Subject: Re: libtool 1.5a download broken - msg#00035

Previous Message by Date: click to view message preview

Re: Darwin, convenience libs, and global symbols

Peter O'Gorman wrote: Matt Fago wrote: | Peter O'Gorman wrote: |> Matt Fago wrote: |> | The main application compiles and links correctly, but a test |> program -- |> | which links the same convenience libraries -- fails with "ld: |> Undefined |> | symbols" corresponding to the global variables in one of the libraries. | | The tarball is located at: God darwin is strange. The symbols the linker can't find are all common symbols, ranlib's default behavior is not to include common symbols in the archive table of contents. You have many choices for fixing this: 1) RANLIB="ranlib -c" ./configure 2) CPPFLAGS="-fno-common" ./configure 3) edit laminate.c and change "int icomputetan;" to "int icomputetan=0;" Although this behavior from apple's ranlib and ld is decidedly different, I'm not sure that it constitutes a bug in libtool. Anyway, I'd suggest option 3 above. While you are in there you could remove the other common symbols too, but it isn't really required. Usually when building shared libtool adds -fno-common to the compile line and -all_load to the link line for convenience libraries, you aren't building shared, so that is not happening, either one (or both) of these would also solve the linking issue. . Not a bug, but perhaps an opportunity to enhance libtool on Darwin. Is it possible to have a future version of libtool do something similar to (1) or (2) above with static libraries on Darwin? I am a bit of a novice in this area -- libtool does its job too well on other platforms. We had been having trouble with shared libraries a few years ago (mixed with F77 on AIX or HPUX or something -- cannot remember), so that's the reason for the static libs. Perhaps it's time to try shared again. Thanks for your help. I won't be able to try it for myself until later tonight, but if it worked for you... Thanks again, Matt

Next Message by Date: click to view message preview

(no subject)

Greetings, We're working on the OpenHPI project in sourceforce and are having trouble getting lt_dlopenext to find a library that we're building. Scenario: We build two versions of the same named library - one is the real library; one is a test version of the same library. We want to determine which library is picked up by the use of an environment variable - OPENHPI_PATH. The problem is that we can always pick up the "real" library but never the "test" one. All Makefiles, libraries, and paths look correct. Details: We set the dl searchpath in our code as follows: path = getenv("OPENHPI_PATH"); err = lt_dlsetsearchpath(path); We build a library - libsnmp_bc.so. The real library is built in an snmp_bc directory, the test library is built in a subdir - snmp_bc/t. After the build is run we have identical libsnmp_bc.la files generated for both directories and both directories have a .libs directory with the desired libraries. So we have in both the snmp_bc and snmp_bc/t directories, the following generated files: libsnmp_bc.la .libs/libsnmp_bc.a .libs/libsnmp_bc.la -> ../libsnmp_bc.la .libs/libsnmp_bc.lai .libs/libsnmp_bc.so -> libsnmp_bc.so.0.3.0 .libs/libsnmp_bc.so.0 -> libsnmp_bc.so.0.3.0 .libs/libsnmp_bc.so.0.3.0 Problem is when OPENHPI_PATH is set to point to the snmp_bc/t directory, lt_dlopenext fails with an errno = 2 (File or path does not exist). If OPENHPI_PATH points to the snmp_bc directory, everything is fine. Seems to indicate that the libraries in snmp_bc/t weren't built properly? Attached are the Makefile.am that control the library builds and the generated libsnmp_bc.la file. snmp_bc dir: snmp_bc/t dir: Both directories: (See attached file: Makefile.am) (See attached file: Makefile.am) (See attached file: libsnmp_bc.la) Any ideas? Or this there additional debugging we can do to isolate the problem? Thanks Steve ======================================================================= Steve Sherman, IBM Internet ID: stevees@xxxxxxxxxx Notes ID: Steve E Sherman/Raleigh/IBM@IBMUS Phone: (919) 254-8621 T/L: 444-8621 Makefile.am Description: Binary data Makefile.am Description: Binary data libsnmp_bc.la Description: Binary data _______________________________________________ Libtool mailing list Libtool@xxxxxxx http://mail.gnu.org/mailman/listinfo/libtool

Previous Message by Thread: click to view message preview

Re: libtool 1.5a download broken

>>> "Rich" == Richard Dawe <rich@xxxxxxxxxxxxxxxxxxxxxx> writes: Rich> Hello. Rich> David Favor wrote: Rich> [snip] >> Is there an alternative way to access libtool 1.5a? Rich> [snip] Rich> I don't know. Maybe one of the GNU libtool maintainers can help? I have an entire duplicate of the CVSROOT of libtool, last synchronized in the night preceding the shutdown, in case someone want to work from it locally (make sure you comment out or update the LockDir option in CVSROOT/config before trying to use this tree). Here it is: http://gadl.nerim.net/pub/libtool-CVSROOT.tar.bz2 -- Alexandre Duret-Lutz

Next Message by Thread: click to view message preview

Re: libtool 1.5a download broken

Hello. "Gary V. Vaughan" wrote: [snip] > According to the instructions on savannah.gnu.org: > > export CVS_RSH="ssh" > cvs -d:ext:anoncvs@xxxxxxxxxxxxxxxxxxx:/cvs-latest/libtool co libtool > > Although I haven't tried it myself. That's how I usually get the libtool sources. Unfortunately it doesn't work right now. I guess it's down due to Savannah being cracked. Bye, Rich =] -- Richard Dawe [ http://homepages.nildram.co.uk/~phekda/richdawe/ ] "You can't evaluate a man by logic alone." -- McCoy, "I, Mudd", Star Trek