Re: About win32 impgen.c patch
On Tue, 22 Oct 2002, Robert Boehne wrote:
> I suppose that leaves one question (in my mind at least),
> and that is, What is pw32?
http://pw32.sourceforge.net/
The latest entry in the changelog is:
2002-08-03 Paul Sokolovsky [EMAIL PROTECTED]
* src/libc/dos/io/{posix2win32.c, win322posix.c},
src/libc/posix/dirent/readdir.c: Urldecode only
characters which are illegal in win32 (i.e. ones
we might have encoded previously). This fixes problem
with find outputing "foo bar.txt not found" for
"foo%20bar.txt" in browser cache.
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: About win32 impgen.c patch (fwd)
I am Cc:ing the libtool list on this response, since there are interested parties there. On Wed, 23 Oct 2002, Paul Sokolovsky wrote: > Bob Friesenhahn wrote: > > Comments? Should pw32 be tracking Cygwin and MinGW in libtool rather > > than being left behind? > > Yes, please, if it's not hard, pw32 can follow the same sequence as mingw. > > As for general point of removing (parts of) impgen.c, I cannot give > adequate answer as I don't have sources handy. IIRC, it belongs to ld. > And it's nice to have ability to create all the DLL stuff (even adhoc > bits like implib) with mere ld (== it's easier for non-win32-savvy > people to port the stuff). On the other point, there's duplication of > functionality with dlltool... Due to advances in binutils, both Cygwin and MinGW no longer use impgen, or even dlltool, from libtool. I assume it that pw32 benefits from the same gcc/binutils enhancements. Do you recommend that all libtool cases which look like cygwin* | mingw* ) be extended to cygwin* | mingw* | pw32*) and the cruft currently attributed to pw32 (using impgen and dlltool) be removed? There is no one currently supporting the pw32 support in libtool, and until yesterday, none of the currently active maintainers even knew what pw32 was. This means that pw32 support in libtool has fallen into disrepair. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
library relocation
Hello, I'm working on linux based embedded platforms. To build a complete platform, we usually compile and install our software packages in a directory that is specific to each developer, say: /home/fred/frozen/usr/lib/... Then, the compiled libraries and executables that must be actually available on the final platform are manipulated so that they finally appear in /usr/lib/... ...when the platform has booted. Here comes the problem: - Scenario 1: a library (let say glib) is configured with the final prefix (/usr) and installed for instance with a make install DESTDIR=/home/fred/ Then, a program that uses the library will link with sth like -L/home/fred/frozen/lib -lglib Unfortunately, libtool (1.4.2a) will transform this into... /usr/lib/libglib.so Grr. This is not a library compiled for the same architecture. - Scenario 2: the library is directly configured to get installed in /home/fred/... Then, the linking will be performed correctly, but a wrong rpath will be added in the executable... Do you know a better method ? Thank, Frédéric -- Frédéric GobrySMARTDATA --- http://www.smartdata.ch Software Engineer Lausanne - Switzerland +41 21 693 84 98 msg03104/pgp0.pgp Description: PGP signature
Re: library relocation
I think the DESTDIR patch for ltmain.sh fixes that. At least it did for me. I had the problem that relinking was failing with "make prefix=/blah install" so I retooled with DESTDIR and with this patch everything seems OK. I found this through a bugs page for libtool, but I can't find that page now. But I do still have the patch address: http://mail.gnu.org/pipermail/bug-libtool/2002-February/003019.html Frederic Gobry wrote: Hello, I'm working on linux based embedded platforms. To build a complete platform, we usually compile and install our software packages in a directory that is specific to each developer, say: /home/fred/frozen/usr/lib/... Then, the compiled libraries and executables that must be actually available on the final platform are manipulated so that they finally appear in /usr/lib/... ...when the platform has booted. Here comes the problem: - Scenario 1: a library (let say glib) is configured with the final prefix (/usr) and installed for instance with a make install DESTDIR=/home/fred/ Then, a program that uses the library will link with sth like -L/home/fred/frozen/lib -lglib Unfortunately, libtool (1.4.2a) will transform this into... /usr/lib/libglib.so Grr. This is not a library compiled for the same architecture. - Scenario 2: the library is directly configured to get installed in /home/fred/... Then, the linking will be performed correctly, but a wrong rpath will be added in the executable... Do you know a better method ? Thank, Frédéric -- Paul E. Johnson email: [EMAIL PROTECTED] Dept. of Political Sciencehttp://lark.cc.ku.edu/~pauljohn 1541 Lilac Lane, Rm 504 University of Kansas Office: (785) 864-9086 Lawrence, Kansas 66044-3177 FAX: (785) 864-5700 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
RE: library relocation
We have this same need when building our software. I've hacked our version of libtool to support this feature: Index: ltmain.sh === RCS file: /var/CVSROOT/ldap/build/ltmain.sh,v retrieving revision 1.1.1.2 retrieving revision 1.3 diff -u -r1.1.1.2 -r1.3 --- ltmain.sh 20 Sep 2002 06:21:52 - 1.1.1.2 +++ ltmain.sh 3 Oct 2002 17:52:00 - 1.3 @@ -1821,9 +1821,7 @@ lib_linked=yes case $hardcode_action in immediate | unsupported) - if test "$hardcode_direct" = no; then - add="$dir/$linklib" - elif test "$hardcode_minus_L" = no; then + if test "$hardcode_minus_L" = no; then case $host in *-*-sunos*) add_shlibpath="$dir" ;; esac @@ -3885,16 +3888,33 @@ output="$output_objdir/$outputname"i # Replace all uninstalled libtool libraries with the installed ones newdependency_libs= + newdirs= for deplib in $dependency_libs; do case $deplib in *.la) - name=`$echo "X$deplib" | $Xsed -e 's%^.*/%%'` + name=`$echo "X$deplib" | $Xsed -e 's%^.*/lib%%' -e s%.la%%` eval libdir=`sed -n -e 's/^libdir=\(.*\)$/\1/p' $deplib` if test -z "$libdir"; then $echo "$modename: \`$deplib' is not a valid libtool archive" 1 >&2 exit 1 fi - newdependency_libs="$newdependency_libs $libdir/$name" + newdependency_libs="$newdependency_libs -l$name" + ;; + -L*) + if test -z "$newdirs"; then + newdirs=`$echo "X$deplib" | $Xsed -e s%-L%%` + newdependency_libs="$newdependency_libs $deplib" + else + for i in $newdirs /..; do + libdir=`expr $deplib : ".*\($i\)"` + if test "$libdir" = "$i"; then + break + fi + done + if test "$i" = /..; then + newdependency_libs="$newdependency_libs $deplib" + fi + fi ;; *) newdependency_libs="$newdependency_libs $deplib" ;; esac We do some other things differently as well, but this is the most relevant for what you're looking for. This patch prevents libtool libraries from being replaced by their current absolute pathnames. It also tries to eliminate redundant "-L/path" specifications. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support > -Original Message- > From: [EMAIL PROTECTED] [mailto:libtool-admin@;gnu.org]On Behalf Of > Frederic Gobry > Sent: Wednesday, October 23, 2002 9:00 AM > To: [EMAIL PROTECTED] > Subject: library relocation > > > Hello, > > I'm working on linux based embedded platforms. To build a complete > platform, we usually compile and install our software packages in a > directory that is specific to each developer, say: > > /home/fred/frozen/usr/lib/... > > Then, the compiled libraries and executables that must be actually > available on the final platform are manipulated so that they finally > appear in > >/usr/lib/... > > ...when the platform has booted. > > Here comes the problem: > > - Scenario 1: a library (let say glib) is configured with the final > prefix (/usr) and installed for instance with a make install > DESTDIR=/home/fred/ > > Then, a program that uses the library will link with sth like > > -L/home/fred/frozen/lib -lglib > > Unfortunately, libtool (1.4.2a) will transform this into... > > /usr/lib/libglib.so > > Grr. This is not a library compiled for the same architecture. > > - Scenario 2: the library is directly configured to get installed in > /home/fred/... > > Then, the linking will be performed correctly, but a wrong rpath > will be added in the executable... > > Do you know a better method ? > Thank, > > Frédéric > > -- > Frédéric GobrySMARTDATA > --- http://www.smartdata.ch > Software Engineer Lausanne - Switzerland > +41 21 693 84 98 > > ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
RE: library relocation
Looks interesting. I have a solution for AIX and HP-UX as well but those diffs are slightly more involved. First, instead of directly linking all .lo files into the .so library, I use ld -r to combine all .lo files into a single object file. (Do this for all platforms, unconditionally.) This single object file is used to create both the intermediate/working and final/installed shared library. This approach saves a lot of time when it comes to the relinking step, especially with AIX's linker. The next step is ugly: we use the appropriate options to embed the desired library search path, and then to avoid any undesired -L paths from being embedded, I symlink any missing -L dependent libraries into the target directory, cd to the target directory and link from there, using "-L." in the final link. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support > -Original Message- > From: [EMAIL PROTECTED] [mailto:libtool-admin@;gnu.org]On Behalf Of > Paul E Johnson > Sent: Wednesday, October 23, 2002 9:22 AM > To: Frederic Gobry; [EMAIL PROTECTED] > Subject: Re: library relocation > > > I think the DESTDIR patch for ltmain.sh fixes that. At least > it did for > me. I had the problem that relinking was failing with "make > prefix=/blah > install" so I retooled with DESTDIR and with this patch > everything seems > OK. I found this through a bugs page for libtool, but I > can't find that > page now. > > But I do still have the patch address: > > http://mail.gnu.org/pipermail/bug-libtool/2002-February/003019.html > > Frederic Gobry wrote: > > Hello, > > > > I'm working on linux based embedded platforms. To build a complete > > platform, we usually compile and install our software packages in a > > directory that is specific to each developer, say: > > > > /home/fred/frozen/usr/lib/... > > > > Then, the compiled libraries and executables that must be actually > > available on the final platform are manipulated so that they finally > > appear in > > > >/usr/lib/... > > > > ...when the platform has booted. > > > > Here comes the problem: > > > > - Scenario 1: a library (let say glib) is configured with > the final > > prefix (/usr) and installed for instance with a make install > > DESTDIR=/home/fred/ > > > > Then, a program that uses the library will link with sth like > > > > -L/home/fred/frozen/lib -lglib > > > > Unfortunately, libtool (1.4.2a) will transform this into... > > > > /usr/lib/libglib.so > > > > Grr. This is not a library compiled for the same architecture. > > > > - Scenario 2: the library is directly configured to get > installed in > > /home/fred/... > > > > Then, the linking will be performed correctly, but a wrong rpath > > will be added in the executable... > > > > Do you know a better method ? > > Thank, > > > > Frédéric > > > > > > -- > Paul E. Johnson email: [EMAIL PROTECTED] > Dept. of Political Sciencehttp://lark.cc.ku.edu/~pauljohn > 1541 Lilac Lane, Rm 504 > University of Kansas Office: (785) 864-9086 > Lawrence, Kansas 66044-3177 FAX: (785) 864-5700 > > > > ___ > 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: Hiding the --finish "installed in" message
libtool --finish blah blah blah 1>&2 2>/dev/null -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: rboehne AT ricardo-us DOT com ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: library relocation
Hello, The real problem is that ELF platforms shouldn't ever relink, because it isn't necessary and it causes problems like these. If I get a patch against CVS head to do this, that means I won't have to make one myself, and it will get checked in sooner. Any volunteers? -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: rboehne AT gnu DOT org ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Libtool 1.4.3 Released
We're pleased to announce the release of Libtool 1.4.3! This is a patch release, the last one in the 1.4.x series, and is compatable with Autoconf 2.13. You can find the new release here: in tarball, ftp://ftp.gnu.org/gnu/libtool/libtool-1.4.3.tar.gz xdelta, ftp://ftp.gnu.org/gnu/libtool/libtool-1.4.2-1.4.3.tar.xdp.gz and diff formats. ftp://ftp.gnu.org/gnu/libtool/libtool-1.4.2-1.4.3.diff Coming soon to a GNU mirror near you! http://www.gnu.org/order/ftp.html Please report bugs to <[EMAIL PROTECTED]>. Thanks again to all those who contributed. Robert Boehne ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Deprecate AC_LIBTOOL_WIN32_DLL?
When the AC_LIBTOOL_WIN32_DLL macro was originated, it was necessary to add dllexport decorations to library source code in order to build a DLL. When AC_LIBTOOL_WIN32_DLL was added to configure.in, it enabled a few Windows specific tests, but most importantly, it enabled building libraries as DLLs. Due to binutils enhancements made in the past two years, both Cygwin and MinGW are able to build DLLs without dllexport decorations. In my opinion, this makes AC_LIBTOOL_WIN32_DLL obsolete. The few remaining functions from this macro can be moved elsewhere in libtool.m4 so that packages can automatically support building DLLs. Comments? Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Deprecate AC_LIBTOOL_WIN32_DLL?
When the AC_LIBTOOL_WIN32_DLL macro was originated, it was necessary to add dllexport decorations to library source code in order to build a DLL. When AC_LIBTOOL_WIN32_DLL was added to configure.in, it enabled a few Windows specific tests, but most importantly, it enabled building libraries as DLLs. Due to binutils enhancements made in the past two years, both Cygwin and MinGW are able to build DLLs without dllexport decorations. In my opinion, this makes AC_LIBTOOL_WIN32_DLL obsolete. The few remaining functions from this macro can be moved elsewhere in libtool.m4 so that packages can automatically support building DLLs. On cygwin, it is completely unnecessary *now* (with latest autoconf, automake, and CVS libtool). The following are sufficient to build DLLs -- no need for any "definitions" to be migrated, AFAIK. At least for cygwin. configure.ac -- AC_INIT(cdll.c) AC_PREREQ(2.52) AM_INIT_AUTOMAKE(dllhelpers-c_autotools, 0.4.0) AC_PROG_CC AM_PROG_LIBTOOL AC_HEADER_STDC AC_OUTPUT([Makefile]) --- Makefile.am --- INCLUDES = -I$(top_builddir) -I$(builddir) -I$(top_srcdir) -I$(srcdir) pkginclude_HEADERS = cdll.h lib_LTLIBRARIES = libcdll.la libcdll_la_SOURCES = cdll.c libcdll_la_LDFLAGS = -version-info 1:0:1 -no-undefined bin_PROGRAMS= usedll usedll_SOURCES = usedll.c usedll_LDADD= libcdll.la The one remaining niggle is this: you *must* specify -no-undefined, or libtool won't even attempt to build a DLL. Yes, it's true that for windows platforms you are not allowed to have any undefined symbols in shared libs (DLLs). But, the requirement that you must actually specify, so to speak, "I hereby represent that the designated source files to be used to build the shared library do not have any undefined symbols" is kinda redundant. either it'll work -- in which case "-no-undefined" was correct, and there WERE no undefined symbols, and you get a DLL. Or it'll fail -- the linker will report that there were "undefined symbols" and you get no DLL. So why bother with requiring the -no-undefined flag? It seems a waste of time to me... But anyway, -no-undefined is a whole separate issue. As far as AC_LIBTOOL_WIN32_DLL, from the cygwin perspective it can be killed. However, given that there are a lot of projects out there that probably have it in their configure.in's already, perhaps you should leave a dummy (empty) definition? Or is that not kosher libtool procedure? --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
