On 25 Oct 2008, at 4:48, Jane wrote:
> i am wondering how to get pthreads into the windows version of my
> fltk application.
> i have to get some (which?) pthread library, ok. but where do i put
> it if i dont want to install one into the system? is it possible to
> get some pthread.a, put it (together with some .h) into the
> fltk-1.1.9 directory and build a libfltk.a with pthreads inside?
> yeah? how? no? why not?
There are "emulations" of pthreads that run on win32 that you can
use, and more or less work like a real pthreads - google will surely
find something.
Once you have it built, just put the lib files in beside your fltk
libs and link as normal.
However - I wouldn't bother in practice: If all you want to do is
create/kill a few threads, and you don't want all the fancy-schmancy
(and mostly pointless) baggage that pthreads brings with it, then the
signature of the MS "_beginthread(...)" function and the pthreads
"pthread_create(...)" are similar enough that a few ifdefs can fix it
all up nice...
See the threads.h header in the test directory for simple worked
example.
> i am missing some general linker skills here and feel kinda lost
> because all my object files built fine but the linker is throwing
> errors like i am throwing stones (when i see stones).
>
> if theres only a libfoo.a version in -L (no libfoo.so), will -lfoo
> statically link the library? what should i do if i have both
> versions and want the static one?
If this is a gcc/ld/binutiuls sort of toolchain, then -lfoo looks
*first* for libfoo.so/libfoo.dll/libfoo.dylib/etc (depending on
platform) and links to that.
If it finds no dynamic lib to link, it then looks for (static)
libfoo.a instead.
Basically, it prefers shared objects over static objects, which can
be a bloody nuisance sometimes.
To force it to only link the static version, you *have* to give the
full pathname if you have both, or the shared object *will* be chosen
in preference.
> finally, if i get some weird undefined references at the linking
> stage, how do i find the lib to link to?
Well - sometimes it is obvious from the symbol name what lib it comes
from, if not... I have in the past resorted to:
cd <libs folder>
nm *.a | grep -H <some symbol name>
And sorting through the libs that way to find out who defines a
missing symbol...
> oh and, can all undefined reference errors at the linking stage be
> solved by just adding another -l or -L flag to the ldflags?
Yes, quite often. If you know which lib to add.
Note also that the majority of linkers are order sensitive... You
need to list the lib which provides a symbol *after* all the things
that use that symbol, otherwise the linker thinks that no module uses
those symbols and discards them to save space.
(Side note: A lot of the MS linkers *do not* work like that - they
try and hold all the symbols in memory until all the modules are
resolved, which alleviates this issue, but has some performance
issues of its own. However, a lot of code that links just fine on
win32 with the MS tools will fail to link with the gcc tools for this
very reason, as the original authors have not considered link order
at build time...)
--
Ian
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
