Re: TODO 2.x: Using libtool 2.0 in autoconf tests
* Sander Niemeijer wrote on Wed, Aug 24, 2005 at 10:54:53AM CEST: I would appreciate it if an item could be added to the TODO list for the new 2.x branch that solves the issue discussed in the following thread from about a year ago: http://lists.gnu.org/archive/html/libtool/2004-11/msg00372.html This issue _has_ been fixed! :))) Oooh excellent! Thanks a bunch for addressing this! http://lists.gnu.org/archive/html/libtool-patches/2005-08/msg00103.html Sorry for not putting your name into the ChangeLog entry as bug reporter. (There might be a specific bug lingering with the usage of LT_OUTPUT -- I am experimenting with it at the moment.) Cheers, Ralf Best regards, Sander ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO 2.x: Using libtool 2.0 in autoconf tests
Hi Sander,
On 24 Aug 2005, at 09:54, Sander Niemeijer wrote:
I would appreciate it if an item could be added to the TODO list
for the new 2.x branch that solves the issue discussed in the
following thread from about a year ago:
http://lists.gnu.org/archive/html/libtool/2004-11/msg00372.html
No need, it is recently fixed!
http://lists.gnu.org/archive/html/libtool-patches/2005-08/msg00099.html
Cheers,
Gary.
--
Gary V. Vaughan ())_. gary@
{lilith.warpmail.net,gnu.org},[EMAIL PROTECTED]
Research Scientist ( '/ http://www.tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/{libtool,m4}
Technical Author `(_~)_ http://sources.redhat.com/autobook
PGP.sig
Description: This is a digitally signed message part
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO 2.x: Using libtool 2.0 in autoconf tests
Hi Sander, * Sander Niemeijer wrote on Wed, Aug 24, 2005 at 10:54:53AM CEST: > I would appreciate it if an item could be added to the TODO list for > the new 2.x branch that solves the issue discussed in the following > thread from about a year ago: > > http://lists.gnu.org/archive/html/libtool/2004-11/msg00372.html This issue _has_ been fixed! :))) http://lists.gnu.org/archive/html/libtool-patches/2005-08/msg00103.html Sorry for not putting your name into the ChangeLog entry as bug reporter. (There might be a specific bug lingering with the usage of LT_OUTPUT -- I am experimenting with it at the moment.) Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
TODO 2.x: Using libtool 2.0 in autoconf tests
I would appreciate it if an item could be added to the TODO list for the new 2.x branch that solves the issue discussed in the following thread from about a year ago: http://lists.gnu.org/archive/html/libtool/2004-11/msg00372.html Best regards, Sander Niemeijer ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO for 2.x
Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Mon, Aug 22, 2005 at 10:00:50PM CEST: Is there a public record of these? TODO file? Search string for the list archives? next mail in this thread? ;-) The following is not very well ordered, not very well cross-referenced, has nonempty overlap with the in-tree TODO file (sorry), is not complete (complain!), and some items served mainly as reminders for me so far. I might add some URLs and replace the MsgIDs if you put this in an editable format. Most applies to branch-2-0/HEAD or all branches. branch-1-5 only issues are denoted as such. Cool! Thanks Ralf! :-D (Alternatively: Gary, how about a publicly editable version of this?) Like this? http://tkd.kicks-ass.net/WebWiki/GnuLibtoolProject/RoadMap If I've set things up properly, you will need to click the Login link at the top of that page, and create yourself a homepage before you will be allowed to edit anything. Ofcourse, you could have done this yourself... everything under WebWiki is just a regular wiki now :-) 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 ___ http://lists.gnu.org/mailman/listinfo/libtool
TODO for 2.x (was: branch-2-0 vs CVS HEAD)
* Gary V. Vaughan wrote on Mon, Aug 22, 2005 at 10:00:50PM CEST: > > Is there a public record of these? TODO file? Search string for the > list archives? next mail in this thread? ;-) The following is not very well ordered, not very well cross-referenced, has nonempty overlap with the in-tree TODO file (sorry), is not complete (complain!), and some items served mainly as reminders for me so far. I might add some URLs and replace the MsgIDs if you put this in an editable format. Most applies to branch-2-0/HEAD or all branches. branch-1-5 only issues are denoted as such. STOP! Yes, you, right there! Before you comment on specific items below or add new ones: Please adjust the Subject: accordingly, and keep specific issues in their subthreads! Not another monster thread where information is not to be found again! (Alternatively: Gary, how about a publicly editable version of this?) Cheers, Ralf regressions === - use AH_HEADER (when Autoconf has it) so we are compatible to both 2.59 and CVS, and do not use private and wrong macros which break on ltdl-using client packages. pending. - fix `make install' and ltdl files timestamps. pending. - Fix LTDL_CONVENIENCE and STATIC/SHARED stuff! (mails by Akim, Albert) - Does the client need argz.m4? Only if libtoolize --ltdl? - win32-dll issue: is this the correct patch? http://lists.gnu.org/archive/html/libtool/2005-03/msg00158.html - fix func_show_eval (or something along the way) shows not what is correctly executed (see $NM -BCpg on AIX). minor bug, description pending. - double elements in configure --help (I may removed (the wrong?) one in a patch against configure.ac) - we define LT_OBJDIR unconditionally for client sources, but don't need to (only for ltdl). - Peter Ekberg: m4_require(_LT_TAG_COMPILER) in LT_PATH_NM. minor bug, fix pending. non-system dependent - Use a better bug tracking system than this stupid list + mail folder. - LTDL_INIT/LT_WITH_LTDL: document, allow optional AC_CONFIG_SUBDIRS. - fix order of macros for non-C++ users of HIDDEN_DEPLIBS: _LT_SYS_HIDDEN_LIBDEPS is at broken position in _LT_LANG_FC_CONFIG and F77 should be after _LT_LINKER_SHLIBS because output_verbose_link.. - allow --prefer-duplicate-deps after $CC - fix Keith Packard's "different SONAME" patch; test, apply - Derek Price: allow spaces in paths. find a way to get this without breaking compatibility! - deplink DESTDIR install failure. related: destdir rpath [EMAIL PROTECTED] - relink outside build tree (below DESTDIR/prefix?) - relink even less often when possible - check whether the temp rpath fix leaves cwd (`.') in LD_LIBRARY_PATH - do not leave build-tree references in installed .la files if not all libs are libtool-created (GCC!) (technically a limitation) - fix java m4 section, seriously broken - write test for $ in filenames, allow $ in object names - implement --quiet --quiet (no output) - s/EOF/_LTEOF/ in our macros (ltdl.m4). pending. - fix LN_S use. pending. - fix use of `#' in Makefiles system-dependent - Fix the Solaris CC -no-undefined issue _right_. - C++ with templates need work (basic support in HEAD only) for: Solaris (-xar?), IRIX (see post from Albert), others - Ralf Menzel: branch-2-0 rebootstrap? (Solaris issue? Maybe already fixed?) - Detect & shortcut RANLIB if possible, use `ar -S' with piecewise archive linking, if it works (see message by Alexandre Oliva) - Fix static libltdl using dlopen on some BSD versions (reported by Guilhem Lavaux) - Fix AIX -dlopen "self" - make link-order SKIP or work on AIX. - AIX .funcname() problem. Need a testcase. [EMAIL PROTECTED] (maybe fixed in branch-2-0?) - backport AIX fixes to branch-1-5. - hide AIX chmod warning. pending. - Dan Stromberg: improve AIX support. - Work around some weird issues with non-GNU `make' triggering autotools reruns (seen on cygwin and mingw). - mingw mdemo failures pending: Peter Ekberg's patches [EMAIL PROTECTED] [EMAIL PROTECTED] - fix lt_error_strings on mingw more general: kill all non-function interfaces! (also those in symbols-list-object!) - cygwin -export-dynamic + -export-symbols failure. [EMAIL PROTECTED] - fix stresstest failures on cygwin/mingw - have cwrapper fail if exec fails (look at gettext diff against libtool, has more changes.) - test, apply MSVC support discuss naming scheme lib$name vs $name see also e.g. https://sourceforge.net/forum/message.php?msg_id=3303527 - forward port Interix patch, test, apply - Tru64: work around shell bugs when executing `libtool' (branch-2-0/HEAD) - Fix F77/FC support for ifort/ifc -static - Fix finding icc/icpc rules when -no-gcc is not given - Fix some weird compile/link behavior (reported by Jeremie Le Hen) - Kill pass_all on many systems! But also improve library search algo
Re: real short TODO summary
Gary V. Vaughan wrote: Do you want me to copy it into CVS TODO? Sure, you'd probably make a better job of it than me :) Thanks, Peter -- Peter O'Gorman - http://www.pogma.com ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: real short TODO summary
Gary V. Vaughan wrote: Peter O'Gorman wrote: libtool todo list > [[snip]] Rewrite everything in perl, and use xml and xslt just to annoy Gary. I quit! But seriously, thanks for working through that convoluted thread! I owe you a(nother) beer. Do you want me to copy it into CVS TODO? 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
Re: real short TODO summary
Peter O'Gorman wrote: libtool todo list > [[snip]] Rewrite everything in perl, and use xml and xslt just to annoy Gary. I quit! -- 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
Re: real short TODO summary
* Peter O'Gorman wrote on Sat, Nov 27, 2004 at 04:14:46PM CET: > > Support dlmopen dladdr1 and dlinfo in libltdl [I totally disagree with > this one Ralf, libltdl is a portability library, none of these functions > enhance portability in any way] Just throw this out then! I just mentioned them because I saw them. BTW, I still think dlinfo could maybe help resolve the `cross compile on linux problem' in part, mentioned in Daniel Reed's RFC (and part of this problem in libtool is linux-specific). But I have not looked at it yet. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
real short TODO summary
libtool todo list
Sort out the macro mess in libtool.m4. We've started this already
by refactoring chunks into separate files, but I never did completely
untangle the mess of macros imported from ltconfig.
Finish the rewrite of the core libltdl. The loaders are fine, and
the outlying code is now good. Ralf is starting to pick away at a lot
of the remaining nasties already, but the code for finding .la/.so files
and reading/loading them could use a lot more improvement.
Get rid of the shared libdlloader.
I think we could factor out a little path management support module
from existing libltdl. This would be useful for M4 at least -- keeping
track of FOO_PATH environment contents, searching for files in paths
etc.
Figure out how to make pkg-config aware of the information libtool knows
about libraries and their dependencies, and send a patch.
Work out what to do when the dynamic linker loads needed dependencies.
{Ralf is looking now}
Look again at a binary C libtool, or byte-compiled libtool to improve speed.
Generate some "platform specific" shell functions with config.status,
for example, there is no need to have the C source code for the wrapper
script on non-windows platforms, this will make the generated libtool
script smaller and easier to follow, maybe a little faster too?
Fix cross-compiling.
Fix threads.
Change libltdl interface: add separate functions for function
pointers. This will allow porting to systems where function pointers
are incompatible with data pointer C-wise.
Support multilibbing.
Automake - unifying locks between libtool and compile.
Automake - Eeek! Fix relinking.
Support dlmopen dladdr1 and dlinfo in libltdl [I totally disagree with
this one Ralf, libltdl is a portability library, none of these functions
enhance portability in any way]
Add i18n strings to libltdl, ensuring that package developers can ignore
any i18n when they libtoolize.
Test everything:
cross compile
dirs with ~
automake subdirs
Rewrite everything in perl, and use xml and xslt just to annoy Gary.
Dropped:
Generate a libtool.m4 from a bunch of individual file, one per platform,
to make the job of a "platform maintainer" easier and make it easier to
add new platforms. [ Unless I suddenly see a way to do it "cleanly" ]
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
Bob Friesenhahn wrote: On Wed, 10 Nov 2004, Gary V. Vaughan wrote: It wouldn't be at all difficult to have 'libtoolize --ltdl --disable-nls' install a non-internationalised libltdl minus message catalogues into a parent package. But yes, we would have to take care to do it carefully. An improved post-2.0 testsuite should help there :-) There are oodles of dangers here. For example, a package distribution maintainer for a particular OS may not agree with the package developer's choices so he will install his own libltdl with the extra message catalogues. This could make things very confusing/difficult for the package developer. There is already plenty of confusion caused by package distribution maintainers who replace the existing libtool in a package with one that they prefer. So you think it's a problem that (a) the project maintainer can choose to ship a non-internationalised libltdl with their project, and then (b) a system integrator chooses to link against an internationalised libltdl? Any sensible project maintainer will ship i15d libltdl with their i15d package, or non-i15d libltdl with their non-i15d package. If some-one chooses to mix and match, they are beyond our help! If the project maintainer stupidly `libtoolize --ltdl --disable-nls' installs libltdl in their i15d package, and a systems integrator chooses to fix it by relibtoolizing --enable-nls to match the parent project, that's a good thing. If the integrator stupidly relibtoolized with a different option when the project maintainer shipped the correct libltdl, he is beyond our help too. On the flip side, the package developer may choose to distribute an internationalized libltdl, which causes new issues for end-users and package distribution maintainers. I fail to see the problem... but it is 2am... 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
Re: TODO
On Wed, Nov 17, 2004 at 08:58:35AM +0100, Ralf Wildenhues wrote: > * Jacob Meuser wrote on Wed, Nov 17, 2004 at 01:07:20AM CET: > > On Tue, Nov 16, 2004 at 11:00:34PM +, Scott James Remnant wrote: > > > On Tue, 2004-11-16 at 11:15 -0800, Jacob Meuser wrote: > > > > On Tue, Nov 16, 2004 at 03:02:55PM +, Scott James Remnant wrote: > > > > > Actually, I'd say the opposite is true ... the LONGER link line, > > > > > produced by the current Libtool, is what allows people to get away > > > > > with > > > > > this because Libtool puts more stuff into the link line. > > > > > > > > > > A shorter, more concise, link line actually forces people to make sure > > > > > they *do* link anything they require themselves, rather than relying > > > > > on > > > > > Libtool to do the right thing for them. > > > > > > > > but where does the problem show up? on !Linux, because Linux will > > > > "do the right thing". > > > > > > > No, on Linux ... because Linux does the right thing and causes the > > > applications to break; whereas Libtool does the wrong thing and links > > > the application directly with half the libraries on the system. > > > > from my understanding, correct me if I'm wrong, > > Can you also be bothered to read > [EMAIL PROTECTED] again? > For archive users, that is message > http://lists.gnu.org/archive/html/libtool/2004-11/msg00319.html I think understand the problem there. deplibs that shouldn't be specified are picked up from .la files. > > on Linux, to the linker, all library deplibs do not need to be > > specified > > ACK. > > > on other systems, to the linker, all library deplibs do need to be > > specified. > > On some other systems. yes, of course, not all other systems. > > libtool is to handle this transparently, just specify the library, > > and, if needed, libtool will add the deplibs. > > That's what libtool does for every system right now, not only if needed. yes, I understand that. > Scotts keybuk-linux-deplibs.patch would change this behavior on linux. yes, I understand that. > > am I right so far? > > I think so. > > > so when libtool fails to complete the deplibs (I still haven't seen > > any explanation for what happens when one of the deplibs is a > > non-libtool library), where is there breakage? not on Linux, because > > it doesn't need the deplibs anyway. > > No breakage. Developer education: "There exist other systems with > linkers that need dependencies explicitly specified." right, but, as Bob pointed out, there is a new generation of coders who only use Linux. why would they care about other systems? how would they know what does need to be explicitly specified, and what shouldn't be specified? what happens when a deplib that has other deplibs is not a libtool library? for example, on BSD systems, the base libraries are not built with libtool, but on Linux distros, a good part of the base libraries are built with libtool. > This education method is not foolproof, however, thus the proposed > change. the change to not have libtool not expand deplibs on Linux is not what I'm arguing about. telling people to not specify deplibs is the problem. it wouldn't be a problem if all libraries on a system were built with libtool, but that is not the case, especially on !Linux. > > how would linux cause the application to break if there was a deplib > > explicitly specified? > > Read the message above. wouldn't that be a problem on any system? since the proposed change only affects systems that don't need deplibs specified, doesn't the same problem remain on systems that do need proper deplibs specified, since libtool will continue to do what it has always done? so, if this fixes a libtool issue on systems that the libtool developers use, what is the motivation to fix the exact same issue for other systems? is this bug deep in libtool left for users of systems that don't have linker dependency resolution to figure out? > Regards, > Ralf -- <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
* Jacob Meuser wrote on Wed, Nov 17, 2004 at 01:07:20AM CET: > On Tue, Nov 16, 2004 at 11:00:34PM +, Scott James Remnant wrote: > > On Tue, 2004-11-16 at 11:15 -0800, Jacob Meuser wrote: > > > On Tue, Nov 16, 2004 at 03:02:55PM +, Scott James Remnant wrote: > > > > Actually, I'd say the opposite is true ... the LONGER link line, > > > > produced by the current Libtool, is what allows people to get away with > > > > this because Libtool puts more stuff into the link line. > > > > > > > > A shorter, more concise, link line actually forces people to make sure > > > > they *do* link anything they require themselves, rather than relying on > > > > Libtool to do the right thing for them. > > > > > > but where does the problem show up? on !Linux, because Linux will > > > "do the right thing". > > > > > No, on Linux ... because Linux does the right thing and causes the > > applications to break; whereas Libtool does the wrong thing and links > > the application directly with half the libraries on the system. > > from my understanding, correct me if I'm wrong, Can you also be bothered to read [EMAIL PROTECTED] again? For archive users, that is message http://lists.gnu.org/archive/html/libtool/2004-11/msg00319.html > on Linux, to the linker, all library deplibs do not need to be > specified ACK. > on other systems, to the linker, all library deplibs do need to be > specified. On some other systems. > libtool is to handle this transparently, just specify the library, > and, if needed, libtool will add the deplibs. That's what libtool does for every system right now, not only if needed. Scotts keybuk-linux-deplibs.patch would change this behavior on linux. > am I right so far? I think so. > so when libtool fails to complete the deplibs (I still haven't seen > any explanation for what happens when one of the deplibs is a > non-libtool library), where is there breakage? not on Linux, because > it doesn't need the deplibs anyway. No breakage. Developer education: "There exist other systems with linkers that need dependencies explicitly specified." This education method is not foolproof, however, thus the proposed change. > how would linux cause the application to break if there was a deplib > explicitly specified? Read the message above. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Tue, Nov 16, 2004 at 11:00:34PM +, Scott James Remnant wrote: > On Tue, 2004-11-16 at 11:15 -0800, Jacob Meuser wrote: > > > On Tue, Nov 16, 2004 at 03:02:55PM +, Scott James Remnant wrote: > > > Actually, I'd say the opposite is true ... the LONGER link line, > > > produced by the current Libtool, is what allows people to get away with > > > this because Libtool puts more stuff into the link line. > > > > > > A shorter, more concise, link line actually forces people to make sure > > > they *do* link anything they require themselves, rather than relying on > > > Libtool to do the right thing for them. > > > > but where does the problem show up? on !Linux, because Linux will > > "do the right thing". > > > No, on Linux ... because Linux does the right thing and causes the > applications to break; whereas Libtool does the wrong thing and links > the application directly with half the libraries on the system. from my understanding, correct me if I'm wrong, on Linux, to the linker, all library deplibs do not need to be specified on other systems, to the linker, all library deplibs do need to be specified. libtool is to handle this transparently, just specify the library, and, if needed, libtool will add the deplibs. am I right so far? so when libtool fails to complete the deplibs (I still haven't seen any explanation for what happens when one of the deplibs is a non-libtool library), where is there breakage? not on Linux, because it doesn't need the deplibs anyway. how would linux cause the application to break if there was a deplib explicitly specified? -- <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Tue, 2004-11-16 at 11:15 -0800, Jacob Meuser wrote: > On Tue, Nov 16, 2004 at 03:02:55PM +, Scott James Remnant wrote: > > Actually, I'd say the opposite is true ... the LONGER link line, > > produced by the current Libtool, is what allows people to get away with > > this because Libtool puts more stuff into the link line. > > > > A shorter, more concise, link line actually forces people to make sure > > they *do* link anything they require themselves, rather than relying on > > Libtool to do the right thing for them. > > but where does the problem show up? on !Linux, because Linux will > "do the right thing". > No, on Linux ... because Linux does the right thing and causes the applications to break; whereas Libtool does the wrong thing and links the application directly with half the libraries on the system. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Tue, Nov 16, 2004 at 09:10:00PM +0100, Ralf Wildenhues wrote: > * Jacob Meuser wrote on Tue, Nov 16, 2004 at 08:00:28PM CET: > > On Tue, Nov 16, 2004 at 03:01:06PM +, Scott James Remnant wrote: > > > On Mon, 2004-11-15 at 10:51 -0800, Jacob Meuser wrote: > > > > > > > On Mon, Nov 15, 2004 at 03:45:10PM +, Scott James Remnant wrote: > > > > > It does assume that all library dependencies are registered, yes. > > > > > This > > > > > has never been a problem, because we've never found any > > > > > Libtool-produced > > > > > library that doesn't have all dependencies registered. > > > > > > > > > > If this isn't the case, and at one time Libtool never registered all > > > > > of > > > > > the dependencies, we should check for that. Otherwise I don't see the > > > > > need -- we can assume sanity from our own output. > > > > > > > > for a long time, libtool did not handle -pthread properly. > > > > > > > It still doesn't, the current situation is a botch that produces the > > > right results but does it in the wrong way. Libraries should record > > > what compiler/linker flags they need (-pthread is not a dependency > > > library). > > > > record how? in the dependency_libs section of an .la file? you seem > > to be saying no, so then where? > > It's already in HEAD. Stored in inherited_linker_flags. > > > > > I can point to at least a few .la files on my system that do > > > > not have -pthread or even other required libraries registered. > > > > > > > I'd be quite shocked if the current version of Libtool produces > > > libraries with -pthread in dependency_libs; I specifically wrote the > > > patch to prevent that, because it causes a lot of problems. > > > > if -pthread is needed but missing, then I get errors about missing > > symbols, much like if a library is missing from the link command. > > Note that the patch in HEAD is not a complete solution to the problem. > It's not portable/right in general to only compile a library thread-safe > and not the entire application, or even compile against different thread > implementations (one library against one, the other against another). > All this probably cannot be solved by libtool, but some possible > problems can be warned about (this is not yet implemented). thanks for the update. I suppose I should probably start looking into the latest sources ... > Regards, > Ralf > -- <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
* Jacob Meuser wrote on Tue, Nov 16, 2004 at 08:00:28PM CET: > On Tue, Nov 16, 2004 at 03:01:06PM +, Scott James Remnant wrote: > > On Mon, 2004-11-15 at 10:51 -0800, Jacob Meuser wrote: > > > > > On Mon, Nov 15, 2004 at 03:45:10PM +, Scott James Remnant wrote: > > > > It does assume that all library dependencies are registered, yes. This > > > > has never been a problem, because we've never found any Libtool-produced > > > > library that doesn't have all dependencies registered. > > > > > > > > If this isn't the case, and at one time Libtool never registered all of > > > > the dependencies, we should check for that. Otherwise I don't see the > > > > need -- we can assume sanity from our own output. > > > > > > for a long time, libtool did not handle -pthread properly. > > > > > It still doesn't, the current situation is a botch that produces the > > right results but does it in the wrong way. Libraries should record > > what compiler/linker flags they need (-pthread is not a dependency > > library). > > record how? in the dependency_libs section of an .la file? you seem > to be saying no, so then where? It's already in HEAD. Stored in inherited_linker_flags. > > > I can point to at least a few .la files on my system that do > > > not have -pthread or even other required libraries registered. > > > > > I'd be quite shocked if the current version of Libtool produces > > libraries with -pthread in dependency_libs; I specifically wrote the > > patch to prevent that, because it causes a lot of problems. > > if -pthread is needed but missing, then I get errors about missing > symbols, much like if a library is missing from the link command. Note that the patch in HEAD is not a complete solution to the problem. It's not portable/right in general to only compile a library thread-safe and not the entire application, or even compile against different thread implementations (one library against one, the other against another). All this probably cannot be solved by libtool, but some possible problems can be warned about (this is not yet implemented). Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Tue, Nov 16, 2004 at 03:02:55PM +, Scott James Remnant wrote: > On Mon, 2004-11-15 at 17:19 -0600, Bob Friesenhahn wrote: > > > 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. > > > Actually, I'd say the opposite is true ... the LONGER link line, > produced by the current Libtool, is what allows people to get away with > this because Libtool puts more stuff into the link line. > > A shorter, more concise, link line actually forces people to make sure > they *do* link anything they require themselves, rather than relying on > Libtool to do the right thing for them. but where does the problem show up? on !Linux, because Linux will "do the right thing". -- <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Tue, Nov 16, 2004 at 03:01:06PM +, Scott James Remnant wrote: > On Mon, 2004-11-15 at 10:51 -0800, Jacob Meuser wrote: > > > On Mon, Nov 15, 2004 at 03:45:10PM +, Scott James Remnant wrote: > > > It does assume that all library dependencies are registered, yes. This > > > has never been a problem, because we've never found any Libtool-produced > > > library that doesn't have all dependencies registered. > > > > > > If this isn't the case, and at one time Libtool never registered all of > > > the dependencies, we should check for that. Otherwise I don't see the > > > need -- we can assume sanity from our own output. > > > > for a long time, libtool did not handle -pthread properly. > > > It still doesn't, the current situation is a botch that produces the > right results but does it in the wrong way. Libraries should record > what compiler/linker flags they need (-pthread is not a dependency > library). record how? in the dependency_libs section of an .la file? you seem to be saying no, so then where? > > I can point to at least a few .la files on my system that do > > not have -pthread or even other required libraries registered. > > > I'd be quite shocked if the current version of Libtool produces > libraries with -pthread in dependency_libs; I specifically wrote the > patch to prevent that, because it causes a lot of problems. if -pthread is needed but missing, then I get errors about missing symbols, much like if a library is missing from the link command. -- <[EMAIL PROTECTED]> > Scott > -- > Have you ever, ever felt like this? > Had strange things happen? Are you going round the twist? > ___ > Libtool mailing list > [EMAIL PROTECTED] > http://lists.gnu.org/mailman/listinfo/libtool ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Mon, 2004-11-15 at 10:51 -0800, Jacob Meuser wrote: > On Mon, Nov 15, 2004 at 03:45:10PM +, Scott James Remnant wrote: > > It does assume that all library dependencies are registered, yes. This > > has never been a problem, because we've never found any Libtool-produced > > library that doesn't have all dependencies registered. > > > > If this isn't the case, and at one time Libtool never registered all of > > the dependencies, we should check for that. Otherwise I don't see the > > need -- we can assume sanity from our own output. > > for a long time, libtool did not handle -pthread properly. > It still doesn't, the current situation is a botch that produces the right results but does it in the wrong way. Libraries should record what compiler/linker flags they need (-pthread is not a dependency library). > I can point to at least a few .la files on my system that do > not have -pthread or even other required libraries registered. > I'd be quite shocked if the current version of Libtool produces libraries with -pthread in dependency_libs; I specifically wrote the patch to prevent that, because it causes a lot of problems. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Mon, 2004-11-15 at 17:19 -0600, Bob Friesenhahn wrote: > 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. > Actually, I'd say the opposite is true ... the LONGER link line, produced by the current Libtool, is what allows people to get away with this because Libtool puts more stuff into the link line. A shorter, more concise, link line actually forces people to make sure they *do* link anything they require themselves, rather than relying on Libtool to do the right thing for them. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
* Gary V. Vaughan wrote on Mon, Nov 15, 2004 at 04:34:49PM CET: > > >+2004-03-28 Scott James Remnant <[EMAIL PROTECTED]> > >+ > >+* ltmain.in: The dynamic link loader on some platforms is able to > >+correctly traverse dependency trees, therefore when $link_all_deplibs > >+is set to 'no' don't add the contents of dependency_libs to the > >+link line to link a program. > >+* m4/libtool.m4 (AC_LIBTOOL_PROG_LD_SHLIBS) [linux*]: Linux is one > >+of those platforms, set link_all_deplibs to 'no' for both C++ and > >+other compilers. > >+* NEWS: Updated. > > Bob's second point needs addressing first, IMHO. I think the > -rpath stuff will come out in the wash provided we are careful. > > Either way, this is a deep change for HEAD only. Actually, because of the problem Daniel described in [EMAIL PROTECTED], I would consider this a bug in current libtool. If you use .la files, the problem exists, if you directly link to the .so, it doesn't. The failure might be silent. Sounds like a bug to me. BTW, precisely because Debian has used this for a long time, I think this change will have less problems than some of the other recent changes (versioned libtool installs come to mind). Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
* Howard Chu wrote on Mon, Nov 15, 2004 at 10:29:04PM CET: > Ralf Wildenhues wrote: > >* Gary V. Vaughan wrote on Mon, Nov 15, 2004 at 04:34:49PM CET: > > >>Also, what do we do about -rpath? We still need to encode the > >>runtime path to even the dropped deplib directories so that the > >>same library we linked with is picked up at runtime. > > >Erm, is this not handled in the depending library? (I have no idea, > >really, but I hoped this would be so.) > > This is definitely a sticky problem. We do builds that "install" to a > path that is different from their actual, final destination. I'm finding > that the rpath handling at various stages of a build tries to be too > smart for its own good. E.g., I have a build tree in my home directory > for a number of packages in ~/BLD, the ultimate destination is /opt/foo, > and everything is staged into ~/BLD/opt/foo. For files in the resulting > package that contain embedded RPATH/RUNPATHs, I only want "/opt/foo" > present in the binary, but I find a lot of instances of > "/home/hyc/BLD/opt/foo" that I have to squash by manually relinking. This sounds to me like a genuine bug in Libtool, *not* a structural limitation that cannot be overcome. Can you be bothered to provide a testcase which exposes this failure? Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Tue, Nov 16, 2004 at 12:00:09AM -0500, Daniel Reed wrote: > On 2004-11-15T20:33-0800, Jacob Meuser wrote: > ) their packages as soon as possible. besides, it is arguable that > ) libtool should be fairly well adapted to RedHat by default, the > ) 1.5 branch has been around for a while now, and you are still > ) shipping patches? > > Until 1.5.10, we were actually patching 5 different areas of functionality ;) > > The functionality provided by all but one of those patches has since been > integrated into [upstream] Libtool. great. I'm not sure why you feel the need to mention that. I never made any claim to the contrary. > > ) > (For that to make sense, keep in mind that, outside of the GNOME world, > the > ) > autotools are used primarily at packaging time, not build time. Having a > ) huh? how can autoconf, or automake, or libtool be used at packaging > ) time, and not build time? and even if you could, why? > > You do not need to have Autoconf installed to build an Autoconf-managed > package. Similarly, you do not need to have Libtool installed to build a > Libtool-managed library inside a libtoolized package, or to link against > already-installed Libtool-built libraries. yes, the autotools come with software. that is, they are distributed by many, many people. > This is not true of, for example (to continue picking on it ;), PKGConfig, > which needs at least a non-general-purpose, externally-installed executable > (pkg-config) to function. yes, it is distrubted by few. > > ) besides, the biggest problem (assuming that OS/distros understand the > ) reasons for not hacking autotools) is original distributors modifying > ) libtool parts that are distributed with their software. look and > > In this case, bug reports going to the developer would be correct. The > concern over having an operating system modify the Libtool it ships is that > bug reports caused by the operating system's changes would incorrectly go to > the developer, or to the GNU lists. no, it is that when someone develops a package on a system that does have the autotools installed, that package gets the autotools from the autotools that were installed on that system. therefore, if the OS is distributing a hacked libtool, that package is shipping a hacked libtool to every other system. if making all packages that use libtool work by updating the libtool package, that would be wonderful, but that is not the case :( for example, libtool-1.5.10 works quite well on MyPreferredOS, versions 1.4 <=> 1.5.6 though, have some serious issues. I installed the libtool-1.5.10 package on my MyPreferredOS system. I still have to patch lots of packages that use libtool stuff. in some cases this is not very easy, because they did not come with a vanilla libtool to begin with. now, who gets the error report? the MyPreferredOS people? the libtool people? the people distributing the package? the people distributing the libtool used to build the package? usually, it goes to the MyPreferredOS people, who really have nothing to do with it. how often do you think it goes up the line to the people who really need to know the problem? OTOH, it is very easy to figure out if a package is putting bad stuff into the package's .pc file, and I don't need to worry about messing up things down the line by hacking the pkg-config binary on my system. -- <[EMAIL PROTECTED]> > > -- > Daniel Reed <[EMAIL PROTECTED]> http://people.redhat.com/djr/ > http://naim.n.ml.org/ > I'd say some people have no lives, but I'm the one who's going to > wallpaper his room in naim source in a few days. -- FalseName, EFnet #naim > > > ___ > Libtool mailing list > [EMAIL PROTECTED] > http://lists.gnu.org/mailman/listinfo/libtool ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On 2004-11-15T20:33-0800, Jacob Meuser wrote: ) their packages as soon as possible. besides, it is arguable that ) libtool should be fairly well adapted to RedHat by default, the ) 1.5 branch has been around for a while now, and you are still ) shipping patches? Until 1.5.10, we were actually patching 5 different areas of functionality ;) The functionality provided by all but one of those patches has since been integrated into [upstream] Libtool. ) > (For that to make sense, keep in mind that, outside of the GNOME world, the ) > autotools are used primarily at packaging time, not build time. Having a ) huh? how can autoconf, or automake, or libtool be used at packaging ) time, and not build time? and even if you could, why? You do not need to have Autoconf installed to build an Autoconf-managed package. Similarly, you do not need to have Libtool installed to build a Libtool-managed library inside a libtoolized package, or to link against already-installed Libtool-built libraries. This is not true of, for example (to continue picking on it ;), PKGConfig, which needs at least a non-general-purpose, externally-installed executable (pkg-config) to function. ) besides, the biggest problem (assuming that OS/distros understand the ) reasons for not hacking autotools) is original distributors modifying ) libtool parts that are distributed with their software. look and In this case, bug reports going to the developer would be correct. The concern over having an operating system modify the Libtool it ships is that bug reports caused by the operating system's changes would incorrectly go to the developer, or to the GNU lists. -- Daniel Reed <[EMAIL PROTECTED]> http://people.redhat.com/djr/ http://naim.n.ml.org/ I'd say some people have no lives, but I'm the one who's going to wallpaper his room in naim source in a few days. -- FalseName, EFnet #naim ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Mon, Nov 15, 2004 at 07:36:21PM -0500, Daniel Reed wrote: > On 2004-11-15T17:19-0600, Bob Friesenhahn wrote: > ) system incrementally. There is also the point that the libtool which > ) comes with a Linux distribution has likely already been hacked to be > ) more lenient. If FSF libtool becomes more lenient by default, then > ) there likely little actual impact. > > Just to address that last comment: Red Hat has shipped patch-free Autoconf > since Red Hat Linux 8.0, patch-free Automake since Fedora Core 1, and will > hopefully be shipping a patch-free Libtool in Fedora Core 4. now perhaps, but in the past? not everyone updates the autotools in their packages as soon as possible. besides, it is arguable that libtool should be fairly well adapted to RedHat by default, the 1.5 branch has been around for a while now, and you are still shipping patches? now think about that in the context of a non-Linux system that the autotools developers don't regularly use. > > We do not modify these tools to work more effectively on Linux at the > expense of their support for other systems because, well, developers might > end up using them! And shipping software based on them. And, if and when > that software breaks, it would be the developer and/or the various @gnu.org > lists that get to figure out why (we would have been long disconnected from > the chain by that point). Time that could go into developing new features > and fixing real bugs would be wasted, so we lose. yes, that is how it should be, but history proves otherwise. > (For that to make sense, keep in mind that, outside of the GNOME world, the > autotools are used primarily at packaging time, not build time. Having a huh? how can autoconf, or automake, or libtool be used at packaging time, and not build time? and even if you could, why? besides, the biggest problem (assuming that OS/distros understand the reasons for not hacking autotools) is original distributors modifying libtool parts that are distributed with their software. look and you will find changes to make libtool act like it does on linux on other systems. does RedHat scrutinize all the autotool stuff in every SRPM and work to correct the issues? why would it, the changes don't affect RedHat. I'm not trying to pick on RedHat here, I wouldn't try to correct things that don't affect me either. -- <[EMAIL PROTECTED]> > Linux-optimized Libtool installed on a Linux machine is not likely to offer > any benefit to people building software from source, just people who are > packaging software to distribute.) > > > We also do not modify these tools to work more effectively on Linux without > affecting other systems because, well, such changes should be made upstream! > This change should be made here! (Or not at all.) > > (Retooling all of the software we ship to take advantage of custom > modifications to the build scripts really bogs down our build roots (and can > waste developer time, causing us to lose again). We primarily do it (retool) > now to take advantage of our multilib-aware Libtool.) > > -- > Daniel Reed <[EMAIL PROTECTED]> http://people.redhat.com/djr/ > http://naim.n.ml.org/ > The pursuit of pretty formulas and neat theorems can no doubt quickly > degenerate into a silly vice, but so can the quest for austere > generalities which are so very general indeed that they are incapable > of application to any particular. -- Eric Temple Bell, Mathematician > > > ___ > Libtool mailing list > [EMAIL PROTECTED] > http://lists.gnu.org/mailman/listinfo/libtool ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Mon, Nov 15, 2004 at 08:01:38PM -0600, Bob Friesenhahn wrote: > On Mon, 15 Nov 2004, Jacob Meuser wrote: > > > >but this only works is all the libraries have .la files, right? > >what happens if not all those libraries were built with libtool? > >how would libtool find the dependent libraries if there is no .la? > > That is a function of pkg-config. :-) > > >>From the outside, nothing changes. Except that libtool trusts you > >>to have linked your deplibs properly. > > > >generally, it's a good idea to list all dependent libraries, > >because it must be done on some systems. now if libtool starts > >saying "don't do this", then people will just not do it, whether > >they understand the issues involved or not. > > At least for libraries with .la files, libtool would silently drop the > extra dependencies (relying on the linker to add them) and would not > say "don't do this". I agree that typical developers react to error > messages and warnings, and may not spend enough time to understand all > the issues. well, by libtool I meant in the documentation, the examples, on this list, etc. but of course, most people don't read that stuff anyway :( -- <[EMAIL PROTECTED]> > Bob > == > Bob Friesenhahn > [EMAIL PROTECTED] > http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On 2004-11-15T19:27-0600, Bob Friesenhahn wrote: ) >> Yes. When you're making a distribution, Libtool's behaviour of directly ) >> linking indirect-dependencies is insane. For a SONAME change to a ) >> library deep in the stack, that only affects the library immediately ) >> above it, you suddenly need to rebuild your entire desktop environment. Iteration 1: libgeneral provides general_utility(). libadmiral provides admiral_electric() and admiral_water(). libcadet provides cadet_dance(), which uses general_utility() and admiral_electric(). service uses cadet_dance() and admiral_water() in its main(). libcadet is linked to libgeneral and libadmiral. service is linked to libcadet and libadmiral. The resulting service executable is indirectly linked to libgeneral to satisfy libcadet's dependency. Iteration 2: libcadet is changed to use libgeneral2's general2_utility(). service is now indirectly linked to libgeneral2 to satisfy libcadet's dependency, and libgeneral is no longer in use. (21:43)[EMAIL PROTECTED]:~/test> make service COMPILE=gcc LINK=gcc gcc libgeneral.c -c -o libgeneral.o gcc libgeneral.o -shared -o libgeneral.so gcc libadmiral.c -c -o libadmiral.o gcc libadmiral.o -shared -o libadmiral.so gcc libcadet.c -c -o libcadet.o gcc libcadet.o -shared -o libcadet.so -L. -Wl,-rpath,. -lgeneral -ladmiral gcc service.c -c -o service.o gcc service.o -o service -L. -Wl,-rpath,. -lcadet -ladmiral (21:44)[EMAIL PROTECTED]:~/test> ldd service libcadet.so => ./libcadet.so (0xf6ffe000) libadmiral.so => ./libadmiral.so (0xf6ffb000) libc.so.6 => /lib/tls/libc.so.6 (0x00703000) libgeneral.so => ./libgeneral.so (0xf6fd9000) /lib/ld-linux.so.2 (0x006ea000) (21:44)[EMAIL PROTECTED]:~/test> ./service main cadet_dance general_utility admiral_electric admiral_water (21:44)[EMAIL PROTECTED]:~/test> The base case is sane. (21:46)[EMAIL PROTECTED]:~/test> make service COMPILE="libtool --mode=compile gcc" LINK="libtool --mode=link gcc" libtool --mode=compile gcc libgeneral.c -c -o libgeneral.o mkdir .libs gcc libgeneral.c -c -fPIC -DPIC -o .libs/libgeneral.o gcc libgeneral.c -c -o libgeneral.o >/dev/null 2>&1 libtool --mode=link gcc libgeneral.o -shared -o libgeneral.so gcc libgeneral.o -shared -o libgeneral.so libtool --mode=compile gcc libadmiral.c -c -o libadmiral.o gcc libadmiral.c -c -fPIC -DPIC -o .libs/libadmiral.o gcc libadmiral.c -c -o libadmiral.o >/dev/null 2>&1 libtool --mode=link gcc libadmiral.o -shared -o libadmiral.so gcc libadmiral.o -shared -o libadmiral.so libtool --mode=compile gcc libcadet.c -c -o libcadet.o gcc libcadet.c -c -fPIC -DPIC -o .libs/libcadet.o gcc libcadet.c -c -o libcadet.o >/dev/null 2>&1 libtool --mode=link gcc libcadet.o -shared -o libcadet.so -L. -Wl,-rpath,. -lgeneral -ladmiral gcc libcadet.o -shared -o libcadet.so -Wl,-rpath -Wl,. -L/home/boston/dreed/test -lgeneral -ladmiral libtool --mode=compile gcc service.c -c -o service.o gcc service.c -c -fPIC -DPIC -o .libs/service.o gcc service.c -c -o service.o >/dev/null 2>&1 libtool --mode=link gcc service.o -o service -L. -Wl,-rpath,. -lcadet -ladmiral gcc service.o -o service -Wl,-rpath -Wl,. -L/home/boston/dreed/test -lcadet -ladmiral (21:46)[EMAIL PROTECTED]:~/test> ldd service libcadet.so => ./libcadet.so (0xf6ffe000) libadmiral.so => ./libadmiral.so (0xf6ffb000) libc.so.6 => /lib/tls/libc.so.6 (0x00703000) libgeneral.so => ./libgeneral.so (0xf6fd9000) /lib/ld-linux.so.2 (0x006ea000) (21:46)[EMAIL PROTECTED]:~/test> Looks good. Let's try iteration 2's change... (21:50)[EMAIL PROTECTED]:~/test> make service2 COMPILE="libtool --mode=compile gcc" LINK="libtool --mode=link gcc" libtool --mode=compile gcc libgeneral2.c -c -o libgeneral2.o gcc libgeneral2.c -c -fPIC -DPIC -o .libs/libgeneral2.o gcc libgeneral2.c -c -o libgeneral2.o >/dev/null 2>&1 libtool --mode=link gcc libgeneral2.o -shared -o libgeneral2.so gcc libgeneral2.o -shared -o libgeneral2.so libtool --mode=compile gcc libcadet2.c -c -o libcadet2.o gcc libcadet2.c -c -fPIC -DPIC -o .libs/libcadet2.o gcc libcadet2.c -c -o libcadet2.o >/dev/null 2>&1 libtool --mode=link gcc libcadet2.o -shared -o libcadet.so -L. -Wl,-rpath,. -lgeneral2 -ladmiral gcc libcadet2.o -shared -o libcadet.so -Wl,-rpath -Wl,. -L/home/boston/dreed/test -lgeneral2 -ladmiral (21:50)[EMAIL PROTECTED]:~/test> ldd service libcadet.so => ./libcadet.so (0xf6ffe000) libadmiral.so => ./libadmiral.so (0xf6ffb000) libc.so.6 => /lib/tls/libc.so.6 (0x00703000) libgeneral2.so => ./libgeneral2.so (0xf6fd9000) /lib/ld-linux.so.2 (0x006ea000) (21:50)[EMAIL PROTECTED]:~/test> ./service main cadet_dance general2_utility admiral_electric admiral_water (21:50)[EMAIL PROTECTED]:~/test> Still good. The service executable is no longer linked to libgeneral.so in any way and works as expected. Let's try "full blown" Libtool (using .la files)... (22:00)[EMAIL
Re: TODO
On Mon, 15 Nov 2004, Jacob Meuser wrote: but this only works is all the libraries have .la files, right? what happens if not all those libraries were built with libtool? how would libtool find the dependent libraries if there is no .la? That is a function of pkg-config. :-) From the outside, nothing changes. Except that libtool trusts you to have linked your deplibs properly. generally, it's a good idea to list all dependent libraries, because it must be done on some systems. now if libtool starts saying "don't do this", then people will just not do it, whether they understand the issues involved or not. At least for libraries with .la files, libtool would silently drop the extra dependencies (relying on the linker to add them) and would not say "don't do this". I agree that typical developers react to error messages and warnings, and may not spend enough time to understand all the issues. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Tue, Nov 16, 2004 at 01:20:58AM +, Gary V. Vaughan wrote: > Bob Friesenhahn wrote: > >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 this only works is all the libraries have .la files, right? what happens if not all those libraries were built with libtool? how would libtool find the dependent libraries if there is no .la? > 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. generally, it's a good idea to list all dependent libraries, because it must be done on some systems. now if libtool starts saying "don't do this", then people will just not do it, whether they understand the issues involved or not. -- <[EMAIL PROTECTED]> > >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 > ___ > Libtool mailing list > [EMAIL PROTECTED] > http://lists.gnu.org/mailman/listinfo/libtool ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Tue, 16 Nov 2004, Gary V. Vaughan wrote: 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 [ stuff removed ] From the outside, nothing changes. Except that libtool trusts you to have linked your deplibs properly. I understand that part. 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? Probably you are missing my point. My point is that it is useful if the build fails (or at least warns verbosely) if a dependency has not been specified to libtool that should have been. This ensures that the configure script, Makefile.am, and resulting Makefile, will be adequately complete because the Linux developer will see a problem. Without this, packages will be distributed which do not build on other platforms due to missing dependencies. I have already encountered packages (which use libtool) with this problem. In this case, the dependency specification which lists libraries which are picked up automatically is a bit like an ANSI C function prototype. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Mon, 15 Nov 2004, Joe Orton wrote: Yes. When you're making a distribution, Libtool's behaviour of directly linking indirect-dependencies is insane. For a SONAME change to a library deep in the stack, that only affects the library immediately above it, you suddenly need to rebuild your entire desktop environment. How does libtool know that the SONAME change only affects the library above it? What if there is a structure exposed through multiple levels of libraries or something like that? I can think of several cases where doing this by default in libtool would be unsafe. This is an important issue that needs to be carefully considered. Libtool itself has no way to know this. Distribution maintainers have to somehow know enough about how the software works that they don't accidentally break something. Or maybe they just wait until the users tell them the software doesn't work anymore. A somewhat related issue is if a library offers extra/different APIs if one of the libraries it optionally depends on is available. This is a case where a shared library is not completely compatible even though it uses the same name. If a library supporting fewer/different APIs is inserted in the place of a library supporting more APIs, then some dependent applications may fail. There should not usually be problem if applications stick to baseline APIs which do not care about the extra library. Do library maintainers test all dependent applications to ensure that none of them have broken due to replacing an existing library? Yet another issue is if two libraries depend on the same library, but of different versions. In this case there is a "deadly embrace" and problems unless there is some sort of symbol versioning (and maybe even if there *is* symbol versioning). Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
Bob Friesenhahn wrote: 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
Re: TODO
On 2004-11-15T17:19-0600, Bob Friesenhahn wrote: ) system incrementally. There is also the point that the libtool which ) comes with a Linux distribution has likely already been hacked to be ) more lenient. If FSF libtool becomes more lenient by default, then ) there likely little actual impact. Just to address that last comment: Red Hat has shipped patch-free Autoconf since Red Hat Linux 8.0, patch-free Automake since Fedora Core 1, and will hopefully be shipping a patch-free Libtool in Fedora Core 4. We do not modify these tools to work more effectively on Linux at the expense of their support for other systems because, well, developers might end up using them! And shipping software based on them. And, if and when that software breaks, it would be the developer and/or the various @gnu.org lists that get to figure out why (we would have been long disconnected from the chain by that point). Time that could go into developing new features and fixing real bugs would be wasted, so we lose. (For that to make sense, keep in mind that, outside of the GNOME world, the autotools are used primarily at packaging time, not build time. Having a Linux-optimized Libtool installed on a Linux machine is not likely to offer any benefit to people building software from source, just people who are packaging software to distribute.) We also do not modify these tools to work more effectively on Linux without affecting other systems because, well, such changes should be made upstream! This change should be made here! (Or not at all.) (Retooling all of the software we ship to take advantage of custom modifications to the build scripts really bogs down our build roots (and can waste developer time, causing us to lose again). We primarily do it (retool) now to take advantage of our multilib-aware Libtool.) -- Daniel Reed <[EMAIL PROTECTED]> http://people.redhat.com/djr/ http://naim.n.ml.org/ The pursuit of pretty formulas and neat theorems can no doubt quickly degenerate into a silly vice, but so can the quest for austere generalities which are so very general indeed that they are incapable of application to any particular. -- Eric Temple Bell, Mathematician ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
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. 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 do see that the explicit dependency list provided by libtool will cause severe problems for Linux maintainers who need to maintain the system incrementally. There is also the point that the libtool which comes with a Linux distribution has likely already been hacked to be more lenient. If FSF libtool becomes more lenient by default, then there likely little actual impact. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
> At first I thought that would be to absorb pkg-config's > functionality into libtool (to avoid duplication of code and > maintenance), Just in case somebody still ponders this, please take into account that pkg-config works even for people on Windows who use MSVC (the command-line tools, not the IDE), with no libtool or Unix-like functionality (shell scripts, Perl scripts) in sight at all. Not that I know if any MSVC users who use for instance GTK actually use pkg-config in their build process... it might be that pkg-config is too Unixish for them. They probably prefer to hardcode paths into makefiles. --tml ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Mon, Nov 15, 2004 at 04:34:49PM CET: Also, what do we do about -rpath? We still need to encode the runtime path to even the dropped deplib directories so that the same library we linked with is picked up at runtime. Erm, is this not handled in the depending library? (I have no idea, really, but I hoped this would be so.) This is definitely a sticky problem. We do builds that "install" to a path that is different from their actual, final destination. I'm finding that the rpath handling at various stages of a build tries to be too smart for its own good. E.g., I have a build tree in my home directory for a number of packages in ~/BLD, the ultimate destination is /opt/foo, and everything is staged into ~/BLD/opt/foo. For files in the resulting package that contain embedded RPATH/RUNPATHs, I only want "/opt/foo" present in the binary, but I find a lot of instances of "/home/hyc/BLD/opt/foo" that I have to squash by manually relinking. -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Mon, 15 Nov 2004, Ralf Wildenhues wrote: I've been away for a few days.. * Gary V. Vaughan wrote on Sun, Nov 14, 2004 at 09:44:19PM CET: Scott James Remnant wrote: They're both trying to deal with platforms like Solaris that don't have a needed-following link loader. That's a good idea, if we know the linker can find deplibs without help, we should take advantage of that to shorten the link line! Please add it to TODO. Seconded (or thirded, or whoever also wants this). On systems where deplibs are handled by the linker, libtool should give the advantage back to the user. IMVHO this is actually increasing the value of libtool, because it allows the user to make use of the features of the underlying system. Just let the docs explicitly tell that the non-implicit dependencies on other systems will lead to more work for the end-user there. I must respectfully disagree with this for the second time. Just because a platform supports the feature does not mean that a particular shared library has recorded the necessary dependencies so they may be automatically included. If the dependencies were lacking when the shared library was built, then they will also be lacking for any program or library which links with it. Libtiff comes to mind as a shared library which in times past has lacked dependency information. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Mon, Nov 15, 2004 at 03:45:10PM +, Scott James Remnant wrote: > On Mon, 2004-11-15 at 15:34 +, Gary V. Vaughan wrote: > > > Scott James Remnant wrote: > > > > > I submitted keybuk-linux-deplibs.patch to libtool-patches back in March, > > > and there was a slight objection from Bob and nobody else joined in to > > > ok it. > > > > The list was very busy around then, and I was waiting to see the results > > of you and Bob duking it out ;-) You didn't answer any of Bob's > > questions... > > > I was pretty busy at the time as well, and have been manically busy > since then with the new job -- only just getting my head above water > again. > > > >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. > > > And, indeed, only does that for shared libraries. > > It should actually promote better support, because you need to remember > to directly link any library you depend on -- and don't rely on a > dependency library linking it in for you. > > > >> This solution does not seem to support the case where an actual > > >> dependency exists but is not registered in the library (because the > > >> user didn't supply it) so that the dynamic link loader doesn't know > > >> about it? > > > > Good point. We really ought to check the library registered > > dependencies against the .la deplibs and only drop the deplibs > > common to both, since we know the linker will pick those up. > > I guess that means looking through the dependency tree of .la > > files to find matches. > > > It does assume that all library dependencies are registered, yes. This > has never been a problem, because we've never found any Libtool-produced > library that doesn't have all dependencies registered. > > If this isn't the case, and at one time Libtool never registered all of > the dependencies, we should check for that. Otherwise I don't see the > need -- we can assume sanity from our own output. for a long time, libtool did not handle -pthread properly. I can point to at least a few .la files on my system that do not have -pthread or even other required libraries registered. probably some of that is due to them coming from older packages, that used older versions of libtool. some probably are even using hacked libtools because the version of libtool available at the time didn't work properly on that system. the primary objective of libtool is portability, is it not? > > Also, what do we do about -rpath? We still need to encode the > > runtime path to even the dropped deplib directories so that the > > same library we linked with is picked up at runtime. > > > Libraries have their own RPATH, don't they? > > > >> If libone or libfour contain weak symbols, what happens? > > > > I have no idea! Scott? > > > They're available to the library that links them. If the application > was relying on something down the stack, it was broken anyway and > should've directly linked libone or libfour itself. > > Scott > -- > Have you ever, ever felt like this? > Had strange things happen? Are you going round the twist? -- <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
* Gary V. Vaughan wrote on Mon, Nov 15, 2004 at 04:34:49PM CET:
> >Bob Friesenhahn wrote:
> >>
> >>This solution does not seem to support the case where an actual
> >>dependency exists but is not registered in the library (because the
> >>user didn't supply it) so that the dynamic link loader doesn't know
> >>about it?
>
> Good point. We really ought to check the library registered
> dependencies against the .la deplibs and only drop the deplibs
> common to both, since we know the linker will pick those up.
> I guess that means looking through the dependency tree of .la
> files to find matches.
I don't think so. If there is a real dependency, then we want it to be
noticed. Look:
libA -> { libB, libC }
libB -> libC
Now libB is rewritten to not need libC any more (imagine it provides
low-level stuff like glib). If we do not listen to what the user tells
us, we end up with a broken installed library libA.
> Also, what do we do about -rpath? We still need to encode the
> runtime path to even the dropped deplib directories so that the
> same library we linked with is picked up at runtime.
Erm, is this not handled in the depending library? (I have no idea,
really, but I hoped this would be so.)
> >>If libone or libfour contain weak symbols, what happens?
>
> I have no idea! Scott?
Me neither.
Regards,
Ralf
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Mon, 2004-11-15 at 15:51 +, Joe Orton wrote: > On Mon, Nov 15, 2004 at 02:42:51PM +, Scott James Remnant wrote: > > On Mon, 2004-11-15 at 13:16 +, Gary V. Vaughan wrote: > > > > > Ralf Wildenhues wrote: > > > Scott James Remnant wrote: > > > > > > > >They're both trying to deal with platforms like Solaris that don't > > > >have > > > >a needed-following link loader. > > > > > > > The patch that is in Debian's libtool? > > > > > > It is? I'll defer to Scott... > > > > > Yes. When you're making a distribution, Libtool's behaviour of directly > > linking indirect-dependencies is insane. For a SONAME change to a > > library deep in the stack, that only affects the library immediately > > above it, you suddenly need to rebuild your entire desktop environment. > > How does libtool know that the SONAME change only affects the library > above it? What if there is a structure exposed through multiple levels > of libraries or something like that? I can think of several cases where > doing this by default in libtool would be unsafe. > Then those additional levels should directly link to the shared libraries they depend on. This is just correct practice. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Mon, 2004-11-15 at 15:34 +, Gary V. Vaughan wrote: > Scott James Remnant wrote: > > > I submitted keybuk-linux-deplibs.patch to libtool-patches back in March, > > and there was a slight objection from Bob and nobody else joined in to > > ok it. > > The list was very busy around then, and I was waiting to see the results > of you and Bob duking it out ;-) You didn't answer any of Bob's > questions... > I was pretty busy at the time as well, and have been manically busy since then with the new job -- only just getting my head above water again. > >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. > And, indeed, only does that for shared libraries. It should actually promote better support, because you need to remember to directly link any library you depend on -- and don't rely on a dependency library linking it in for you. > >> This solution does not seem to support the case where an actual > >> dependency exists but is not registered in the library (because the > >> user didn't supply it) so that the dynamic link loader doesn't know > >> about it? > > Good point. We really ought to check the library registered > dependencies against the .la deplibs and only drop the deplibs > common to both, since we know the linker will pick those up. > I guess that means looking through the dependency tree of .la > files to find matches. > It does assume that all library dependencies are registered, yes. This has never been a problem, because we've never found any Libtool-produced library that doesn't have all dependencies registered. If this isn't the case, and at one time Libtool never registered all of the dependencies, we should check for that. Otherwise I don't see the need -- we can assume sanity from our own output. > Also, what do we do about -rpath? We still need to encode the > runtime path to even the dropped deplib directories so that the > same library we linked with is picked up at runtime. > Libraries have their own RPATH, don't they? > >> If libone or libfour contain weak symbols, what happens? > > I have no idea! Scott? > They're available to the library that links them. If the application was relying on something down the stack, it was broken anyway and should've directly linked libone or libfour itself. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Mon, Nov 15, 2004 at 02:42:51PM +, Scott James Remnant wrote: > On Mon, 2004-11-15 at 13:16 +, Gary V. Vaughan wrote: > > > Ralf Wildenhues wrote: > > Scott James Remnant wrote: > > > > > >They're both trying to deal with platforms like Solaris that don't have > > >a needed-following link loader. > > > > > The patch that is in Debian's libtool? > > > > It is? I'll defer to Scott... > > > Yes. When you're making a distribution, Libtool's behaviour of directly > linking indirect-dependencies is insane. For a SONAME change to a > library deep in the stack, that only affects the library immediately > above it, you suddenly need to rebuild your entire desktop environment. How does libtool know that the SONAME change only affects the library above it? What if there is a structure exposed through multiple levels of libraries or something like that? I can think of several cases where doing this by default in libtool would be unsafe. joe ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
Scott James Remnant wrote: I submitted keybuk-linux-deplibs.patch to libtool-patches back in March, and there was a slight objection from Bob and nobody else joined in to ok it. The list was very busy around then, and I was waiting to see the results of you and Bob duking it out ;-) You didn't answer any of Bob's questions... >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. This solution does not seem to support the case where an actual dependency exists but is not registered in the library (because the user didn't supply it) so that the dynamic link loader doesn't know about it? Good point. We really ought to check the library registered dependencies against the .la deplibs and only drop the deplibs common to both, since we know the linker will pick those up. I guess that means looking through the dependency tree of .la files to find matches. Also, what do we do about -rpath? We still need to encode the runtime path to even the dropped deplib directories so that the same library we linked with is picked up at runtime. If libone or libfour contain weak symbols, what happens? I have no idea! Scott? +2004-03-28 Scott James Remnant <[EMAIL PROTECTED]> + + * ltmain.in: The dynamic link loader on some platforms is able to + correctly traverse dependency trees, therefore when $link_all_deplibs + is set to 'no' don't add the contents of dependency_libs to the + link line to link a program. + * m4/libtool.m4 (AC_LIBTOOL_PROG_LD_SHLIBS) [linux*]: Linux is one + of those platforms, set link_all_deplibs to 'no' for both C++ and + other compilers. + * NEWS: Updated. Bob's second point needs addressing first, IMHO. I think the -rpath stuff will come out in the wash provided we are careful. Either way, this is a deep change for HEAD only. 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
Re: TODO
* Peter O'Gorman wrote on Tue, Nov 09, 2004 at 02:46:09PM CET: > I just want to get some possibilities out there into the ether. Feel free > to add more bits/say which bits are silly. > > Post 2.0: glibc HEAD NEWS has: | | Namespaces in ld.so are implemented. DSOs can be loaded in separate | namespaces using the new function dlmopen(). This feature is of course, | like most other dynamic loading functionality, not available in statically | linked applications. Implemented by Ulrich Drepper. I have not yet looked at the exact semantics. But we can look if we can support this (and maybe also add the semantics to ltdl-preopened libtool libraries). Furthermore, wrap | New functions `dladdr1' and `dlinfo' in provide more ways to | interrogate the dynamic linker, compatible with the Solaris interface. because in some cases ltdl can provide some of the additional information. Actually, I haven't looked at the specs, so maybe all we need to do is nothing/just use the new functions if they are available. After all, Libtool is GNU software, and should work nicely on GNU systems, right? Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Mon, 2004-11-15 at 13:16 +, Gary V. Vaughan wrote: > Ralf Wildenhues wrote: > Scott James Remnant wrote: > > > >They're both trying to deal with platforms like Solaris that don't have > >a needed-following link loader. > > > The patch that is in Debian's libtool? > > It is? I'll defer to Scott... > Yes. When you're making a distribution, Libtool's behaviour of directly linking indirect-dependencies is insane. For a SONAME change to a library deep in the stack, that only affects the library immediately above it, you suddenly need to rebuild your entire desktop environment. > > If yes, the why in the world are we not using it? > > Exactly! :-) > I submitted keybuk-linux-deplibs.patch to libtool-patches back in March, and there was a slight objection from Bob and nobody else joined in to ok it. Attached again. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? diff -ruNp libtool-CVS~/ChangeLog libtool-CVS/ChangeLog --- libtool-CVS~/ChangeLog 2004-03-24 14:23:18.0 + +++ libtool-CVS/ChangeLog 2004-03-28 22:12:29.0 +0100 @@ -0,0 +1,11 @@ +2004-03-28 Scott James Remnant <[EMAIL PROTECTED]> + + * ltmain.in: The dynamic link loader on some platforms is able to + correctly traverse dependency trees, therefore when $link_all_deplibs + is set to 'no' don't add the contents of dependency_libs to the + link line to link a program. + * m4/libtool.m4 (AC_LIBTOOL_PROG_LD_SHLIBS) [linux*]: Linux is one + of those platforms, set link_all_deplibs to 'no' for both C++ and + other compilers. + * NEWS: Updated. + diff -ruNp libtool-CVS~/ltmain.in libtool-CVS/ltmain.in --- libtool-CVS~/ltmain.in 2004-03-24 02:59:18.0 + +++ libtool-CVS/ltmain.in 2004-03-28 21:45:45.0 +0100 @@ -1904,7 +1904,10 @@ EOF case $pass in dlopen) libs="$dlfiles" ;; dlpreopen) libs="$dlprefiles" ;; - link) libs="$deplibs %DEPLIBS% $dependency_libs" ;; + link) + libs="$deplibs %DEPLIBS%" + test "X$link_all_deplibs" != Xno && libs="$libs $dependency_libs" + ;; esac fi if test "$pass" = dlopen; then diff -ruNp libtool-CVS~/m4/libtool.m4 libtool-CVS/m4/libtool.m4 --- libtool-CVS~/m4/libtool.m4 2004-03-24 14:08:28.0 + +++ libtool-CVS/m4/libtool.m4 2004-03-28 22:08:26.0 +0100 @@ -3381,6 +3381,9 @@ m4_if([$1], [CXX], [ cygwin* | mingw*) _LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED -e '\''/^[[BCDGS]] /s/.* \([[^ ]]*\)/\1 DATA/;/^.* __nm__/s/^.* __nm__\([[^ ]]*\) [[^ ]]*/\1 DATA/;/^I /d;/^[[AITW]] /s/.* //'\'' | sort | uniq > $export_symbols' ;; + linux*) +_LT_AC_TAGVAR(link_all_deplibs, $1)=no + ;; *) _LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED '\''s/.* //'\'' | sort | uniq > $export_symbols' ;; @@ -3566,6 +3569,7 @@ _LT_EOF else _LT_AC_TAGVAR(archive_expsym_cmds, $1)=$_LT_AC_TAGVAR(archive_cmds, $1) fi + _LT_AC_TAGVAR(link_all_deplibs, $1)=no else _LT_AC_TAGVAR(ld_shlibs, $1)=no fi diff -ruNp libtool-CVS~/NEWS libtool-CVS/NEWS --- libtool-CVS~/NEWS 2004-03-24 14:13:19.0 + +++ libtool-CVS/NEWS 2004-03-28 22:13:41.0 +0100 @@ -31,6 +31,9 @@ New in 1.5b: 2004-??-??; CVS version 1.5 * If you configure libtool with --disable-shared (or if libtool does not support shared libraries on your platform) trying to build a library using `-shared' is a fatal error. +* libtool no longer adds the contents of dependency_libs to the link line + to link a program on Linux as its dynamic link loader is able to + correctly traverse dependency trees. * libtoolize installs libtool.m4 (and ltdl.m4 if used) to AC_CONFIG_MACRO_DIR. * Mode inferrence removed, shorthand for choosing modes added. * Specifying -allow-undefined is now an error. signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Sun, 2004-11-14 at 14:45 -0600, Bob Friesenhahn wrote: > On Sun, 14 Nov 2004, Albert Chin wrote: > > > On Sun, Nov 14, 2004 at 08:57:27AM +, Scott James Remnant wrote: > >> They're both trying to deal with platforms like Solaris that don't have > >> a needed-following link loader. > > > > What does this mean? > > I assume that he is talking about ELF inherited dependencies. With > inherited dependencies, libraries which were not specified at link > time may appear in the output of `ldd' because one of the linked > libraries does require other non-listed libraries. > Indeed. The link-loader follows the NEEDED of shared libraries it loads and loads *their* dependencies as well. > Recent versions of Solaris do inherit shared library dependencies. > Are you sure about that?! Solaris 9 here doesn't. > Probably Scott should have mentioned Linux instead since I recall a time > (possibly as recent > as Red Hat 5.0) when it did not inherit shared library dependencies. > Nowhere near that recent. Linux's ELF link-loader has, from what I recall, *always* done it. You'd have to go back to before ELF, I suspect. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO ... solution to the pkg-config "conflict"?
On Sun, 2004-11-14 at 17:37 -0800, Jacob Meuser wrote: > On Sun, Nov 14, 2004 at 08:53:15AM +, Scott James Remnant wrote: > > I actually tend to think we should look at this the other way ... if we > > could expose the information Libtool has to other tools, pkg-config > > could defer to Libtool. > > > > So rather than libtool taking over pkg-config, we make them work > > together. > > so, what you want, is simply something like ... > > $ pkg-config --libs foo > -L/path/to -lfoo > $ pkg-config --libs-libtool foo > /path/to/libfoo.la > $ pkg-config --libs bar > -L/path/to -lbar -L/path/to -lfoo > $ pkg-config --libs-libtool bar > /path/to/libbar.la > > where libbar depends on libfoo? > Something along those lines, perhaps; yes. I haven't fully thought out my plans yet. > if so, then write the patch and give it to the pkg-config folks. > I took over pkg-config from Havoc some time ago; I haven't had the time to either patch or reimplement it yet :o) Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Sun, 2004-11-14 at 13:35 -0500, Daniel Reed wrote: > On 2004-11-14T08:50-, Scott James Remnant wrote: > ) On Fri, 2004-11-12 at 11:20 +, Gary V. Vaughan wrote: > ) > Haven't thought through the -I thing yet though... maybe that doesn't > ) > belong in libtool... maybe we could provide a macro that can intuit > ) > include directories from .la locations... I dunno... > ) The most common arrangement is libraries in /usr/lib and includes > ) in /usr/include/- ... so not easy to intuit like that. > > That appears to be common of GNOME components, but does not appear to be > common in the general case. > pkg-config is a GNOME component that became generically useful enough to become a Freedesktop.org component. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
Ralf Wildenhues wrote: Scott James Remnant wrote: They're both trying to deal with platforms like Solaris that don't have a needed-following link loader. So will libtool do The Right Thing in all circumstances, given the tiny patch to enable link_all_deps=yes on linux and whatever other system has this linker feature? I believe so, especially if we are conservative about enabling it. The patch that is in Debian's libtool? It is? I'll defer to Scott... If yes, the why in the world are we not using it? Exactly! :-) Actually, we need to be careful not to break support for old OS releases. Bob pointed out that Redhat 5 shipped a linker (presumably an old GNU ld) that couldn't follow deplibs without help, so we might want to write a configure time test too. But we can't rely on that too much because it will break cross compiles. On balance, I think we can start setting link_all_deplibs=no in HEAD for platforms that we can prove will support it. Ideally, the GNU ld case should be keyed off `ld --version` so that we don't break old dists, but other hosts can probably be taken from $host_os version quite safely. 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
Re: TODO
* Gary V. Vaughan wrote on Mon, Nov 15, 2004 at 01:11:26PM CET: > Ralf Wildenhues wrote: > >* Gary V. Vaughan wrote on Sun, Nov 14, 2004 at 09:44:19PM CET: > >>Scott James Remnant wrote: > >> > >>>They're both trying to deal with platforms like Solaris that don't have > >>>a needed-following link loader. > >> > >>That's a good idea, if we know the linker can find deplibs without > >>help, we should take advantage of that to shorten the link line! > >>Please add it to TODO. > > > >Seconded (or thirded, or whoever also wants this). > >On systems where deplibs are handled by the linker, > >libtool should give the advantage back to the user. > >IMVHO this is actually increasing the value of libtool, > >because it allows the user to make use of the features > >of the underlying system. Just let the docs explicitly > >tell that the non-implicit dependencies on other systems > >will lead to more work for the end-user there. > > No need for that. It should all be transparent to the user. > Libtool will continue to use its long deplib link lines unless > it knows that the host platform can follow deplibs on its own, > in which case it only adds the direct dependencies to the > link line, and trusts the linker to find the deplibs. So will libtool do The Right Thing in all circumstances, given the tiny patch to enable link_all_deps=yes on linux and whatever other system has this linker feature? The patch that is in Debian's libtool? If yes, the why in the world are we not using it? Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
Hi Howard! Howard Chu wrote: That's great for shared libraries, but one of the things I actually like about libtool is the automatic dependency inclusion when linking static libraries. I.e., plain 'ol .a archives are much less friendlier without libtool because they don't carry any dependency info... Agreed. We would only drop the deplibs when we know the linker will handle it. The only difference to the user is that they will see much shorter linker calls if they are building on a host that can handle it. Everything is remains as is! 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
Re: TODO
Ralf Wildenhues wrote: I've been away for a few days.. * Gary V. Vaughan wrote on Sun, Nov 14, 2004 at 09:44:19PM CET: Scott James Remnant wrote: They're both trying to deal with platforms like Solaris that don't have a needed-following link loader. That's a good idea, if we know the linker can find deplibs without help, we should take advantage of that to shorten the link line! Please add it to TODO. Seconded (or thirded, or whoever also wants this). On systems where deplibs are handled by the linker, libtool should give the advantage back to the user. IMVHO this is actually increasing the value of libtool, because it allows the user to make use of the features of the underlying system. Just let the docs explicitly tell that the non-implicit dependencies on other systems will lead to more work for the end-user there. No need for that. It should all be transparent to the user. Libtool will continue to use its long deplib link lines unless it knows that the host platform can follow deplibs on its own, in which case it only adds the direct dependencies to the link line, and trusts the linker to find the deplibs. 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
Re: TODO
Ralf Wildenhues wrote: I've been away for a few days.. * Gary V. Vaughan wrote on Sun, Nov 14, 2004 at 09:44:19PM CET: Scott James Remnant wrote: They're both trying to deal with platforms like Solaris that don't have a needed-following link loader. That's a good idea, if we know the linker can find deplibs without help, we should take advantage of that to shorten the link line! Please add it to TODO. Seconded (or thirded, or whoever also wants this). On systems where deplibs are handled by the linker, libtool should give the advantage back to the user. IMVHO this is actually increasing the value of libtool, because it allows the user to make use of the features of the underlying system. Just let the docs explicitly tell that the non-implicit dependencies on other systems will lead to more work for the end-user there. Regards, Ralf That's great for shared libraries, but one of the things I actually like about libtool is the automatic dependency inclusion when linking static libraries. I.e., plain 'ol .a archives are much less friendlier without libtool because they don't carry any dependency info... -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
Hi Jacob, Jacob Meuser wrote: On Sun, Nov 14, 2004 at 09:04:31PM +, Gary V. Vaughan wrote: Hi Bob! Bob Friesenhahn wrote: You seem to be a victim of a package install where every package has used its own unique installation prefix. It seems to me that most systems use just one or two installation prefixes. Absolutely. But the point is that pkg-config is supposed to help with parallel installs, and it most certainly does not! come on Gary, libtool is supposed to make building libraries more portable, but it is simply _broken_ for some systems at any given time, because the libtool team simply does not have the time to check that every change does not break on any systems. so you end up having someone who finds the brokenness and sends in patches. That is very true. think about it. you can either improve the interaction between pkg-confg and libtool in a positive and constructive manner, or you can just blame pkg-config. I didn't mean to be uselessly negative about pkg-config, I was (am) just frustrated with its flaws. But, irrespective of that, the bottom line is that what I want to do (the long scenario I described earlier in the thread) can be much easier than it is with current pkg-config. And of course I would like to fix that, by the simplest means available. At first I thought that would be to absorb pkg-config's functionality into libtool (to avoid duplication of code and maintenance), but as you and others have pointed out, the better way is to make it easier for pkg-config to get the information it needs with libtool's help (where it is available). I'd love to help make that happen. 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
Re: TODO
I've been away for a few days.. * Gary V. Vaughan wrote on Sun, Nov 14, 2004 at 09:44:19PM CET: > Scott James Remnant wrote: > > >They're both trying to deal with platforms like Solaris that don't have > >a needed-following link loader. > > That's a good idea, if we know the linker can find deplibs without > help, we should take advantage of that to shorten the link line! > Please add it to TODO. Seconded (or thirded, or whoever also wants this). On systems where deplibs are handled by the linker, libtool should give the advantage back to the user. IMVHO this is actually increasing the value of libtool, because it allows the user to make use of the features of the underlying system. Just let the docs explicitly tell that the non-implicit dependencies on other systems will lead to more work for the end-user there. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Sun, Nov 14, 2004 at 09:04:31PM +, Gary V. Vaughan wrote: > Hi Bob! > > Bob Friesenhahn wrote: > >You seem to be a victim of a package install where every package has > >used its own unique installation prefix. It seems to me that most > >systems use just one or two installation prefixes. > > Absolutely. > > But the point is that pkg-config is supposed to help with parallel > installs, and it most certainly does not! come on Gary, libtool is supposed to make building libraries more portable, but it is simply _broken_ for some systems at any given time, because the libtool team simply does not have the time to check that every change does not break on any systems. so you end up having someone who finds the brokenness and sends in patches. think about it. you can either improve the interaction between pkg-confg and libtool in a positive and constructive manner, or you can just blame pkg-config. -- <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
Hi Jacob, Jacob Meuser wrote: On Sun, Nov 14, 2004 at 05:09:08PM -0500, Daniel Reed wrote: On 2004-11-14T14:56-0600, Bob Friesenhahn wrote: ) On Sun, 14 Nov 2004, Gary V. Vaughan wrote: ) > $ PKG_CONFIG_PATH=/opt/libgdiplus10/lib/pkgconfig ) You seem to be a victim of a package install where every package has ) used its own unique installation prefix. It seems to me that most ) systems use just one or two installation prefixes. [http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES] /opt is reserved for the installation of add-on application software packages. A package to be installed in /opt must locate its static files in a separate /opt/ or /opt/ directory tree, where is a name that describes the software package and is the provider's LANANA registered name. ... The directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man are reserved for local system administrator use. Packages may provide "front-end" files intended to be placed in (by linking or copying) these reserved directories by the local system administrator, but must function normally in the absence of these reserved directories. (It may be arguable that having to manually specify paths to find .pc files to pkg-config is not functioning "normally"--at least not within the stated goals of PKGConfig's developers--as Gary pointed out.) huh? so pkg-config is supposed to look in _every_ directory to find .pc files? Nope. Just the ones required to let me link with the library I specify. besides the second part of what you quoted is what should have happened on Gary's system, so instead of all the separate paths under /opt, there would have simply been /opt/lib/pkgconfig. But the point of splitting things into separate directories is so that I can have parallel installs of, say, libpng-1.2.4 and libpng-1.2.7, and link them against, say, zlib-1.1.4 and zlib-1.2.2 respectively. You can't do that with a shared pkgconfig directory. And without a lot of manual intervention, pkg-config actually makes it harder to do that than just looking up the dependencies by hand. :-( yes, because they "*want* to isolate each package", but the administrator failed to "either manage a system-wide set of $*PATH environment variables or manage symlinks from other well-known locations (maybe as part of a simple form of software management)." There shouldn't be any need to do this. All the information was already known when the .pc file was made, but it wasn't saved. _any_ tool that needs information that is hidden from it will of course not be as functional as it could be. pkg-config could either get it from ldd at link time, or at install time from configure. Or it could co-operate with libtool... 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
Re: TODO ... solution to the pkg-config "conflict"?
On Sun, Nov 14, 2004 at 08:53:15AM +, Scott James Remnant wrote: > On Fri, 2004-11-12 at 23:02 -0800, Jacob Meuser wrote: > > > > It doesn't care about package versions, but it has to care about library > > > versions and paths to libraries. > > > > again, functionality provided by pkg-config. > > > > I am contesting the claim "Libtool already has all the information > > it needs". > > > I actually tend to think we should look at this the other way ... if we > could expose the information Libtool has to other tools, pkg-config > could defer to Libtool. > > So rather than libtool taking over pkg-config, we make them work > together. so, what you want, is simply something like ... $ pkg-config --libs foo -L/path/to -lfoo $ pkg-config --libs-libtool foo /path/to/libfoo.la $ pkg-config --libs bar -L/path/to -lbar -L/path/to -lfoo $ pkg-config --libs-libtool bar /path/to/libbar.la where libbar depends on libfoo? if so, then write the patch and give it to the pkg-config folks. I can't imagine that you'd have the time to reimplement pkg-config, but not the time to patch it. -- <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Sun, Nov 14, 2004 at 05:09:08PM -0500, Daniel Reed wrote: > On 2004-11-14T14:56-0600, Bob Friesenhahn wrote: > ) On Sun, 14 Nov 2004, Gary V. Vaughan wrote: > ) > $ PKG_CONFIG_PATH=/opt/libgdiplus10/lib/pkgconfig > ) You seem to be a victim of a package install where every package has > ) used its own unique installation prefix. It seems to me that most > ) systems use just one or two installation prefixes. > > [http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES] > /opt is reserved for the installation of add-on application software > packages. > > A package to be installed in /opt must locate its static files in a > separate /opt/ or /opt/ directory tree, where >is a name that describes the software package and >is the provider's LANANA registered name. > > ... > > The directories /opt/bin, /opt/doc, /opt/include, /opt/info, > /opt/lib, and /opt/man are reserved for local system administrator > use. Packages may provide "front-end" files intended to be placed in > (by linking or copying) these reserved directories by the local > system administrator, but must function normally in the absence of > these reserved directories. > > (It may be arguable that having to manually specify paths to find .pc files > to pkg-config is not functioning "normally"--at least not within the stated > goals of PKGConfig's developers--as Gary pointed out.) huh? so pkg-config is supposed to look in _every_ directory to find .pc files? besides the second part of what you quoted is what should have happened on Gary's system, so instead of all the separate paths under /opt, there would have simply been /opt/lib/pkgconfig. > ... > > The use of /opt for add-on software is a well-established practice > in the UNIX community. The System V Application Binary Interface > [AT&T 1990], based on the System V Interface Definition (Third > Edition), provides for an /opt structure very similar to the one > defined here. > > The Intel Binary Compatibility Standard v. 2 (iBCS2) also provides a > similar structure for /opt. > > Generally, all data required to support a package on a system must > be present within /opt/, including files intended to be > copied into /etc/opt/ and /var/opt/ as well as > reserved directories in /opt. > > > > As opposed to: > > [http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY] > The /usr/local hierarchy is for use by the system administrator when > installing software locally. It needs to be safe from being > overwritten when the system software is updated. It may be used for > programs and data that are shareable amongst a group of hosts, but > not found in /usr. > > Locally installed software must be placed within /usr/local rather > than /usr unless it is being installed to replace or upgrade > software in /usr. [27] > > > The /usr/local hierarchy may be thought of as mimicking the /usr hierarchy > for packages that are installed outside of the local system's software > management infrastructure. (/usr/local is the default install prefix for the > autotools to gently enforce this.) > > The /opt hierarchy, on the other hand, may be more widely used by > third-party software that does integrate with the local system's software > management infrastructure, but is not a part of the local system's core > installation. > > The /opt hierarchy may also be used by operating system distributors who > *want* to isolate each package, and either manage a system-wide set of > $*PATH environment variables or manage symlinks from other well-known > locations (maybe as part of a simple form of software management). > > There is no requirement that software installed into /opt make its presence > known (in well-known locations). Hence, to be reliable, PKGConfig would > either need to crawl /opt/*/lib/pkgconfig/ or demand that the installers > manually specify from which install prefix to pull information. Either way, yes, because they "*want* to isolate each package", but the administrator failed to "either manage a system-wide set of $*PATH environment variables or manage symlinks from other well-known locations (maybe as part of a simple form of software management)." > PKGConfig's reliable usefulness is reduced to being something like a means > of storing CFLAGS and CPPFLAGS preferences for specific instances of a > software package; it can not be relied upon in all cases as helping manage > systems with multiple versions of a package installed. _any_ tool that needs information that is hidden from it will of course not be as functional as it could be. > (That is, in a case where a .pc file might be installed in a well-known > location without the library and header files being installed in well-known > locations, an .la file could be similarly installed separat
Re: TODO
On 2004-11-14T14:56-0600, Bob Friesenhahn wrote: ) On Sun, 14 Nov 2004, Gary V. Vaughan wrote: ) > $ PKG_CONFIG_PATH=/opt/libgdiplus10/lib/pkgconfig ) You seem to be a victim of a package install where every package has ) used its own unique installation prefix. It seems to me that most ) systems use just one or two installation prefixes. [http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES] /opt is reserved for the installation of add-on application software packages. A package to be installed in /opt must locate its static files in a separate /opt/ or /opt/ directory tree, where is a name that describes the software package and is the provider's LANANA registered name. ... The directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man are reserved for local system administrator use. Packages may provide "front-end" files intended to be placed in (by linking or copying) these reserved directories by the local system administrator, but must function normally in the absence of these reserved directories. (It may be arguable that having to manually specify paths to find .pc files to pkg-config is not functioning "normally"--at least not within the stated goals of PKGConfig's developers--as Gary pointed out.) ... The use of /opt for add-on software is a well-established practice in the UNIX community. The System V Application Binary Interface [AT&T 1990], based on the System V Interface Definition (Third Edition), provides for an /opt structure very similar to the one defined here. The Intel Binary Compatibility Standard v. 2 (iBCS2) also provides a similar structure for /opt. Generally, all data required to support a package on a system must be present within /opt/, including files intended to be copied into /etc/opt/ and /var/opt/ as well as reserved directories in /opt. As opposed to: [http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY] The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr. Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr. [27] The /usr/local hierarchy may be thought of as mimicking the /usr hierarchy for packages that are installed outside of the local system's software management infrastructure. (/usr/local is the default install prefix for the autotools to gently enforce this.) The /opt hierarchy, on the other hand, may be more widely used by third-party software that does integrate with the local system's software management infrastructure, but is not a part of the local system's core installation. The /opt hierarchy may also be used by operating system distributors who *want* to isolate each package, and either manage a system-wide set of $*PATH environment variables or manage symlinks from other well-known locations (maybe as part of a simple form of software management). There is no requirement that software installed into /opt make its presence known (in well-known locations). Hence, to be reliable, PKGConfig would either need to crawl /opt/*/lib/pkgconfig/ or demand that the installers manually specify from which install prefix to pull information. Either way, PKGConfig's reliable usefulness is reduced to being something like a means of storing CFLAGS and CPPFLAGS preferences for specific instances of a software package; it can not be relied upon in all cases as helping manage systems with multiple versions of a package installed. (That is, in a case where a .pc file might be installed in a well-known location without the library and header files being installed in well-known locations, an .la file could be similarly installed separately to provide access to the same kind of information, just lacking the header file component.) -- Daniel Reed <[EMAIL PROTECTED]> http://people.redhat.com/djr/ http://naim.n.ml.org/ There is a lot of food in a supermarket, too, but a supermarket isn't the best place to hold a dinner party. -- Christopher Faylor ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Sun, 14 Nov 2004, Gary V. Vaughan wrote: Hi Bob! Bob Friesenhahn wrote: You seem to be a victim of a package install where every package has used its own unique installation prefix. It seems to me that most systems use just one or two installation prefixes. Absolutely. But the point is that pkg-config is supposed to help with parallel installs, and it most certainly does not! It can help if the packages themselves are designed to support parallel installs by using versioned lib, include, share, etc., directories. That allows them to use the same installation prefix. Libtool helps, but its resulting configuration (saved in .la files) is static, while pkgconfig's configuration is dynamic since it may be altered by the user. You mean that the installed .pc files need to be altered by the user to give things a hope of linking? ;-) But seriously, why would you install a .pc using library, and then alter the installed .pc file? The libraries may be moved to (or reside in) a different location than when they were built. As you pointed out, pkg-config pulls configuration at run-time for each package, and the user has the ability to specify the pkg-config directory via PKG_CONFIG_PATH. This means that pkg-config is more end-user "tweakable" than libtool. Libtool's .la file scheme expects more path stability than pkg-config does. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Sun, Nov 14, 2004 at 08:53:15AM +, Scott James Remnant wrote: > On Fri, 2004-11-12 at 23:02 -0800, Jacob Meuser wrote: > > > > It doesn't care about package versions, but it has to care about library > > > versions and paths to libraries. > > > > again, functionality provided by pkg-config. > > > > I am contesting the claim "Libtool already has all the information > > it needs". > > > I actually tend to think we should look at this the other way ... if we > could expose the information Libtool has to other tools, pkg-config > could defer to Libtool. why can't libtool just ignore what it thinks is wrong? > So rather than libtool taking over pkg-config, we make them work > together. how about just making libtool work correctly. it's not the fault of any single program that extra linker flags can end up in link commands. if libtool cannot deal with such situations, then libtool is simply broken. -- <[EMAIL PROTECTED]> > Scott > -- > Have you ever, ever felt like this? > Had strange things happen? Are you going round the twist? > ___ > Libtool mailing list > [EMAIL PROTECTED] > http://lists.gnu.org/mailman/listinfo/libtool ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Sun, Nov 14, 2004 at 08:57:27AM +, Scott James Remnant wrote:
> On Sat, 2004-11-13 at 15:27 -0800, Jacob Meuser wrote:
>
> > On Sat, Nov 13, 2004 at 10:21:19AM +0100, Ralf Corsepius wrote:
> > > It's just that their functionality
> > > intersects and partially conflicts.
> >
> > how?
> >
> > pkg-config is used to give basic information about installed packages.
> > libtool is used to build libraries.
> >
> > pkg-config is used in configure scripts.
> > libtool is used in Makefiles.
> >
> > yes, it's possible to use constructs like
> >
> > foo.so: foo.o
> > ${CC} ${LDFLAGS} -o foo.so foo.o `pkg-config bar --libs`
> >
> > in Makefiles, but this is not overlap in a conflicting way.
> >
> This is actually exactly what happens when you use pkg-config in a
> configure script. It generates a (e.g.) GLIB_LIBS Makefile variable and
> you arrange for the contents of that to be added to the link line --
> just like you say here.
yes, or I could just as easily hardcode
FOO_LIBS="-L/usr/local/lib -lfoo -lbar"
in configure.
so now, I'm not using pkg-config at all. it's not uncommon to see
such things. how would libtool deal with that?
> The conflict is that pkg-config not only provides the -L and -l needed
> to the library, but also those for all of its dependency libraries.
>
> So does Libtool.
how is that a conflict? would the case above be an irreconcilable
conflict?
> They're both trying to deal with platforms like Solaris that don't have
> a needed-following link loader.
>
> It would be far neater if they could co-operate with this.
libtool already scrutinizes the command line for relevant flags.
if libtool is so infinitely better than anything else at building
libraries, then why can't it simply drop irrelevant/duplicated
flags, and add the ones it needs?
--
<[EMAIL PROTECTED]>
>
> Scott
> --
> Have you ever, ever felt like this?
> Had strange things happen? Are you going round the twist?
> ___
> Libtool mailing list
> [EMAIL PROTECTED]
> http://lists.gnu.org/mailman/listinfo/libtool
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Sun, Nov 14, 2004 at 09:04:31PM +, Gary V. Vaughan wrote:
> You mean that the installed .pc files need to be altered by the
> user to give things a hope of linking? ;-)
Hate to chime in, but I always seem to have to add -Wl,-R... to the *.pc
files, so have not ended up being a fan of pkg-config. Unfortunately
it seems to crop up all over the place, and I keep reinventing ways of
getting libtool's ${wl} info into the foo.pc from foo.pc.in..
> But seriously, why would you install a .pc using library, and then
> alter the installed .pc file?
Because that's what comes in the source tar :-( and then the other
source tars' use pkg-config --libs (given up on glib and friends often)
Cheers,
Patrick
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
Hi Bob! Bob Friesenhahn wrote: You seem to be a victim of a package install where every package has used its own unique installation prefix. It seems to me that most systems use just one or two installation prefixes. Absolutely. But the point is that pkg-config is supposed to help with parallel installs, and it most certainly does not! The system I use (Solaris based) uses three. There is one for the software that comes with the base system (under /usr)), one for "freeware" (under /usr/sfw), and one created by myself for locally installed packages (under /usr/local). The Gentoo Linux system I use has only two pkgconfig files. pkgconfig directories, right? Libtool helps, but its resulting configuration (saved in .la files) is static, while pkgconfig's configuration is dynamic since it may be altered by the user. You mean that the installed .pc files need to be altered by the user to give things a hope of linking? ;-) But seriously, why would you install a .pc using library, and then alter the installed .pc file? 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
Re: TODO
On Sun, 14 Nov 2004, Gary V. Vaughan wrote: My main complaint about pkg-config is this: It is supposed to make it easier to link with packages that have each been installed to their own prefix (to support parallel installation of multiple versions), but in fact it makes things much harder. Real world example: I want to link against libgdiplus, which has a dependency on cairo, so I ask it for the linkflags: $ pkg-config --libs libgdiplus Package libgdiplus was not found in the pkg-config search path. Perhaps you should add the directory containing `libgdiplus.pc' to the PKG_CONFIG_PATH environment variable No package 'libgdiplus' found Fair enough, better tell it where libgdiplus lives: $ PKG_CONFIG_PATH=/opt/libgdiplus10/lib/pkgconfig You seem to be a victim of a package install where every package has used its own unique installation prefix. It seems to me that most systems use just one or two installation prefixes. The system I use (Solaris based) uses three. There is one for the software that comes with the base system (under /usr)), one for "freeware" (under /usr/sfw), and one created by myself for locally installed packages (under /usr/local). The Gentoo Linux system I use has only two pkgconfig files. Libtool helps, but its resulting configuration (saved in .la files) is static, while pkgconfig's configuration is dynamic since it may be altered by the user. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Sun, 14 Nov 2004, Albert Chin wrote: On Sun, Nov 14, 2004 at 08:57:27AM +, Scott James Remnant wrote: They're both trying to deal with platforms like Solaris that don't have a needed-following link loader. What does this mean? I assume that he is talking about ELF inherited dependencies. With inherited dependencies, libraries which were not specified at link time may appear in the output of `ldd' because one of the linked libraries does require other non-listed libraries. Recent versions of Solaris do inherit shared library dependencies. Probably Scott should have mentioned Linux instead since I recall a time (possibly as recent as Red Hat 5.0) when it did not inherit shared library dependencies. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
PATH too, along with anything else they might depend on. And so it goes on. Like I said, pkg-config is an aberration: it makes it *harder* for me to link correctly :-( And worse, if I try to link this without the help of libtool, it doesn't even set the runtime loader library search path, so my app is going to pick up libraries from the wrong directories when I run it anyway. So does Libtool. How would I do this link with just libtool? (note: -n, -o application and object.o are dummies just to show this output) $ libtool -n --mode=link gcc -o application object.o \ /opt/libgdiplus10/lib/libgdiplus.la And here is what it tells me. Notice that it automatically links against the same dependent libraries that I used to link libgdiplus in the first place, it doesn't force me to figure out paths to the correct libraries by hand, and it sets the rpath for me so that the runtime loader will find the same libraries I'm linking against at compile time. gcc -o application object.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 And *that* is why I think pkg-config is an aberration. They're both trying to deal with platforms like Solaris that don't have a needed-following link loader. That's a good idea, if we know the linker can find deplibs without help, we should take advantage of that to shorten the link line! Please add it to TODO. It would be far neater if they could co-operate with this. Okay, I agree that we're not in the business of killing off pkg-config. And it would certainly make life easier for everyone if libtool could extract linkflags like above without the -n -o sleight of hand. With luck, we could persuade the pkg-config folks to use that to pass back a correct link line that won't hose their users' builds. 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) iD8DBQFBl55rFRMICSmD1gYRArbsAKClNeJ3PdYGUEEs2+/UwHC8l1fNpgCgk73/ yoN7joWunIdd6f1bWuRWaoc= =Ur5s -END PGP SIGNATURE- signature.asc Description: OpenPGP digital signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Sun, Nov 14, 2004 at 08:57:27AM +, Scott James Remnant wrote: > They're both trying to deal with platforms like Solaris that don't have > a needed-following link loader. What does this mean? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On 2004-11-14T08:50-, Scott James Remnant wrote: ) On Fri, 2004-11-12 at 11:20 +, Gary V. Vaughan wrote: ) > Haven't thought through the -I thing yet though... maybe that doesn't ) > belong in libtool... maybe we could provide a macro that can intuit ) > include directories from .la locations... I dunno... ) The most common arrangement is libraries in /usr/lib and includes ) in /usr/include/- ... so not easy to intuit like that. That appears to be common of GNOME components, but does not appear to be common in the general case. (Automake's includedir location defaults to prefix/include and its pkgincludedir location defaults to includedir/name, not includedir/name-version.) The following packages on my FC4 machine have versioned pkgincludedirs: apr atk at-spi bonobo dbus devhelp eel2 evolution evolution-data-server gail gal gdk-pixbuf gedit gimp glib glib2 gnome-desktop gnome-keyring gnome-libs gnome-mag gnome-panel gnome-speech gnome-vfs gnome-vfs2 gnopernicus gstreamer gtk+ gtk2 gtkhtml gtkhtml2 gtkhtml3 gtksourceview gtkspell howl libart_lgpl libbonobo libbonoboui libcroco libgal2 libglade libglade2 libgnome libgnomecanvas libgnomecups libgnomeprint22 libgnomeprintui22 libgnomeui libgsf libgtop2 libIDL librsvg2 libsoup libwnck linc metacity ORBit ORBit2 ots pango startup-notification subversion Of that list, I believe only apr, ots, and subversion are not GNOME components. Also of that list, only the following did not appear to have .pc files installed: apr gnome-libs subversion Just as another point of data, the following packages on my FC4 machines have .pc files installed: aiksaurus aiksaurus-gtk alsa-lib atk at-spi audiofile bluez-libs bonobo dbh dbus devhelp eel2 esound evolution evolution-data-server fontconfig freetype fribidi gail gaim gal gamin gawk GConf GConf2 gedit gimp gkrellm glib glib2 gnome-applets gnome-bluetooth gnome-desktop gnome-icon-theme gnome-keyring gnome-mag gnome-media gnome-mime-data gnome-panel gnome-pilot gnome-python2 gnome-speech gnome-utils gnome-vfs2 gnopernicus gok gphoto2 gstreamer gstreamer-plugins gtk+ gtk2 gtk2-engines gtkhtml gtkhtml2 gtkhtml3 gtksourceview gtkspell hal howl ImageMagick imlib libao libart_lgpl libbonobo libbonoboui libbtctl libcroco libdv libexif libgal2 libgcj libgda libglade libglade2 libgnome libgnomecanvas libgnomecups libgnomedb libgnomeprint22 libgnomeprintui22 libgnomeui libgsf libgtop2 libIDL libidn libmusicbrainz libogg libpng libpng10 libraw1394 librsvg2 libsilc libsoup libuser libvorbis libwnck libwpd libxfce4mcs libxfce4util libxfcegui4 libxklavier libxml libxml2 libxslt linc metacity mozilla mozilla-nspr mozilla-nss nautilus nautilus-cd-burner neon NetworkManager openssl ORBit ORBit2 ots pango planner pygtk2 pyorbit qt rhythmbox shared-mime-info speex startup-notification valgrind vte xemacs-sumo xfce4-panel xfce-mcs-manager xffm xmlsec1 xmlsec1-openssl xorg-x11 Of this second list, most of them appear to be either a) GNOME components, b) GNOME-related/integrated software (gaim, ImageMagick), or c) software maintained by people who are also GNOME developers (*xml*). (The .pc file gawk installs is a README for "pc" versus "hpux" or "atari" :) I would be very interested in researching how Libtool can help with multilib builds. Other than that cause, however, I am not sure there exists a real demand (outside of GNOME) for the features PKGConfig offers that Libtool does not already provide. (My own machines without GNOME or even X installed only have .pc files for valgrind and/or openssl, and do not have PKGConfig installed. They do, however, have many .la files. On my machines with a C++ compiler installed, there is a g++-3 directory in /usr/include; on machines without, there are no versioned include directories.) -- Daniel Reed <[EMAIL PROTECTED]> http://people.redhat.com/djr/ http://naim.n.ml.org/ If nature has made you a giver, your hands are born open, and so is your heart. And though there may be times when your hands are empty, your heart is always full, and you can give things out of that. -- Frances Hodgson Burnett, Novelist ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Fri, 2004-11-12 at 23:02 -0800, Jacob Meuser wrote: > > It doesn't care about package versions, but it has to care about library > > versions and paths to libraries. > > again, functionality provided by pkg-config. > > I am contesting the claim "Libtool already has all the information > it needs". > I actually tend to think we should look at this the other way ... if we could expose the information Libtool has to other tools, pkg-config could defer to Libtool. So rather than libtool taking over pkg-config, we make them work together. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Sat, 2004-11-13 at 15:27 -0800, Jacob Meuser wrote:
> On Sat, Nov 13, 2004 at 10:21:19AM +0100, Ralf Corsepius wrote:
> > It's just that their functionality
> > intersects and partially conflicts.
>
> how?
>
> pkg-config is used to give basic information about installed packages.
> libtool is used to build libraries.
>
> pkg-config is used in configure scripts.
> libtool is used in Makefiles.
>
> yes, it's possible to use constructs like
>
> foo.so: foo.o
> ${CC} ${LDFLAGS} -o foo.so foo.o `pkg-config bar --libs`
>
> in Makefiles, but this is not overlap in a conflicting way.
>
This is actually exactly what happens when you use pkg-config in a
configure script. It generates a (e.g.) GLIB_LIBS Makefile variable and
you arrange for the contents of that to be added to the link line --
just like you say here.
The conflict is that pkg-config not only provides the -L and -l needed
to the library, but also those for all of its dependency libraries.
So does Libtool.
They're both trying to deal with platforms like Solaris that don't have
a needed-following link loader.
It would be far neater if they could co-operate with this.
Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
signature.asc
Description: This is a digitally signed message part
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Fri, 2004-11-12 at 11:20 +, Gary V. Vaughan wrote: > Albert Chin wrote: > > On Wed, Nov 10, 2004 at 03:43:48PM +, Scott James Remnant wrote: > > > > Ick. Libtool is about portably building/using libraries. Why can't we > > leave it at that? > > But linking against installed libraries using the correct -L and -l flags > *is* part of portably building/using libraries! ;-) > > Haven't thought through the -I thing yet though... maybe that doesn't > belong in libtool... maybe we could provide a macro that can intuit > include directories from .la locations... I dunno... > The most common arrangement is libraries in /usr/lib and includes in /usr/include/- ... so not easy to intuit like that. Scot -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Sat, 13 Nov 2004, Jacob Meuser wrote:
libtool is used to build libraries.
pkg-config is used in configure scripts.
libtool is used in Makefiles.
yes, it's possible to use constructs like
foo.so: foo.o
${CC} ${LDFLAGS} -o foo.so foo.o `pkg-config bar --libs`
in Makefiles, but this is not overlap in a conflicting way. libtool
isn't even being used there. and if CC is libtool, then if it cannot
handle that command, then, well, libtool is the abberation, because
then it's not doing what it is supposed to do. libtool is supposed to
make building libraries/shared objects easier.
Libtool makes building libraries more portable.
now, could you please tell me where pkg-config conflicts with libtool,
or why pkg-config is an "aberration", or why the libtool codebase
should be bloated to provide functionality already provided by
another commonly use package?
The "simple tool" approach which has helped Unix succeed should be
followed. As you say pkg-config is already easy to use in configure
scripts. It can continue to be used in configure scripts. Libtool
can continue to be a compiler/linker driver. There is no need to fix
something which is not broken and tie tools together when they don't
need to be.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Sat, Nov 13, 2004 at 10:21:19AM +0100, Ralf Corsepius wrote:
> On Fri, 2004-11-12 at 23:02 -0800, Jacob Meuser wrote:
> > On Sat, Nov 13, 2004 at 04:27:28AM +0100, Ralf Corsepius wrote:
> > > On Fri, 2004-11-12 at 14:31 -0800, Jacob Meuser wrote:
> > > > On Fri, Nov 12, 2004 at 03:33:02PM -0600, Albert Chin wrote:
> > > > > On Fri, Nov 12, 2004 at 11:20:13AM +, Gary V. Vaughan wrote:
> > > > > > Albert Chin wrote:
> > > > > > > On Wed, Nov 10, 2004 at 03:43:48PM +, Scott James Remnant
> > > > > > > wrote:
> > > > > > >
> > > > > > >>On Tue, 2004-11-09 at 14:24 +, Gary V. Vaughan wrote:
> > > > > > >>
> > > > > > >>
> > > > > > >>>6. Absorb the functionality of the aberration called
> > > > > > >>>pkg-config. Libtool
> > >
> > > > > > >>>already has all the information it needs, we just need to
> > > > > > >>> teach it (or
> > > > > > >>>maybe a subsidiary script) to spit out link flags after
> > > > > > >>> poking around
> > > > > > >>>in a dependency chain of .la files.
> > > > > > >>
> > > > > > >>There's actually a couple of things pkg-config does that Libtool
> > > > > > >>doesn't
> > > > > > >>currently do. pkg-config's main job can be summed up simply as
> > > > > > >>enabling
> > > > > > >>parallel-installed -dev packages.
> > > >
> > > > since when does libtool care about CFLAGS
> > > It hardly can avoid doing so if wanting to support multilibs.
> >
> > of course, it cares about _some_ CFLAGS at build time. it does not
> > care about where the headers are going to be installed though, or what
> > CPPFLAGS need to be set either ... functionality you do get from
> > pkg-config.
> Well, current libtool does not support multilibs.
>
> If multilibs should ever be able to support them, I'd expect libtool
> having to examine the whole command being used, comprising CFLAGS and
> CPPFLAGS (There exist targets where multilib variants are being
> triggered by preprocessor flags)
but does it care about where the package is going to install it's
headers?
> > > > or package versions?
> > > It doesn't care about package versions, but it has to care about library
> > > versions and paths to libraries.
> >
> > again, functionality provided by pkg-config.
> No. Like libtool, pkg-config only covers some parts of the whole
> picture. *.la's contain information pkg-config has not notion about,
yes
> and
> *.pc's can contain information libtool has no notion about.
yes
they serve two distinct purposes.
> (libtool-*.la's contain linker/library specific info. *.pc's basically
> are more or less a poor-man's registry/database and can contain
> arbitrary information).
yes, two distinct purposes.
> > I am contesting the claim "Libtool already has all the information
> > it needs".
> Agreed, but neither has pkg-config.
huh?
> It's just that their functionality
> intersects and partially conflicts.
how?
pkg-config is used to give basic information about installed packages.
libtool is used to build libraries.
pkg-config is used in configure scripts.
libtool is used in Makefiles.
yes, it's possible to use constructs like
foo.so: foo.o
${CC} ${LDFLAGS} -o foo.so foo.o `pkg-config bar --libs`
in Makefiles, but this is not overlap in a conflicting way. libtool
isn't even being used there. and if CC is libtool, then if it cannot
handle that command, then, well, libtool is the abberation, because
then it's not doing what it is supposed to do. libtool is supposed to
make building libraries/shared objects easier.
now, could you please tell me where pkg-config conflicts with libtool,
or why pkg-config is an "aberration", or why the libtool codebase
should be bloated to provide functionality already provided by
another commonly use package?
> Ralf
>
--
<[EMAIL PROTECTED]>
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Sat, 13 Nov 2004, Ralf Corsepius wrote: Well, current libtool does not support multilibs. If multilibs should ever be able to support them, I'd expect libtool having to examine the whole command being used, comprising CFLAGS and CPPFLAGS (There exist targets where multilib variants are being triggered by preprocessor flags) While some existing builds may be mis-using pre-processor flags, if libtool is updated to support multilibs, it should establish a more concrete method of specifying which architectural targets to build, and the surrounding build environments should be adapted to suit. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Fri, 2004-11-12 at 23:02 -0800, Jacob Meuser wrote: > On Sat, Nov 13, 2004 at 04:27:28AM +0100, Ralf Corsepius wrote: > > On Fri, 2004-11-12 at 14:31 -0800, Jacob Meuser wrote: > > > On Fri, Nov 12, 2004 at 03:33:02PM -0600, Albert Chin wrote: > > > > On Fri, Nov 12, 2004 at 11:20:13AM +, Gary V. Vaughan wrote: > > > > > Albert Chin wrote: > > > > > > On Wed, Nov 10, 2004 at 03:43:48PM +, Scott James Remnant wrote: > > > > > > > > > > > >>On Tue, 2004-11-09 at 14:24 +, Gary V. Vaughan wrote: > > > > > >> > > > > > >> > > > > > >>>6. Absorb the functionality of the aberration called pkg-config. > > > > > >>>Libtool > > > > > > > >>>already has all the information it needs, we just need to > > > > > >>> teach it (or > > > > > >>>maybe a subsidiary script) to spit out link flags after poking > > > > > >>> around > > > > > >>>in a dependency chain of .la files. > > > > > >> > > > > > >>There's actually a couple of things pkg-config does that Libtool > > > > > >>doesn't > > > > > >>currently do. pkg-config's main job can be summed up simply as > > > > > >>enabling > > > > > >>parallel-installed -dev packages. > > > > > > since when does libtool care about CFLAGS > > It hardly can avoid doing so if wanting to support multilibs. > > of course, it cares about _some_ CFLAGS at build time. it does not > care about where the headers are going to be installed though, or what > CPPFLAGS need to be set either ... functionality you do get from > pkg-config. Well, current libtool does not support multilibs. If multilibs should ever be able to support them, I'd expect libtool having to examine the whole command being used, comprising CFLAGS and CPPFLAGS (There exist targets where multilib variants are being triggered by preprocessor flags) > > > or package versions? > > It doesn't care about package versions, but it has to care about library > > versions and paths to libraries. > > again, functionality provided by pkg-config. No. Like libtool, pkg-config only covers some parts of the whole picture. *.la's contain information pkg-config has not notion about, and *.pc's can contain information libtool has no notion about. (libtool-*.la's contain linker/library specific info. *.pc's basically are more or less a poor-man's registry/database and can contain arbitrary information). > I am contesting the claim "Libtool already has all the information > it needs". Agreed, but neither has pkg-config. It's just that their functionality intersects and partially conflicts. Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Sat, Nov 13, 2004 at 04:27:28AM +0100, Ralf Corsepius wrote: > On Fri, 2004-11-12 at 14:31 -0800, Jacob Meuser wrote: > > On Fri, Nov 12, 2004 at 03:33:02PM -0600, Albert Chin wrote: > > > On Fri, Nov 12, 2004 at 11:20:13AM +, Gary V. Vaughan wrote: > > > > Albert Chin wrote: > > > > > On Wed, Nov 10, 2004 at 03:43:48PM +, Scott James Remnant wrote: > > > > > > > > > >>On Tue, 2004-11-09 at 14:24 +, Gary V. Vaughan wrote: > > > > >> > > > > >> > > > > >>>6. Absorb the functionality of the aberration called pkg-config. > > > > >>>Libtool > > > > > >>>already has all the information it needs, we just need to teach > > > > >>> it (or > > > > >>>maybe a subsidiary script) to spit out link flags after poking > > > > >>> around > > > > >>>in a dependency chain of .la files. > > > > >> > > > > >>There's actually a couple of things pkg-config does that Libtool > > > > >>doesn't > > > > >>currently do. pkg-config's main job can be summed up simply as > > > > >>enabling > > > > >>parallel-installed -dev packages. > > > > since when does libtool care about CFLAGS > It hardly can avoid doing so if wanting to support multilibs. of course, it cares about _some_ CFLAGS at build time. it does not care about where the headers are going to be installed though, or what CPPFLAGS need to be set either ... functionality you do get from pkg-config. > > or package versions? > It doesn't care about package versions, but it has to care about library > versions and paths to libraries. again, functionality provided by pkg-config. I am contesting the claim "Libtool already has all the information it needs". adding this to libtool is just bloat. pkg-config is not going to go away. it's too usefull and easy to use, and, believe it or not, not everyone uses autoconf/automake/libtool. > Ralf > -- <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Fri, 2004-11-12 at 14:31 -0800, Jacob Meuser wrote: > On Fri, Nov 12, 2004 at 03:33:02PM -0600, Albert Chin wrote: > > On Fri, Nov 12, 2004 at 11:20:13AM +, Gary V. Vaughan wrote: > > > Albert Chin wrote: > > > > On Wed, Nov 10, 2004 at 03:43:48PM +, Scott James Remnant wrote: > > > > > > > >>On Tue, 2004-11-09 at 14:24 +, Gary V. Vaughan wrote: > > > >> > > > >> > > > >>>6. Absorb the functionality of the aberration called pkg-config. > > > >>>Libtool > > > >>>already has all the information it needs, we just need to teach it > > > >>> (or > > > >>>maybe a subsidiary script) to spit out link flags after poking > > > >>> around > > > >>>in a dependency chain of .la files. > > > >> > > > >>There's actually a couple of things pkg-config does that Libtool doesn't > > > >>currently do. pkg-config's main job can be summed up simply as enabling > > > >>parallel-installed -dev packages. > > since when does libtool care about CFLAGS It hardly can avoid doing so if wanting to support multilibs. > or package versions? It doesn't care about package versions, but it has to care about library versions and paths to libraries. Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Fri, Nov 12, 2004 at 03:33:02PM -0600, Albert Chin wrote: > On Fri, Nov 12, 2004 at 11:20:13AM +, Gary V. Vaughan wrote: > > Albert Chin wrote: > > > On Wed, Nov 10, 2004 at 03:43:48PM +, Scott James Remnant wrote: > > > > > >>On Tue, 2004-11-09 at 14:24 +, Gary V. Vaughan wrote: > > >> > > >> > > >>>6. Absorb the functionality of the aberration called pkg-config. Libtool why is pkg-config an aberration? it's very useful for eliminating disgusting homegrown m4 macros from configure scripts because it's very easy to use. > > >>>already has all the information it needs, we just need to teach it > > >>> (or > > >>>maybe a subsidiary script) to spit out link flags after poking around > > >>>in a dependency chain of .la files. > > >> > > >>There's actually a couple of things pkg-config does that Libtool doesn't > > >>currently do. pkg-config's main job can be summed up simply as enabling > > >>parallel-installed -dev packages. since when does libtool care about CFLAGS or package versions? > > > What about non-libtool libraries wanting to benefit from pkg-config? > > > This will require them to spit out .la files rather than .pc files. > > > > Nope, to absorb pkg-config libtool will need to be aware of .pc files too. > > If libtool can't find a .la file, but there is a suitable .pc file in the > > search patch, libtool would pull the flags from there. > > Just gross! that's the understatement of the year. > -- > albert chin ([EMAIL PROTECTED]) > -- <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Fri, 12 Nov 2004, Albert Chin wrote: There's actually a couple of things pkg-config does that Libtool doesn't currently do. pkg-config's main job can be summed up simply as enabling parallel-installed -dev packages. What about non-libtool libraries wanting to benefit from pkg-config? This will require them to spit out .la files rather than .pc files. Nope, to absorb pkg-config libtool will need to be aware of .pc files too. If libtool can't find a .la file, but there is a suitable .pc file in the search patch, libtool would pull the flags from there. Just gross! I do not believe that libtool should ever know about pkg-config or its .pc files. Libtool should only know about compilers, linkers, and standard Unix utilities. Configure scripts may easily use pkg-config if they need to, and pass any necessary parameters on to libtool. This has been working fine for years. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Fri, Nov 12, 2004 at 11:20:13AM +, Gary V. Vaughan wrote: > Albert Chin wrote: > > On Wed, Nov 10, 2004 at 03:43:48PM +, Scott James Remnant wrote: > > > >>On Tue, 2004-11-09 at 14:24 +, Gary V. Vaughan wrote: > >> > >> > >>>6. Absorb the functionality of the aberration called pkg-config. Libtool > >>>already has all the information it needs, we just need to teach it (or > >>>maybe a subsidiary script) to spit out link flags after poking around > >>>in a dependency chain of .la files. > >> > >>There's actually a couple of things pkg-config does that Libtool doesn't > >>currently do. pkg-config's main job can be summed up simply as enabling > >>parallel-installed -dev packages. > > > > What about non-libtool libraries wanting to benefit from pkg-config? > > This will require them to spit out .la files rather than .pc files. > > Nope, to absorb pkg-config libtool will need to be aware of .pc files too. > If libtool can't find a .la file, but there is a suitable .pc file in the > search patch, libtool would pull the flags from there. Just gross! -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
Hi Albert! Albert Chin wrote: > On Wed, Nov 10, 2004 at 03:43:48PM +, Scott James Remnant wrote: > >>On Tue, 2004-11-09 at 14:24 +, Gary V. Vaughan wrote: >> >> >>>6. Absorb the functionality of the aberration called pkg-config. Libtool >>>already has all the information it needs, we just need to teach it (or >>>maybe a subsidiary script) to spit out link flags after poking around >>>in a dependency chain of .la files. >> >>There's actually a couple of things pkg-config does that Libtool doesn't >>currently do. pkg-config's main job can be summed up simply as enabling >>parallel-installed -dev packages. > > What about non-libtool libraries wanting to benefit from pkg-config? > This will require them to spit out .la files rather than .pc files. Nope, to absorb pkg-config libtool will need to be aware of .pc files too. If libtool can't find a .la file, but there is a suitable .pc file in the search patch, libtool would pull the flags from there. >>Principally it provides the right -L and -l flags to link libraries, we >>can get this from Libtool. An an improvement would then be only >>providing the dependency -l flags on platforms that need it, and not on >>Linux for example. A good idea! > Ick. Libtool is about portably building/using libraries. Why can't we > leave it at that? But linking against installed libraries using the correct -L and -l flags *is* part of portably building/using libraries! ;-) Haven't thought through the -I thing yet though... maybe that doesn't belong in libtool... maybe we could provide a macro that can intuit include directories from .la locations... I dunno... 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
Re: TODO
On Wed, Nov 10, 2004 at 03:43:48PM +, Scott James Remnant wrote: > On Tue, 2004-11-09 at 14:24 +, Gary V. Vaughan wrote: > > > 6. Absorb the functionality of the aberration called pkg-config. Libtool > > already has all the information it needs, we just need to teach it (or > > maybe a subsidiary script) to spit out link flags after poking around > > in a dependency chain of .la files. > > There's actually a couple of things pkg-config does that Libtool doesn't > currently do. pkg-config's main job can be summed up simply as enabling > parallel-installed -dev packages. What about non-libtool libraries wanting to benefit from pkg-config? This will require them to spit out .la files rather than .pc files. > Principally it provides the right -L and -l flags to link libraries, we > can get this from Libtool. An an improvement would then be only > providing the dependency -l flags on platforms that need it, and not on > Linux for example. Ick. Libtool is about portably building/using libraries. Why can't we leave it at that? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Wed, Nov 10, 2004 at 10:44:33PM +0100, Alexandre Duret-Lutz wrote: > Strictly speaking automake does not know these dependencies. It > knows some dependencies, but because of the possibility to > AC_SUBST variables for conditional linking, and doest not know > exactly all of them (think libfoo_la_DEPENDENCIES = @SOME_LA@). > However these dependencies are indeed known later at make time. I had forgotten. Bother. > Noah> If Automake generated an install target for installable > Noah> product, just as it generated a build target, would that > Noah> not solve this problem? > > This sounds appealing, but wouldn't this imply that if two > libraries depends on another one, the later will be installed > twice? Time stamp files would prevent that, but I don't know offhand how to handle @FOO@ cleanly. I'll play with a few ideas. Thanks for the feedback. ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Wed, 2004-11-10 at 12:17 -0600, Bob Friesenhahn wrote: > On Wed, 10 Nov 2004, Ralf Wildenhues wrote: > > >> However it *also* provides the right -I flags to point at the include > >> files. A GTK+ application will '#include ' for example > >> and require -I/usr/include/gtk-2.0 to actually be able to find that (or > >> -1.0, -3.0, etc.) > > > > That's a good feature. Dunno whether I want that (or it can even be) in > > a .la file or not. But letting libtool output both information might > > prove valuable. Absorbing pkgconfig in libtool in a way that each > > pkgconfig user must use libtool will pave way for quote some resistance, > > I'd expect. > > pkg-config does not issue the "right" -I flags. It merely proposes > some based on where the package is installed. This is fine if the > package is used in isolation. Sometimes these flags work ok in > conjuction with flags from other unrelated packages, but other times > it results in a bloody mess and wrong behavior. > It should never do ... the intent is that the directory specified by the -I flag *only* contains the include files of the given package; otherwise you'd be doing -I/usr/include or similar which pkg-config specifically removes from any output. Do you have an example of the wrong behaviour? Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
>>> "Noah" == Noah Misch <[EMAIL PROTECTED]> writes: Noah> On Wed, Nov 10, 2004 at 01:17:19AM +0100, Alexandre Duret-Lutz wrote: >> - the relinking dependency debacle: >> >> For libtool to relink libraries when installing them, all >> dependencies must have been installed. However automake cannot >> pre-compute this installation order when it is run, and >> computing it at compile-time look overly complicated and error >> prone. Instead, would it make sense to support a two-stage Noah> The core problem appears to be that an Automake-generated Noah> Makefile.in uses dependencies when building installable Noah> products but then installs them in destination_PRIMARY Noah> batches without observing the dependencies it already Noah> knows. Indeed, if Automake did not know the dependency Noah> graph of each object, it could not build them reliably. Strictly speaking automake does not know these dependencies. It knows some dependencies, but because of the possibility to AC_SUBST variables for conditional linking, and doest not know exactly all of them (think libfoo_la_DEPENDENCIES = @SOME_LA@). However these dependencies are indeed known later at make time. In other word Makefile.in and Makefile.am do not have the necessary information to compute an installation order, but Makefile does. So yes, this order could be recorded during the build. Libtool already does that, doesn't it? If so it seems easier to get the dependencies from it. Noah> If Automake generated an install target for installable Noah> product, just as it generated a build target, would that Noah> not solve this problem? This sounds appealing, but wouldn't this imply that if two libraries depends on another one, the later will be installed twice? -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Wed, 10 Nov 2004, Noah Misch wrote: A problem exists in that if a library is already installed on the system, it may be used by accident, either at build time, or at install time. This masks serious build/install ordering issues. Yes. Automake could unmask these issues by unlinking every file it is about to install before installing them. Unfortunately, this would keep the user from meaningfully specifying `install' options to, for example, make backup copies. As you say, using distcheck is a robust way to flush out these issues. This won't work reliably because it is older (i.e. different shared library version) libraries which cause the problem. The older shared libraries should not be unlinked. The existing libraries may be discovered in a different directory than the new libraries are being intalled in. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Wed, Nov 10, 2004 at 08:52:00PM +0100, Ralf Wildenhues wrote: > * Bob Friesenhahn wrote on Wed, Nov 10, 2004 at 08:31:15PM CET: > > On Wed, 10 Nov 2004, Noah Misch wrote: > > >If Automake descends into SUBDIRS to install in the same order it > > >does to build and uses `make' dependencies to ensure proper ordering > > >within each SUBDIR, then the products should relink/install in the > > >correct order. Right? > > > > That would be my assumption as well. The current library install > > mechanism does not ensure that libraries are installed in the same > > order that they are built. > > This statement seems to me to imply that Automake should be able to do > the job on its own, without any additional information from libtool, > given the library dependencies are stated correctly in the > Makefile.am's. I think so. Every working build order is a correct installation order. If the build succeeds, Automake knows one working build order. It therefore knows one workable installation order. > So, can the user not enforce inter-Makefile dependencies through the use > of `libfoo_la_DEPENDENCIES = sub/libbar.la' ? That would not improve installation order correctness at this time. > > A problem exists in that if a library is already installed on > > the system, it may be used by accident, either at build time, or at > > install time. This masks serious build/install ordering issues. > > Yes. Automake could unmask these issues by unlinking every file it is about to install before installing them. Unfortunately, this would keep the user from meaningfully specifying `install' options to, for example, make backup copies. As you say, using distcheck is a robust way to flush out these issues. > > Package developers usually already have the library installed on the > > system so they may not see the failure in their environment, but > > end-users do. 'make distcheck' helps significantly with discovering > > these problems. > > BTW, this topic shouldn't have any extra issues in the cases of staged > installs (checked by `make distcheck') and cross-compilation, right? I cannot think of any. ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
[ slightly reformatted ] * Bob Friesenhahn wrote on Wed, Nov 10, 2004 at 08:31:15PM CET: > On Wed, 10 Nov 2004, Noah Misch wrote: > >On Wed, Nov 10, 2004 at 12:28:24PM -0600, Bob Friesenhahn wrote: > >>The problem is that Automake does *not* know the dependency graph of > >>each object. Within one Makefile, this is possible (and mostly > >>supported) but most projects depend on SUBDIRS to recurse though > >>subordinate Makefiles so there is no full dependency graph of each > >>object. The build is dependent on careful ordering by the developer > >>rather than Makefile dependencies. > > > >Thanks for the correction. > > > >If Automake descends into SUBDIRS to install in the same order it > >does to build and uses `make' dependencies to ensure proper ordering > >within each SUBDIR, then the products should relink/install in the > >correct order. Right? > > That would be my assumption as well. The current library install > mechanism does not ensure that libraries are installed in the same > order that they are built. This statement seems to me to imply that Automake should be able to do the job on its own, without any additional information from libtool, given the library dependencies are stated correctly in the Makefile.am's. So, can the user not enforce inter-Makefile dependencies through the use of `libfoo_la_DEPENDENCIES = sub/libbar.la' ? > A problem exists in that if a library is already installed on > the system, it may be used by accident, either at build time, or at > install time. This masks serious build/install ordering issues. Yes. > Package developers usually already have the library installed on the > system so they may not see the failure in their environment, but > end-users do. 'make distcheck' helps significantly with discovering > these problems. BTW, this topic shouldn't have any extra issues in the cases of staged installs (checked by `make distcheck') and cross-compilation, right? Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Wed, 10 Nov 2004, Noah Misch wrote: On Wed, Nov 10, 2004 at 12:28:24PM -0600, Bob Friesenhahn wrote: The problem is that Automake does *not* know the dependency graph of each object. Within one Makefile, this is possible (and mostly supported) but most projects depend on SUBDIRS to recurse though subordinate Makefiles so there is no full dependency graph of each object. The build is dependent on careful ordering by the developer rather than Makefile dependencies. Thanks for the correction. If Automake descends into SUBDIRS to install in the same order it does to build and uses `make' dependencies to ensure proper ordering within each SUBDIR, then the products should relink/install in the correct order. Right? That would be my assumption as well. The current library install mechanism does not ensure that libraries are installed in the same order that they are built. A problem exists in that if a library is already installed on the system, it may be used by accident, either at build time, or at install time. This masks serious build/install ordering issues. Package developers usually already have the library installed on the system so they may not see the failure in their environment, but end-users do. 'make distcheck' helps significantly with discovering these problems. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Wed, Nov 10, 2004 at 12:28:24PM -0600, Bob Friesenhahn wrote: > The problem is that Automake does *not* know the dependency graph of > each object. Within one Makefile, this is possible (and mostly > supported) but most projects depend on SUBDIRS to recurse though > subordinate Makefiles so there is no full dependency graph of each > object. The build is dependent on careful ordering by the developer > rather than Makefile dependencies. Thanks for the correction. If Automake descends into SUBDIRS to install in the same order it does to build and uses `make' dependencies to ensure proper ordering within each SUBDIR, then the products should relink/install in the correct order. Right? ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Wed, 10 Nov 2004, Gary V. Vaughan wrote: It wouldn't be at all difficult to have 'libtoolize --ltdl --disable-nls' install a non-internationalised libltdl minus message catalogues into a parent package. But yes, we would have to take care to do it carefully. An improved post-2.0 testsuite should help there :-) There are oodles of dangers here. For example, a package distribution maintainer for a particular OS may not agree with the package developer's choices so he will install his own libltdl with the extra message catalogues. This could make things very confusing/difficult for the package developer. There is already plenty of confusion caused by package distribution maintainers who replace the existing libtool in a package with one that they prefer. On the flip side, the package developer may choose to distribute an internationalized libltdl, which causes new issues for end-users and package distribution maintainers. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
Daniel Reed wrote: On 2004-11-09T18:19-, Gary V. Vaughan wrote: ) Ralf Wildenhues wrote: ) > * Gary V. Vaughan wrote on Tue, Nov 09, 2004 at 03:24:25PM CET: ) >>3.5. While we are there, maybe internationalise libltdl? ) > Please don't. If you do, make it possible to have zero(!) overhead for ) > ltdl users if they choose not to make use of the translation capability. ) Do you mean zero runtime overhead? That's easy, and fairly standard already: ) ) #ifndef _ ) # ifdef ENABLE_NLS ) #include ) #define _(Text) gettext ((Text)) ) # else ) #define _(Text) (Text) ) # endif ) #endif ) ) There are a few other tweaks that need to be done (see CVS M4), but for ) brevity I'll spare you the details :-) ) ) Obviously message catalogues and the like will make the distribution bigger ) though. As this trick takes effect at compile time, would this require that an embedded libltdl grow in size even if the functionality is never used? This is only part of the magic, but is the only change in the source code. If so, I think the point is to allow packagers who embed libltdl in other packages to choose a prenoninternationalized version (so the noni18n occurs at repackaging time rather than compile time). It wouldn't be at all difficult to have 'libtoolize --ltdl --disable-nls' install a non-internationalised libltdl minus message catalogues into a parent package. But yes, we would have to take care to do it carefully. An improved post-2.0 testsuite should help there :-) 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
Re: TODO
On 2004-11-09T18:19-, Gary V. Vaughan wrote: ) Ralf Wildenhues wrote: ) > * Gary V. Vaughan wrote on Tue, Nov 09, 2004 at 03:24:25PM CET: ) >>3.5. While we are there, maybe internationalise libltdl? ) > Please don't. If you do, make it possible to have zero(!) overhead for ) > ltdl users if they choose not to make use of the translation capability. ) Do you mean zero runtime overhead? That's easy, and fairly standard already: ) ) #ifndef _ ) # ifdef ENABLE_NLS ) #include ) #define _(Text) gettext ((Text)) ) # else ) #define _(Text) (Text) ) # endif ) #endif ) ) There are a few other tweaks that need to be done (see CVS M4), but for ) brevity I'll spare you the details :-) ) ) Obviously message catalogues and the like will make the distribution bigger ) though. As this trick takes effect at compile time, would this require that an embedded libltdl grow in size even if the functionality is never used? If so, I think the point is to allow packagers who embed libltdl in other packages to choose a prenoninternationalized version (so the noni18n occurs at repackaging time rather than compile time). -- Daniel Reed <[EMAIL PROTECTED]> http://people.redhat.com/djr/ http://naim.n.ml.org/ The open source world considers many of its large projects as benevolent dictatorships. It's a democracy only in the sense that cyberspace is infinite so anyone who doesn't like it can move out. -- Alan Cox ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Wed, 10 Nov 2004, Noah Misch wrote: On Wed, Nov 10, 2004 at 01:17:19AM +0100, Alexandre Duret-Lutz wrote: - the relinking dependency debacle: For libtool to relink libraries when installing them, all dependencies must have been installed. However automake cannot pre-compute this installation order when it is run, and computing it at compile-time look overly complicated and error prone. Instead, would it make sense to support a two-stage The core problem appears to be that an Automake-generated Makefile.in uses dependencies when building installable products but then installs them in destination_PRIMARY batches without observing the dependencies it already knows. Indeed, if Automake did not know the dependency graph of each object, it could not build them reliably. The problem is that Automake does *not* know the dependency graph of each object. Within one Makefile, this is possible (and mostly supported) but most projects depend on SUBDIRS to recurse though subordinate Makefiles so there is no full dependency graph of each object. The build is dependent on careful ordering by the developer rather than Makefile dependencies. If Automake generated an install target for installable product, just as it generated a build target, would that not solve this problem? Like so: It *should* do this for libraries built from within the Makefile, but currently it does not. Instead it simply goes though the LTLIBRARIES list in each Makefile and installs in that order. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Wed, 10 Nov 2004, Ralf Wildenhues wrote: However it *also* provides the right -I flags to point at the include files. A GTK+ application will '#include ' for example and require -I/usr/include/gtk-2.0 to actually be able to find that (or -1.0, -3.0, etc.) That's a good feature. Dunno whether I want that (or it can even be) in a .la file or not. But letting libtool output both information might prove valuable. Absorbing pkgconfig in libtool in a way that each pkgconfig user must use libtool will pave way for quote some resistance, I'd expect. pkg-config does not issue the "right" -I flags. It merely proposes some based on where the package is installed. This is fine if the package is used in isolation. Sometimes these flags work ok in conjuction with flags from other unrelated packages, but other times it results in a bloody mess and wrong behavior. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Wed, Nov 10, 2004 at 01:17:19AM +0100, Alexandre Duret-Lutz wrote: > - the relinking dependency debacle: > > For libtool to relink libraries when installing them, all > dependencies must have been installed. However automake cannot > pre-compute this installation order when it is run, and > computing it at compile-time look overly complicated and error > prone. Instead, would it make sense to support a two-stage The core problem appears to be that an Automake-generated Makefile.in uses dependencies when building installable products but then installs them in destination_PRIMARY batches without observing the dependencies it already knows. Indeed, if Automake did not know the dependency graph of each object, it could not build them reliably. If Automake generated an install target for installable product, just as it generated a build target, would that not solve this problem? Like so: -- Makefile.am lib_LTLIBRARIES = foo.la bar.la foo_la_LIBADD = bar.la -- Makefile.in foo.la: bar.la $(LIBTOOL) ... install-foo.la: install-bar.la $(INSTALL) ... install-bar.la: $(INSTALL) ... ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
