From: Christopher S. M. <morrison@ARL.ARMY.MIL> - 2004-03-04 15:28:02
|
It's been a little while since my initial question, and I've done some further poking with continued disdain. To summarize, I've been facing a problem where building tclsh incessintly builds against the mac os x system tcl instead of using the libtcl that I build. Regardless of -nodefaultlibs, it seems to either ignore our -L option or give precedence to the system tcl when searching for -ltcl8.4. On Tue, 13 Jan 2004, Jim Ingham wrote: > It looks like the link is succeeding, but you will know for sure if you > do: > > $ setenv DYLD_PRINT_LIBRARIES 1 > $ /usr/brlcad/bin/bwish > > and watch the output. That will tell you which version of the Tcl & Tk > libraries actually got loaded. Thanks for this tip. It was useful, and indeed confirmed that the system tcl was getting in the way: [static build of libtcl8.4.a performed here] cc -pipe -prebind tclAppInit.o -L/vld/morrison/brlcad/.libtcl8.4.pmac -ltcl8.4 -framework CoreFoundation -o tclsh ./tclsh loading libraries for image: ./tclsh loading library: /System/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl loading library: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation loading library: /usr/lib/libSystem.B.dylib ... If I relink using the .a directly, it links how I'd expect it to: cc -pipe -prebind tclAppInit.o ./libtcl8.4.a -framework CoreFoundation -o tclsh ./tclsh loading libraries for image: ./tclsh loading library: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation loading library: /usr/lib/libSystem.B.dylib ... Again no link difference if I pass -nodefaultlibs or -nostdlib in. > The immediate error is that Tcl & Tk don't know where to look for the > script files. Where is the tk.tcl that you want Wish to find? They are in the --prefix dir at "prefix"/lib/tk8.4 for tk and "prefix"/lib/tcl8.4 for tcl. ("prefix" is /usr/brlcad in this particular example) > If you are building a Unix/X11 version of Tcl & Tk (as opposed to using > Mac OS X style frameworks) you tell Tcl where it is going to find these > script files by passing --prefix=/install/root whatever the install > root is to configure. That will get the build system to seed the > library search path with the correct install location. Are you doing > that? We are indeed building using the unix version/style presently for mac os x. We pass --prefix to the right place, and again the problem appears to be that when the tclsh binary itself is linked, that it's linked against the existing system Tcl instead of what was just compiled. Here's our configure line: ../libtcl8.4/unix/configure --srcdir=/vld/morrison/brlcad/.libtcl8.4.pmac/unix --quiet --cache-file cache.pmac --exec-prefix=/usr/brlcad --prefix=/usr/brlcad --disable-shared As you can see, we are doing a static build there, which may be part of the problem with how the linker searches. I've found what appears to be some hint of a solution, but the cause of the problem remains elusive. Basically, I've narrowed the problem down to a case where if I build tclsh (for example) and link tclsh using -Lyadayada -ltcl8.4 that it does not use my yadayada path. It links against the system framework of /System/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl. If I instead simply link against the static libtcl archive that I just built using ./libtcl8.5.a instead of -Lyadayada -ltcl8.4, then it of course properly links -- as was shown up above. This behavior seems contrary to all our other supported unix platforms, so I'm doing my best to assume that I'm missing some fundamental piece of the puzzle or perhaps apple's modified gcc is doing something that I'm not expecting search-path-wise. Any insight or correction slaps are more than welcome. Cheers! Sean p.s. On another note, we were using 8.4.4 when I first started hunting this problem, and I'm upgrading to 8.4.6 now just because we should. |