Re: bug in libtool --mode=install with EXEEXT
Sebastien Sable wrote:
> ../libtool: line 5764: ./test_libbraille.: No such file or directory
Hi,
just ran in the same bug while cross compiling for MinGW on a
HP-UX box. Here is a patch:
2003-02-27 Ralph Schleicher <[EMAIL PROTECTED]>
* ltmain.in: Only append a dot to the wrapper script when
building on cygwin/MSYS (check for $build, not $host).
diff -u libtool-20030219/ltmain.in.orig libtool-20030219/ltmain.in
--- libtool-20030219/ltmain.in.orig Tue Feb 18 18:12:39 2003
+++ libtool-20030219/ltmain.in Thu Feb 27 14:35:29 2003
@@ -5379,7 +5379,7 @@
# To insure that "foo" is sourced, and not "foo.exe",
# finese the cygwin/MSYS system by explicitly sourcing "foo."
# which disallows the automatic-append-.exe behavior.
- case $host in
+ case $build in
*cygwin* | *mingw*) wrapperdot=${wrapper}. ;;
*) wrapperdot=${wrapper} ;;
esac
@@ -5417,7 +5417,7 @@
# To insure that "foo" is sourced, and not "foo.exe",
# finese the cygwin/MSYS system by explicitly sourcing "foo."
# which disallows the automatic-append-.exe behavior.
- case $host in
+ case $build in
*cygwin* | *mingw*) wrapperdot=${wrapper}. ;;
*) wrapperdot=${wrapper} ;;
esac
--
Ralph
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Patch requirements
Samuel Meder wrote: > > New and improved patch. > > /Sam > Posted to the wrong list. :( http://www.gnu.org/software/libtool/contribute.html ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool Digest, Vol 3, Issue 35
Bill, In general, Libtool won't prevent you from doing anything that the linker can. This works by passing flags through Libtool with these flags: `-Wl,FLAG' `-Xlinker FLAG' Pass a linker specific flag directly to the linker. `-XCClinker FLAG' Pass a link specific flag to the compiler driver (CC) during linking. And another spot where convenience libraries are discussed: Linking static libraries Why return to `ar' and `ranlib' silliness when you've had a taste of libtool? Well, sometimes it is desirable to create a static archive that can never be shared. The most frequent case is when you have a set of object files that you use to build several different programs. You can create a "convenience library" out of those objects, and link programs with the library, instead of listing all object files for every program. This technique is often used to overcome GNU automake's lack of support for linking object files built from sources in other directories, because it supports linking with libraries from other directories. This limitation applies to GNU automake up to release 1.4; newer releases should support sources in other directories. If you just want to link this convenience library into programs, then you could just ignore libtool entirely, and use the old `ar' and `ranlib' commands (or the corresponding GNU automake `_LIBRARIES' rules). You can even install a convenience library (but you probably don't want to) using libtool: burger$ libtool --mode=install ./install-sh -c libhello.a /local/lib/libhello.a ./install-sh -c libhello.a /local/lib/libhello.a ranlib /local/lib/libhello.a burger$ Using libtool for static library installation protects your library from being accidentally stripped (if the installer used the `-s' flag), as well as automatically running the correct `ranlib' command. But libtool libraries are more than just collections of object files: they can also carry library dependency information, which old archives do not. If you want to create a libtool static convenience library, you can omit the `-rpath' flag and use `-static' to indicate that you're only interested in a static library. When you link a program with such a library, libtool will actually link all object files and dependency libraries into the program. If you omit both `-rpath' and `-static', libtool will create a convenience library that can be used to create other libtool libraries, even shared ones. Just like in the static case, the library behaves as an alias to a set of object files and dependency libraries, but in this case the object files are suitable for inclusion in shared libraries. But be careful not to link a single convenience library, directly or indirectly, into a single program or library, otherwise you may get errors about symbol redefinitions. When GNU automake is used, you should use `noinst_LTLIBRARIES' instead of `lib_LTLIBRARIES' for convenience libraries, so that the `-rpath' option is not passed when they are linked. As a rule of thumb, link a libtool convenience library into at most one libtool library, and never into a program, and link libtool static convenience libraries only into programs, and only if you need to carry library dependency information to the user of the static convenience library. Another common situation where static linking is desirable is in creating a standalone binary. Use libtool to do the linking and add the `-all-static' flag. Bill Northcott wrote: > > >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 ___ 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
cvs/HEAD: broken clean on linux+libtool
I have attached a small example tar.gz of this (obvious) bug. cd test make make clean ... and it is not that clean. (it leaves .la and .a files in */.libs) If you look at the commands libtool executes: rm -f lib2/libb.la lib2/main/main/.libs/libb.al lib2/main/main/.libs/libb.la lib2/main/main/.libs/libb.lai rm -f lib1/liba.la lib1/lib2/lib2/main/main/.libs/liba.al lib1/lib2/lib2/main/main/.libs/liba.la lib1/lib2/lib2/main/main/.libs/liba.lai ... you will see that it is definitely on crack. There is simply something wrong in the directory logic. I presume this is broken on all architectures. Please fix before 1.5. :-) Thanks. PS. I am hoping this attached test makes the bug more clear since my previous *4* posts (one of which was a work-around patch) on this bug have been silently ignored. ... I am also interested if someone can test the 'make' part on MacOS. I have heard rumours that this fails. -- Wesley W. Terpstra <[EMAIL PROTECTED]> test.tgz Description: GNU Unix tar archive pgp0.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: bug in libtool --mode=install with EXEEXT
This is obviously correct; please check in. I'm sorry I missed this,
when I submitted the original patch. I'll go hide, now.
--Chuck
Schleicher Ralph (LLI) wrote:
2003-02-27 Ralph Schleicher <[EMAIL PROTECTED]>
* ltmain.in: Only append a dot to the wrapper script when
building on cygwin/MSYS (check for $build, not $host).
diff -u libtool-20030219/ltmain.in.orig libtool-20030219/ltmain.in
--- libtool-20030219/ltmain.in.orig Tue Feb 18 18:12:39 2003
+++ libtool-20030219/ltmain.in Thu Feb 27 14:35:29 2003
@@ -5379,7 +5379,7 @@
# To insure that "foo" is sourced, and not "foo.exe",
# finese the cygwin/MSYS system by explicitly sourcing "foo."
# which disallows the automatic-append-.exe behavior.
- case $host in
+ case $build in
*cygwin* | *mingw*) wrapperdot=${wrapper}. ;;
*) wrapperdot=${wrapper} ;;
esac
@@ -5417,7 +5417,7 @@
# To insure that "foo" is sourced, and not "foo.exe",
# finese the cygwin/MSYS system by explicitly sourcing "foo."
# which disallows the automatic-append-.exe behavior.
- case $host in
+ case $build in
*cygwin* | *mingw*) wrapperdot=${wrapper}. ;;
*) wrapperdot=${wrapper} ;;
esac
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
