>     Whenever I want to link static libs, I specify the absolute
>     path to the .a files, and stay away from -L/-l flags. ie:
> 
>       g++ [..] /usr/lib/libpng.a /usr/lib/libz.a [..] -o foo
> 
>     This always seemed to make it clear to both me and the linker
>     what the intention is, and so dynamic libs won't "leak" into
>     the binary by accident.

Yup, me too. And I think that's what we intended for the fltk-config
script to do too - it just isn't quite there yet.

Drifting off topic a wee bit:
I always believed that if you had a shared and a static version of a lib
in your folder, say libfoo.a and libfoo.{so|dylib|dll}, and you passed
the gcc linker the option "-lfoo" then it would always prefer the shared
object over the static archive, and would only pick the static archive
if no shared object was found.
So the *only* way to reliably make the liker pick the static archive was
to pass its full name, libfoo.a...

However, the other day I was trawling through some Makefiles from a
project on OSX and the guy that wrote them was using some trick linker
option (which I can't now find, or remember...) to make it pick the
static archive when the "-lfoo" option was passed...

Anybody else know what this is? Is it an OSX specific tweak or is it
standard? Can we use it in fltk-config when --ldstaticflags is set?

Thoughts?
-- 
Ian


SELEX Sensors and Airborne Systems Limited
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 
3EL
A company registered in England & Wales.  Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to