On Mon, 15 Nov 2004, Gary V. Vaughan wrote:
Bob Friesenhahn wrote:
Doesn't this patch cause Linux to be more equal than other operating systems, thereby causing free applications to be developed which won't work anywhere else?
No, it just shortens the link line on platforms that support that.
The point of my statement is that many applications are developed solely under Linux, but the authors expect them to be portable because they use autotools and standard APIs. It seems that the shortened link line will allow developers to not list the dependencies which are necessary on some other platforms.
That's not what I mean at all. The call to libtool will be exactly the same. Holding up my horrid gdiplus example again, with or without this change the user will call libtool like this:
libtool --mode=link gcc -o app obj.o /opt/libgdiplus10/lib/libgdiplus.la
On a linker that can't handle deplibs unaided, libtool will run:
gcc -o app obj.o \ /opt/libgdiplus10/lib/libgdiplus.so \ -L/opt/libttf21/lib -L/opt/zlib11/lib -L/opt/gettext014/lib \ -L/opt/libglib24/lib -L/opt/libiconv19/lib \ /opt/libglib24/lib/libglib-2.0.so \ /opt/gettext014/lib/libintl.so \ /opt/libiconv19/lib/libiconv.so \ -L/opt/cairo02/lib -L/opt/fcpackage22/lib -L/usr/X11R6/lib \ -L/opt/libpixman01/lib -L/opt/libpng12/lib \ /opt/libcairo02/lib/libcairo.so \ -L/opt/libexpat12/lib \ /opt/fcpackage22/lib/libfontconfig.so \ /opt/libexpat12/lib/libexpat.so \ /opt/libpixman01/lib/libpixman.so \ /opt/fcpackage22/lib/libXrender.so -lXext /opt/libttf21/lib/libfreetype.so \ -L/opt/libtiff35/lib -ltiff \ -L/opt/libjpeg6b/lib /opt/libjpeg6b/lib/libjpeg.so \ -L/opt/libungif41/lib /opt/libungif41/lib/libungif.so -lX11 /opt/libpng12/lib/libpng.so -lm \ /opt/zlib11/lib/libz.so -lpthread \ -Wl,-rpath -Wl,/opt/libgdiplus10/lib \ -Wl,-rpath -Wl,/opt/libglib24/lib \ -Wl,-rpath -Wl,/opt/gettext014/lib \ -Wl,-rpath -Wl,/opt/libiconv19/lib \ -Wl,-rpath -Wl,/opt/libcairo02/lib \ -Wl,-rpath -Wl,/opt/fcpackage22/lib \ -Wl,-rpath -Wl,/opt/libexpat12/lib \ -Wl,-rpath -Wl,/opt/libpixman01/lib \ -Wl,-rpath -Wl,/opt/libttf21/lib \ -Wl,-rpath -Wl,/opt/libjpeg6b/lib \ -Wl,-rpath -Wl,/opt/libungif41/lib \ -Wl,-rpath -Wl,/opt/libpng12/lib \ -Wl,-rpath -Wl,/opt/zlib11/lib
But where the linker can already do this work, libtool will issue:
gcc -o app obj.o \ /opt/libgdiplus10/lib/libgdiplus.so \ -Wl,-rpath -Wl,/opt/libgdiplus10/lib
From the outside, nothing changes. Except that libtool trusts you to have linked your deplibs properly.
The result of this is more applications which don't compile and link outside of Linux. There are an abundance of new Linux programmers for which Linux is the new "Windows" (single operating system mentality) and have not bought into the open systems concept. Given that these programmers don't have experience with any other Unix system, and are unlikely to test on other systems, it is useful if libtool helps aid/enforce portability by any means available.
I get the feeling we're talking past each other here a little. Am I missing your point somehow?
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
