Re: [MACTCL] Inadvertantly linking against the system tcl/tk

[Christopher S. M. <morrison@ARL.ARMY.MIL>]

Daniel,

Ugh.  I had feared something along those lines was happening with the
static libs.  Thank you in any respect, however, for the explanation.

Since it wouldn't be prudent for out team to assume that our users will be
able to move their system libraries out of the way (like we had been doing
ourselves), I think our best solution is to simply rename the library for
static builds so as not to collide with the system tcl library name.  I
assume that dynamic library search path ordering is "doing the right
thing" and won't need to be modified, though I'll have to now reverify
this for just for my own sanity.

Now to figure out why linking with AquaTk crashes.. ;)

Cheers!
Sean


On Fri, 5 Mar 2004, Daniel A. Steffen wrote:

> [snip snip]
>
> this is exactly the crucial point, I hadn't realized your were linking
> statically in your previous question
>
> what you're seeing is a (mis)feature of the Darwin ld in that when
> searching for a library in response to -lblah it always prefers a
> dynamic library libblah.dylib instead of a static one libblah.a if it
> can find such a dynamic library anywhere on its search path.
>
> I presume you're working on Panther, and /usr/lib/libtcl.dylib or
> /usr/lib/libtcl8.4.dylib are thus getting in the way of -ltcl finding
> your static version. Since these are just symlinks to
> /System/Libray/Frameworks/Tcl.framework/Tcl, one way to workaround the
> problem is just to temporarily move these symlinks aside, the system
> tcl will not break as a result of that (but building other tcl software
> might, of course).
>
> The way to tell ld that you want a specific static library to be used
> while linking is to give the full path to the .a library on the link
> line instead of using the -l option, but that will require makefile
> fiddling of course...
>
> See the darwin-development list archives for more details & background
> on the ld & static libs issue, it has come up there quite a few times
>
> Cheers,
>
> Daniel