Re: static part of a shared library
On 16/11/2008, at 4:02 AM, matej wrote: So imagine this situation: You want to compile a (shared) library. And you also have very good reasons for requiring that a part of the library is build as a static library ONLY and that the rest depends on it. So once more: 1. I want to build a static library libfoo_unsharable out of some sources 2. And I want to build a (shared) library libfoo. 3. Finally, whenever I link with either static or shared version of libfoo, I want libtool to link with libfoo_unsharable automatically. As others wrote you need a convenience library. However, as the code you are compiling will be part of a shared library, you need to use appropriate compiler flags. -fPIC is defaulted on the Apple compilers but I don't know if you need -fno- common anymore. Bill Northcott smime.p7s Description: S/MIME cryptographic signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Loadable modules with FSF compilers on Darwin MacOS X
There is a problem building loadable modules on Darwin/MacOS X using
libtool and FSF compilers.
A typical build failure looks like this:
/bin/sh ../../../libtool --tag=CXX --mode=link /usr/local/gcc4.0/
bin/g++ -g -O2 -o basefunctions.la -rpath /usr/local/lib/jags/
modules -no-undefined -module -avoid-version basefunctions_la-
Add.lo basefunctions_la-Divide.lo basefunctions_la-Equals.lo
basefunctions_la-Multiply.lo basefunctions_la-Neg.lo
basefunctions_la-Pow.lo basefunctions_la-Subtract.lo
basefunctions_la-module.lo ../../../src/lib/libjags.la -lm
/usr/local/gcc4.0/bin/g++ -o .libs/basefunctions.so -bundle .libs/
basefunctions_la-Add.o .libs/basefunctions_la-Divide.o .libs/
basefunctions_la-Equals.o .libs/basefunctions_la-Multiply.o .libs/
basefunctions_la-Neg.o .libs/basefunctions_la-Pow.o .libs/
basefunctions_la-Subtract.o .libs/basefunctions_la-
module.o ../../../src/lib/.libs/libjags.dylib -lm
i686-apple-darwin8-g++-4.0.3: couldn't run '/usr/local/gcc4.0/bin/
undle-gcc-4.0.3': No such file or directory
There is always some complaint about a missing file or directory
whose name starts with 'undle'.
The immediate cause can be seen in the g++ command above where '-
bundle' is the second option. Unless -bundle is the first option on
the command line, it is interpreted as '-b undle' which causes the
errors.
In the package concerned the cause seems to be around line 220 of the
configured libtool where one finds:
module_cmds=\$CC \$allow_undefined_flag -o \$lib -bundle \$libobjs
\$deplibs\$compiler_flags
module_expsym_cmds=sed -e \\\s,#.*,,\\\ -e \\\s,^[]*,,\\\ -
e \\\s,^(..*),_,\\\ \$export_symbols \$output_objdir/
\${libname}-symbols.expsym~\$CC \$allow_undefined_flag -o \$lib -
bundle \$libobjs \$deplibs\$compiler_flags~nmedit -s \
$output_objdir/\${libname}-symbols.expsym \${lib}
Of course it is easy enough to rearrange those lines and get it to
build, but it seems to me like a bug in libtool. Alternatively, it
is a bug in the compiler, although I think it is documented somewhere.
The version here is 1.5.22 on MacOS X 10.4.10 Intel using the gcc
compilers distributed with R-2.4.1.
Using Apple's compilers there does not seem to be the same issue
maybe they require -b to be followed by a space.
I know I am not the only one to hit this problem.
Bill Northcott
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Loadable modules with FSF compilers on Darwin MacOS X
Forget that last message. The problem I have is definitely in the compiler driver gcc/g++ Apologies Bill On 17/07/2007, at 4:00 PM, Bill Northcott wrote: There is a problem building loadable modules on Darwin/MacOS X using libtool and FSF compilers. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: MacOS X nested functions in libtool library
Thanks for that, but I don't now think this is a libtool problem. The MacOS linker will only accept -allow-stack-execute if the output file is of type MH_EXECUTE (ie an application not a library). So you cannot build a dylib with stack execute on. We have a working example of adding code to the library to allow stack execution, but it can't be done with compiler or linker options. Thanks again Bill On 10/06/2007, at 7:01 PM, Ralf Wildenhues wrote: Hello, and apologies for the delay, * Bill Northcott wrote on Tue, May 29, 2007 at 09:16:52AM CEST: On 29/05/2007, at 4:36 PM, Peter O'Gorman wrote: Adding '-fnested-functions' to the CFLAGS stops the compiler barfing. However as per Apple Tech note http:// developer.apple.com/technotes/tn2006/tn2161.html it is also necessary to add -fnested-functions or an equivalent ld flag to the compiler link command. Without this flag, the linker defaults to disable_stack_execute on i386 and the library crashes at runtime. Adding -fnested-functions to libfoo_la_LDFLAGS does not work because libtool strips it out before invoking gcc. Try passing -Wc,-fnested-functions to GNU libtool. Or -Xcompiler. Is there a way around this or an actual fix? LDFLAGS=-Wl,-allow_stack_execute does not work? I just sent the message below to the Apple xcode-users list: [...] Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: MacOS X nested functions in libtool library
On 29/05/2007, at 4:36 PM, Peter O'Gorman wrote: Adding '-fnested-functions' to the CFLAGS stops the compiler barfing. However as per Apple Tech note http:// developer.apple.com/technotes/tn2006/tn2161.html it is also necessary to add -fnested-functions or an equivalent ld flag to the compiler link command. Without this flag, the linker defaults to disable_stack_execute on i386 and the library crashes at runtime. Adding -fnested-functions to libfoo_la_LDFLAGS does not work because libtool strips it out before invoking gcc. Is there a way around this or an actual fix? LDFLAGS=-Wl,-allow_stack_execute does not work? I just sent the message below to the Apple xcode-users list: TN2161 says that -fnested-functions can be passed to the compiler driver in a link command to send the -allow_stack_execute flag to the linker. However, libtool seems to choke on it thus: gcc -B ../../tools -dynamiclib -fnested-functions -o .libs/ libswarm.0.0.0.dylib .libs/SwarmEnvironment.o .libs/ classList.o .libs/libswarm.lax/libspace.a/Ca2d.o *** lots of objects removed .libs/libswarm.lax/libswarmobjc.a/thr.o -L/Library/Frameworks/ Swarm.framework/Versions/Current/Resources/lib -L/Library/ Frameworks/Tk.framework/Versions/8.4-X11/lib -L/usr/X11R6/lib - lpthread /Library/Frameworks/Swarm.framework/Versions/Current/ Resources/lib/libffi.dylib -lBLT24 -lXpm /Library/Frameworks/ Swarm.framework/Versions/Current/Resources/lib/libpng12.dylib / Library/Frameworks/Swarm.framework/Versions/Current/Resources/lib/ libhdf5.dylib -lz -lX11 -lm -ldl -Wl,-search_paths_first - framework CoreFoundation -framework CoreFoundation -framework Tk - framework Tcl -install_name /Library/Frameworks/Swarm.framework/ Versions/2.2/lib/libswarm.0.dylib -Wl,-compatibility_version -Wl,1 - Wl,-current_version -Wl,1.0 /usr/bin/libtool: unknown option character `l' in: - allow_stack_execute Usage: /usr/bin/libtool -static [-] file [...] [-filelist listfile [,dirname]] [-arch_only arch] [-sacLT] Usage: /usr/bin/libtool -dynamic [-] file [...] [-filelist listfile [,dirname]] [-arch_only arch] [-o output] [-install_name name] [- compatibility_version #] [-current_version #] [-seg1addr 0x#] [- segs_read_only_addr 0x#] [-segs_read_write_addr 0x#] [- seg_addr_table filename] [-seg_addr_table_filename file_system_path] [-all_load] [-noall_load] make[4]: *** [libswarm.la] Error 1 Ho hum This was done bodging -fnested-functions option into the configured libtool script. I will try the -Wl option but libtool seems to strip all flags that it does not recognise. Have to dash now Bill ___ http://lists.gnu.org/mailman/listinfo/libtool
MacOS X Intel nested functions
I think I have reached a dead end on this. See below:
#bar.c
void bar () {
return;
}
#foo.c
int main(int argc, void * argv) {
bar();
return 0;
}
[MBP-OGN:Public/Swarm/libtest] billn% gcc -c -fnested-functions -o
bar.o bar.c
[MBP-OGN:Public/Swarm/libtest] billn% gcc -dynamiclib -fnested-
functions -o libbar.dylib bar.o
/usr/bin/libtool: unknown option character `l' in: -allow_stack_execute
Usage: /usr/bin/libtool -static [-] file [...] [-filelist listfile
[,dirname]] [-arch_only arch] [-sacLT]
Usage: /usr/bin/libtool -dynamic [-] file [...] [-filelist listfile
[,dirname]] [-arch_only arch] [-o output] [-install_name name] [-
compatibility_version #] [-current_version #] [-seg1addr 0x#] [-
segs_read_only_addr 0x#] [-segs_read_write_addr 0x#] [-seg_addr_table
filename] [-seg_addr_table_filename file_system_path] [-all_load]
[-noall_load]
[MBP-OGN:Public/Swarm/libtest] billn% gcc -dynamiclib -o libbar.dylib
bar.o
[MBP-OGN:Public/Swarm/libtest] billn% gcc -fnested-functions -o foo -
L./ -lbar foo.c
[MBP-OGN:Public/Swarm/libtest] billn%
-fnested-functions (-allow_stack_execute) only works as an option
when linking an executable. It then means all code in that process
can execute functions off the stack.
It is not acceptable as an option linking a dynamic library, because
that uses Apple's libtool, which spits the dummy. Even if libtool
did not barf, the option is meaningless in a library. The
allow_stack_execute can only be set by the
OS as part of launching a new process.
This is not an issue for producing Objective-C Swarm programs. The -
fnested-functions option when doing the final link will ensure that
the program can run the nested functions.
However, I can see no way to get this to work for java, where the
main executable is java which has not been linked with the -fnested-
functions flag.
Either
a. I have this wrong
or
b. The only way to get JavaSwarm to run on MacOS X Intel is to get
rid of the nested functions. :-((
Bill
___
http://lists.gnu.org/mailman/listinfo/libtool
MacOS X nested functions in libtool library
I am trying to build a libtool library containing nested functions on MacOS X Intel. The project is using Autoconf 2.59, Automake 1.9.6 and Libtool 1.5.22. Adding '-fnested-functions' to the CFLAGS stops the compiler barfing. However as per Apple Tech note http://developer.apple.com/ technotes/tn2006/tn2161.html it is also necessary to add -fnested- functions or an equivalent ld flag to the compiler link command. Without this flag, the linker defaults to disable_stack_execute on i386 and the library crashes at runtime. Adding -fnested-functions to libfoo_la_LDFLAGS does not work because libtool strips it out before invoking gcc. Is there a way around this or an actual fix? Thanks Bill Northcott ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.5.23b
On 19/02/2007, at 4:04 AM, Tim Rice wrote: Should a single libtool handle both 32bit 64bit builds on Solaris with Sun Studio 11? Is there any support for 64 bit MacOS builds using Apple's -arch option or FSF gcc with -m64? In particular does it understand that some versions of gcc seem to put 64 bit libs in lib/ppc64 or whatever? Thanks for all your work on this Bill Northcott ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: totally confused by versioning system of libtool...
On 15/05/2005, at 12:24 PM, Peter O'Gorman wrote: It what sense do you think 'it works fine'? How does a single libtool version string get translated into the two possibly different version strings required by MacOS X? I don't follow what you think is wrong. Libtool's versioning system uses the CURRENT, AGE and REVISION system described in the libtool documentation. Does reading this thread help? http://thread.gmane.org/gmane.comp.gnu.libtool.patches/1348 That link was helpful, but I think incorrect. In one of the messages you have Now lets release a new libfoo 4:0:2 Current system: libfoo.dylib - libfoo.2.2.0.dylib libfoo.2.dylib - libfoo.2.2.0.dylib libfoo.2.2.0.dylib install_name libfoo.2.dylib compatibility_version 5 current_version 5.0 Proposed : libfoo.dylib - libfoo.2.dylib libfoo.2.dylib same encoded information. IMHO this should be: Now lets release a new libfoo 4:15:2 libfoo.dylib - libfoo.2.dylib (for the benefit of configure scripts only) libfoo.2.dylib install_name libfoo.2.dylib compatibility_version 3.0.0 current_version 5.0.15 Possibly, the last line could equally be: install_name libfoo.2.dylib compatibility_version 3.0.0 current_version 3.2.15 That would have the same effect on Darwin, if applied consistently. If you set compatibility_version to 5, which is what seems to be happening now, then something linked against the library built with libtool version 3:10:1 will fail to link at runtime, even thought the libtool version implies it is compatible. I think your 2003 suggestion to eliminate libfoo.x.x.x.dylib is correct. Creating that just results in unnecessary duplication. Bill Northcott ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: totally confused by versioning system of libtool...
On 15/05/2005, at 10:06 PM, Peter O'Gorman wrote: Possibly, the last line could equally be: install_name libfoo.2.dylib compatibility_version 3.0.0 current_version 3.2.15 That would have the same effect on Darwin, if applied consistently. The encoded current_version is for informational purposes only, nothing uses it, compatibility_version is used by dyld (darwin's dynamic linker) when loading libraries. It checks that the library version it loaded has a compatibility_version greater than or equal to the one it saw when it was created by the static linker. The example is interesting. Thanks. I tried a few more variations on the theme. Compatibility_version works as you say. However, it still seems to me that current version is not irrelevant. Although it is not checked by dyld, according to the Apple docs both library and client can check it at runtime for compatibility, presence of features etc. So it still seems to me that it should be meaningful. Also and more to the point, the compatibility version in the libfoo example should still be 3.0.0 not 5.0.0. Surely compatibility_version 5.0.0 implies a libtool version like 4.0.0 or 6.12.2, rather than 4.15.2? Or am I still misunderstanding libtool version, which was where we came in? Bill ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: totally confused by versioning system of libtool...
On 15/05/2005, at 1:57 PM, Peter O'Gorman wrote: I have so far only found one GNU libtool packages which correctly versions its libraries on MacOS X. This is R and they seem to do it with code in Makefile.in which overrides the libtool versioning. Looks like R builds a framework on darwin and uses install_name_tool to encode the full path, as the library's install_name (soname), so the library ends up being something like: install_name /Library/Frameworks/R.framework/Versions/2/Resources/ lib/lib compatibility_version 2 current_version 2.1 Please read the libtool versioning information, man 1 ld, and http://developer.apple.com/documentation/DeveloperTools/Conceptual/ MachOTopics/Articles/loading_code.html (alternatively http:// tinyurl.com/a376e). I read this again before that last post. Bill ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: totally confused by versioning system of libtool...
On 15/05/2005, at 10:06 PM, Peter O'Gorman wrote: Possibly, the last line could equally be: install_name libfoo.2.dylib compatibility_version 3.0.0 current_version 3.2.15 That would have the same effect on Darwin, if applied consistently. The encoded current_version is for informational purposes only, nothing uses it, compatibility_version is used by dyld (darwin's dynamic linker) when loading libraries. It checks that the library version it loaded has a compatibility_version greater than or equal to the one it saw when it was created by the static linker. On second thoughts, perhaps I do get it. Or maybe it is to late at night, and it will make sense in the morning. Bill ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: totally confused by versioning system of libtool...
On 15/05/2005, at 12:55 AM, Peter O'Gorman wrote: | How should libtool versioning be used so as to support both the MacOS | X/Darwin scheme and the Linux ELF way of doing things? Is this | possible, or should one write specific makefile routines to adjust | version numbers at install time? Mac OS X/darwin support for library versioning in GNU libtool uses a scheme that is similar to GNU/linux, it works fine. I have so far only found one GNU libtool packages which correctly versions its libraries on MacOS X. This is R and they seem to do it with code in Makefile.in which overrides the libtool versioning. Most libtool libraries either don't set the internal library versions at all or just set both current_version and compatibility_version to the same string, which is not correct. As I understand the problem, on Linux an app linked against libfoo version 4.5.6 will happily link at run time with version 4.6.2. On Darwin MacOS X it will not work. As I see it on MacOS X the app should have a current_version of 4.5.6 and compatibility version of 4.0.0. R is the only package I have seen that does this. It what sense do you think 'it works fine'? How does a single libtool version string get translated into the two possibly different version strings required by MacOS X? Bill Northcott ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: totally confused by versioning system of libtool...
On 14/05/2005, at 1:33 AM, Bob Friesenhahn wrote: How does the version number get used in this situation? That is, is there any time on the users machine that the linker notices that he is now linking to 1.0.0 instead of 0.0.0? Yes, the linker notices it when it runs. :-) Existing programs continue to use existing libraries according to ELF versioning rules. Programs linked after the newer library is installed will use the newer library. Which is all very nice, but does it also work on non-ELF systems such as Darwin/MacOS X? Bill Northcott ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: totally confused by versioning system of libtool...
On 14/05/2005, at 3:45 AM, Ed Hartnett wrote: But I don't understand why it's not 0.5.0 and 0.6.0. That is, wouldn't it be a case of incrementing the minor version number, the middle number? If libexample 0.0.6 is merely a bug fix, it is usually customary to only updated the least significant number in the version string. Customarily, however, only the very first number is ever used for runtime linking (so libexample 0.0.0, libexample 0.0.1, and libexample 0.1.0 would all replace each other, but libexample 0.1.0 and libexample 1.0.0 could be installed in parallel). MacOS X/Darwin regards both major and minor version numbers as significant. Also it stores two library versions in each linked executable file the 'current-version' which is the one linked against and the 'compatibility-version' which is the oldest which will support the executable (possibly with reduced functionality. Similarly libraries export their current version and the oldest API which they support. How should libtool versioning be used so as to support both the MacOS X/Darwin scheme and the Linux ELF way of doing things? Is this possible, or should one write specific makefile routines to adjust version numbers at install time? Bill Northcott ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: building libtool on Tru64 Unix
In regard to: building libtool on Tru64 Unix, Janet Goldstein said (at...: I am trying to build libtool 1.5.6 on Tru64 Unix. using './configure --enable-dynamic'. The 'make' dies thusly: I've never seen this particular problem on Digital UNIX or Tru64 UNIX. The obvious differences I can see between your build and my typical builds are - I use GNU make. Not sure if it's required, but I'm suspicious about `config.status' being run as a dependency. Try using GNU make for the build process. I have successfully done this, and I am very sure you need GNU make. Bill Northcott ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Building JNI libraries on MacOS X and other systems
Searching the archives, I seem some discussion of enhancing libtool to build JNI libraries correctly. On MacOS X this requires a normal .dylib dynamic library but renamed or symlinked to .jnilib. Cygwin also seems to have specific requirements. I can find nothing in the sources I downloaded ten days ago. Did anything come of this? Are there any plans for such an enhancement? Bill Northcott Swarm Development Group ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.5 on MacOS X
Because of the way things are set up, adding fsf gcc support is essentially adding a completely different compiler. Depending on my available free time, I may decide to revisit this issue, do you really think it is required? With stock GCC 3.3, most if not all of the Apple-like command line options are processed just as they are on the compiler distributed by Apple. Take a look at the sources and you'll see there are hooks for this. For libtool 1.5, treating stock GCC 3.3 like Apple's GCC works for me to generate dynamic libraries and executables. I just did have a quick peek at the sources, looks like you are indeed correct. I will submit a patch to the list tomorrow. To excuse myself here, almost none of these flags were passed through by the gcc-3.2 fsf gcc which was available when I first looked at this issue. Firstly: Fixing the libtool.m4 macros allowed our project to build on MacOS X using an FSF gcc3.3 compiler. Secondly: I would like to second Marcus' comments that the differences between an Apple compiler and an FSF compiler built on MacOS X are very small. The big difference is the compiler file layout. See the link below for a complete listing of Apple compiler options which highlights the ones not supported on the FSF version. http://developer.apple.com/techpubs/macosx/DeveloperTools/gcc3/gcc/Option-Summary.html#Option%20Summary They involve Apple specific issues such as kext support, Apple ld/dyld support, Pascal strings, pre-compiled headers, Altivec and a couple of Apple legacy compatability things. All of these seem to me to be unlikely to be an issue for cross platform code that wants to use libtool or the FSF compiler. I think the FSF compiler is supposed to support Altivec real soon now. As far as I can see, there is only one issue which prevents our project building with an Apple compiler. This is that the Apple compilers crash trying to compile a main() function with the -fgnu-runtime flag. Bill Northcott ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.5 on MacOS X
Another member of our group suggested: Before installing libtool 1.5, go through the libtool.m4 and change all the stuff that says: if $CC -v 21 | grep 'Apple' /dev/null ; then \ to: if true; then Then rerun libtool's `bootstrap', and reisntall. The basic problem is that libtool uses the info from gcc -v to do Darwin things if it sees Apple. GCC 3.3 doesn't report Apple. This sounds very plausible to me. It would explain why I have not had trouble building other gnu tools using Apple's compiler. I will test it and report back before sending the complete log. The $CC -v | grep 'Apple' will only work if you are using the Apple compiler. Mac hackers like us may well be using a compiler built from FSF sources. We do it because we need to use the GNU Objective-C runtime and the -fgnu-runtime flag crashes Apple's compilers:-( Others may may use FSF sources for the languages not included in the Apple builds such as f77, ada etc.. The fix suggested above is obviously an OS specific kluge. It seems to me that libtool needs to know the linker, not the compiler. It would be better to use if cc -v 21... which would test the default compiler, but that could still be defeated by the PATH setting. Unfortunately Apple's ld has no version option. The test I have used is to check for MacOS X is uname = 'Darwin'. This may give a problem with old Rhapsody versions of the OS but you could test version as well. On my machines: [pbg4-12bn:macosx/swarmx/build] billn% uname -v Darwin Kernel Version 6.6: Thu May 1 21:48:54 PDT 2003; root:xnu/xnu-344.34.obj~1/RELEASE_PPC Peter O'Gorman [EMAIL PROTECTED] wrote on 30/05/2003 10:41:14 PM: Could you possible run this again in this directory (preferably with all the .o's present in the .libs dir) using `make SHELL=/bin/sh -x log.txt' and send me the log. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Convenience Libraries
In general, Libtool won't prevent you from doing anything that the linker can. This works by passing flags through Libtool with these flags: Not really. As has been discussed here before it will not let you produce a dynamic by linking static libraries, although this can be done with direct invocation of gcc or ld on MacOS X. And another spot where convenience libraries are discussed: Unfortunately that is the one and only spot where they are discussed and it does not say much. Perhaps it would help, if I clarify what we are trying to do. The Swarm project has a hierarchy of three levels of libraries: Basics like BLT, and libobjc Swarm modules which are subsets of the API. These reference symbols in the basics and also each other. A swarm library which is the top of the hierarchy and uses symbols from all of the above. Libtool appears to restrict options to an either or choice: Either: Build everything static in which case every symbol will be incorporated into every executable built against the top level library. OR: Build everything dynamic in which case everything has to be in the right place at the right times and a complex DYLD_LIBRARY_PATH set up to get the apps to run. and you also get plagued with run time warning about not being able to find the build directories. Might this last problem go away with --disable-fast-install? What we would like to do is to build most of the lower level libraries static and link them into a single swarm dynamic library against which executables would be dynamically linked. Libtool; appears to specifically rule this out. Or can you explain how to do it? Bill Northcott ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool Digest, Vol 3, Issue 35
A convenience library is usually part of your own package, it turns into a list of object files when you link to it. It could be in a subdirectory, much like libltdl is for many packages that use it. Here is a section of the manual that mentions them: http://www.gnu.org/software/libtool/manual.html#SEC14 Unfortunately all it does do is mention them! It does not explain what it means or how to build or use them. Is there any useful documentation? What we are looking for on MacOS X is the ability to link a static library into a dylib with the -all-load flag, which ensures all symbols are loaded even if not referenced. Having read the MacOS X ld docs, this is the only way to build a dylib which actually includes all the symbol definitions from some other library. I seem to remember seeing libtool use the -all-load flag, but I spent several hours reading what documentation there is and I can see no clues how to do this. Bill Northcott ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Pending release of 1.5
I'm just about to make the release of Libtool 1.5. If anyone would like to test the current CVS on their favorite platform and report any problems, please do so! If not, your woes may have to wait for 1.5.1. We are trying to build a complex libtoolised package (Swarm) on MacOSX. The libtool command is: /bin/sh ../../libtool --mode=link /Users/billn/Public/GNU/dst/bin/gcc -g -O2 -fgnu-runtime -fno-strict-aliasing -Wall -Wno-import -Wno-protocol -Wno-long-long -Wno-unknown-pragmas -Wno-unknown-pragmas -o libdefobj.la -rpath /Users/billn/Public/Swarm/swarm/macosx/swarmx/build/dst/usr/lib -version-info 4:0:0 Archiver.lo LispArchiver.lo HDF5Archiver.lo Arguments.lo Create.lo Customize.lo DefClass.lo DefObject.lo HDF5Object.lo Program.lo Symbol.lo Zone.lo FCall.lo FArguments.lo defobj.lo internal.lo java.lo directory.lo JavaProxy.lo JavaClassProxy.lo JavaCollection.lo JavaCollectionIndex.lo COMProxy.lo fcall_objc.lo fcall_java.lo COM.lo modulemap.lo ../../avcall/libavcall.la after much complainng this produces a link instruction: /Users/billn/Public/GNU/dst/bin/gcc -dynamiclib -flat_namespace -undefined suppress -o .libs/libdefobj.4.0.0.dylib .libs/libdefobj.la-27.o -all_load ../../avcall/.libs/libavcall.a ../../avcall/.libs/libavcall.a -install_name /Users/billn/Public/Swarm/swarm/macosx/swarmx/build/dst/usr/lib/libdefobj.4.dylib -compatibility_version 5 -current_version 5.0 which fails with multiple definitions of symbols in libavcall.a. This was broken in 1.4.2. Apparently fixed in the 1.4.3 release and seems to be broken again in 10 Feb cvs snapshot I tried yesterday. I think we give up and use jam on MacOS X until you guys think this thing is ported. Bill Northcott ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
MacOS X libtool problem with non-standard libobjc
It appears that libtool 1.4.3 implicitly assumes that any App containing Objective-C code must be linked against the system (Apple) libobjc. This stuffs up projects like Swarm or GNUstep which use non-Apple runtimes which include a libobjc. The problem is that regardless of where the object file containing the main() function appears on the libtool command line, libtool will create a link instruction placing it ahead of any -Lsomepaths. When the linker(ld) encounters the object file containing main(), if that object file includes Objective-C code, it will be linked against the system libobjc. Any '-Lpathtomylibobjc -lobjc' type flags further down the command line are just ignored even though there were undefined symbols in the first link. In order to work -Lpathtomylibobjc must precede any object files containing Objective-C on the ld command line. Libtool 'as is' prevents this! Even LD_LIBRARY_PATH variables don't seem to help. Bill Northcott ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
