0

I have an issue trying to cross build win32 and win64 exes on a linux host.

I am using the mingw cross build toolchains

my .c file includes time.h in order to use clock_gettime() in main()

now this is a POSIX thing so no guarantee it is windows portable

however, on another laptop with a similar (but obviously not identical) setup it does compile and link no problem

on this laptop (a new one I am migrating to) I get a linker error:

undefined reference to `clock_gettime'
collect2: error: ld returned 1 exit status

what I would like to be able to do is somehow have the linker on the other machine tell me where it is finding the .dll with clock_gettime() in it

In order for me to see whether the similar .dll is present on the new laptop and whether the clock_gettime() symbol is avaiable in it

Is it possible to get the linker to report this info, some sort of verbose mode perhaps. I've gone down the GIYF route but drawn a blank thus far.

bph
  • 10,728
  • 15
  • 60
  • 135

2 Answers2

1

Compile with -lrt which is needed for for glibc version < 2.17.

What probably happens on the other laptop is that it has a recent version of glibc >=2.17 in which the the clock_gettime() is part of the libc. But older in glibcs, it's a separate library. Hence, you needed to link it yourself.

P.P
  • 117,907
  • 20
  • 175
  • 238
  • 1
    This solves the asker's problem but doesn't actually answer the question as written. – user253751 Jan 21 '16 at 22:00
  • This doesn't solve the problem unfortunately, I don't think librt exists for mingw - i am very curious as to how it was linked on the other machine, i.e. in which dll it found clock_gettime() - some seem to suggest it may be in winpthread, rather than guessing though I'd like the linker to tell me – bph Jan 22 '16 at 10:50
  • 1
    `clock_gettime()` is a POSIX function and may not be available on windows to start with. If it exists, then you can link it just how you would in a GNU environment with `-lm`, `-lpthread`, etc. Mingw is supposed to be a simulation of GNU environment. I don't see how it's useful to find in what DLL it actually presents and I don't know how to list DLLs. As you said, librt may not exist as a separate library but the internal mechanism of how DLLs are linked is not really useful: you just link how you would do with ld. – P.P Jan 22 '16 at 11:15
  • 1
    You can try with `#define _POSIX_SOURCE 199309` to enable POSIX functiions (if your mingw version) supports. If not, I would assume `clock_gettime()` doesn't exist. – P.P Jan 22 '16 at 11:15
  • when I talk about which .dll the clock_gettime() fn is in, what I'm trying to get at is which library I have to link to, i.e. -lm, lpthread, lrt etc. when cross-building, i.e. in which library that fn resides in the mingw environment. I know its in librt for a native gcc linux build, but I would like some technique to find this info for mingw. hope that makes it a bit clearer. I'll try that #define many thanks – bph Jan 22 '16 at 11:28
  • pthread was the fix - but i had to trial and error it rather than have the linker show me the way.. trawling through a bunch of mingw discussions on sourceforge suggested it may work – bph Jan 22 '16 at 11:57
0

To use clock_gettime() as defined in <time.h> when cross building for windows using mingw toolchain on a linux host you must link to pthread not rt

for example:

source code, example.c, looks like this:

#include <time.h>
...
struct timespec t1;
...
clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &t1);

native build looks like this:

gcc example.o -lrt -o example

win32 cross-build looks like this:

i686-w64-mingw32-gcc -I/usr/local/i686-w64-mingw32/include  example.o -L/usr/local/i686-w64-mingw32/bin -lpthread -lws2_32 -o example.exe

Unfortunately, I am none the wiser on how to get the linker to tell me in which library it has found a function that it has successfully linked to

i.e. if I could have somehow got the linker to inform me that it had found clock_gettime() in libpthread on my other machine that was successfully linking, I could have saved a lot of messing about fixing the link error issue on this machine.

bph
  • 10,728
  • 15
  • 60
  • 135