Re: totally confused by versioning system of libtool...
On Fri, 13 May 2005, Ed Hartnett wrote: Bob Friesenhahn [EMAIL PROTECTED] writes: That implies that when I install a new version, the old version says around. Is that correct? Yes. Unless it is explicitly deleted. Suppose that we discover a bug which doesn't require any API change to fix, but which will cause he users' computers to go into self-destruct mode, and catch on fire. ... But now, we have the additional option of deleting the version of the library file that contains the bug, during the install of the next version. Then, their applications would crash horribly. But at least their computer would not explode. Do not simply delete the broken file, replace it. If libexample-0.0.0, which installs as libexample.so.0, contains a bug, release a bug fix libexample-0.0.1, which will also install as libexample.so.0, replacing the broken version. Programs that were running at the time of the upgrade will continue to use the buggy version (even if the file is removed from the directory hierarchy, it will be kept available for processes that had it open before it was removed). Programs that start after the upgrade will automatically use the new version, with no relinking or explosions, horrible or otherwise. Many projects will continue to make bug fix releases even if a newer API is currently under development--including Libtool itself. For this example scenario, if libexample-1.0.2 is the current release, but a critical bug is found in both it and libexample-0.0.5, then you can feel free to release libexample-0.0.6 and libexample-1.0.3 at the same time. People using software that depends on libexample's 0 series will get the bug fix without having to rebuild or, worse, rewrite their software. People using software that depends on libexample's 1 series should not be confused by the new release for the older 0 series, because 0.0.6 is still less than 1.0.anything. The only down side is that installing libexample 0.0.6 might cause libexample.so to be re-pointed to libexample.so.0 and libexample 0's headers to overwrite libexample 1's headers, so software that is compiled after an upgrade might be forced to use the libexample 0 API and ABI instead of libexample 1's (which would not necessarily cause explosions, just different-than-expected but still functional behavior). The next time the libexample 1 series was upgraded everything would go back to normal. -- Daniel Reed [EMAIL PROTECTED] http://naim-users.org/nmlorg/ http://naim.n.ml.org/ The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: totally confused by versioning system of libtool...
On Fri, 13 May 2005, Daniel Reed wrote: People using software that depends on libexample's 1 series should not be confused by the new release for the older 0 series, because 0.0.6 is still less than 1.0.anything. The only down side is that installing libexample 0.0.6 might cause libexample.so to be re-pointed to libexample.so.0 and libexample 0's headers to overwrite libexample 1's headers, so software that is compiled after an upgrade might be forced to use the libexample 0 API and ABI instead of libexample 1's (which would not necessarily cause explosions, And a potential scenario where the symlink/la mismatch can occur, causing explosions: If the 0 series did not use Libtool, and hence never installed an la file, but the 1 series does use Libtool, and hence installs an la file. Installing libexample 1.0.2 will cause /usr/lib/libexample.la and /usr/lib/libexample.so to both be created, each pointing to libexample.so.1 . It will install its header files, defining structs and function prototypes, into /usr/include . Then installing libexample 0.0.6 will cause only /usr/lib/libexample.so to be overwritten, not /usr/lib/libexample.la, because libexample's 0 series did not use Libtool. libexample 0.0.6 will also install its header files over libexample 1.0.2's--which is correct as long as the linker will use libexample.so.0 when linking with -lexample, because your program would need libexample 0's prototypes and structs to properly link. Executables that are built by hand or otherwise not using Libtool will have -lexample passed to the linker, which will resolve based on the symlink, correctly matching libexample 0's header files to libexample.so.0 . Executables built by Libtool will resolve -lexample based on libexample.la, incorrectly matching libexample 0's header files to libexample.so.1 . This can cause a compile-time failure if the API changed in certain ways (such as the removal of a function that the program believe existed due to a #define), but may cause mysterious run-time failures more often (such as if a function changed from accepting an int to accepting a float, or if a new element was added to a struct shared by the library and the program). just different-than-expected but still functional behavior). The next time the libexample 1 series was upgraded everything would go back to normal. This is still true regardless, though. The moral is, if you do release an update to an older branch, make sure care is given that either it both won't overwrite already-installed headers nor update libexample.so, or will update/remove an installed .la file it wouldn't normally replace. That is, it either has to repoint all potential compile/link-time references to itself, or it has to repoint none of them. The simplest way to do that might be to go back and convert older trees to use Libtool just for a bugfix release. -- Daniel Reed [EMAIL PROTECTED] http://naim-users.org/nmlorg/ http://naim.n.ml.org/ A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. -- Douglas Adams, Novelist ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: totally confused by versioning system of libtool...
On Fri, 13 May 2005, Ed Hartnett wrote: Daniel Reed [EMAIL PROTECTED] writes: Many projects will continue to make bug fix releases even if a newer API is currently under development--including Libtool itself. For this example scenario, if libexample-1.0.2 is the current release, but a critical bug is found in both it and libexample-0.0.5, then you can feel free to release libexample-0.0.6 and libexample-1.0.3 at the same time. So this is not actually replacing libexample-0.0.5, it is adding libexample-0.0.6, and the loader is smart enough to automatically use that in preference to libexample-0.0.5. Sort of. Parallel install of runtime support files (such as runtime libraries) is accomplished by reducing the versioning information of the installed files to the point where all distinguishing characteristics related to binary compatibility are kept, but everything else is dropped. When you install libexample-0.0.5, it may install three files in your lib dir: libexample.so.0.0.5, libexample.so.0, and libexample.so . The latter two may be symlinks to the former. When you link a program using -lexample, it will look at libexample.so and see that its internal name is libexample.so.0, and so will store that name in the program. When the program starts up, it will ask the runtime loader to find libexample.so.0 for it, and it will find libexample.so.0 a symlink to libexample.so.0.0.5 and use it. If you then install libexample 0.0.6, it may install libexample.so.0.0.6 and change the symlinks to point to that, leaving libexample.so.0.0.5 on the disk. However, only the files libexample.so and libexample.so.0 are ever directly accessed; programs that were linked with -lexample when libexample.so pointed to libexample.so.0.0.5 only know that libexample.so.0 is what they want, they don't necessarily care what specific version of the file is installed. So, changing /usr/lib/libexample.so.0 to point to libexample.so.0.0.6 instantly makes it so any program linked against libexample.so.0 will use libexample.so.0.0.6. libexample.so.0.0.5 will therefore no longer be used, for any purpose. In that way, libexample 0.0.6 is replacing libexample 0.0.5. Is that correct? And libexample-0.0.5 stays on the users' systems until they feel like deleting it, but it is ignored by the loader because a fresher version exists. Yes; libexample.so.0.0.5 may remain on the disk, but it will never be used, even by software that was originally linked against it. But I don't understand why it's not 0.5.0 and 0.6.0. That is, wouldn't it be a case of incrementing the minor version number, the middle number? If libexample 0.0.6 is merely a bug fix, it is usually customary to only updated the least significant number in the version string. Customarily, however, only the very first number is ever used for runtime linking (so libexample 0.0.0, libexample 0.0.1, and libexample 0.1.0 would all replace each other, but libexample 0.1.0 and libexample 1.0.0 could be installed in parallel). would not necessarily cause explosions, just different-than-expected but still functional behavior). The next time the libexample 1 series was upgraded everything would go back to normal. But if we were updating two versions of our software at once, we could do it in the correct order, so that libexample 1 is done after libexample 0. Is that correct? If you have control over the practices of everyone who will be using your library, then yes, you can guarantee it will be done in the least-confusing order. In general, however, you don't have such control, which is why many operating system distributors use a convention of keeping the runtime support files separated from the compile-time or development files. A package called libexample might include libexample.so.0.0.5 and libexample.so.0 but not libexample.so, because only the versioned files are needed for runtime; libexample.so is only needed to link new programs. A package called libexample-devel might include the symlink libexample.so and header files. You could end up with something like: libexample-0.0.5: /usr/lib/libexample.so.0.0.5 /usr/lib/libexample.so.0 - libexample.so.0.0.5 libexample-1.0.2: /usr/lib/libexample.so.1.0.2 /usr/lib/libexample.so.1 - libexample.so.1.0.2 libexample-devel-1.0.2: /usr/lib/libexample.so - libexample.so.1 /usr/include/example.h Then upgrading libexample-0.0.5 to libexample-0.0.6 would never cause discrepencies, because it only would touch libexample.so.0.0.x and libexample.so.0, never libexample.so nor the header files. When libexample 1.0.3 was installed, it would cause libexample-devel 1.0.3 to be installed too, updating all of libexample.so.1.0.x, libexample.so.1, libexample.so, and example.h. Any number of base packages could be installed, but only one development package would be allowed. But this is not a function of Libtool. -- Daniel Reed [EMAIL PROTECTED] http://naim-users.org/nmlorg/ http
Re: multilib2 patch (was: another 1.5 release)
On 2004-12-08T18:47+0100, Ralf Wildenhues wrote: ) Before as well as after your change, the first part of the search ) algorithm finds the libstdc++.la which belongs to the 32bit version ) and shortcuts your second part. Linking tests/tagdemo/libfoo.la fails ) happily. If something is specifying -Ltests/tagdemo on the command line, it should fail. This seems to indicate something is adding a -L option that shouldn't have been added. It appears gcc can not be made to include user-specified search paths in its -print-file-name functionality, so Libtool still needs to check -L paths itself before asking gcc. As to inclusion in RHEL4, my group officially moved off of RHEL4 development yesterday, and I was asked to close the tracker that would have allowed an update for the initial release. Unless something drastic happens, we will be shipping 1.5.6 with 1.4-nonneg, 1.5-libtool.m4-x86_64, 1.4.2-multilib, 1.4.2-demo, and 1.5-testfailure applied. I will try to get something based on 1.5.10 with multilib2 or a newer 1.5 in the first update (in 3 months). -- Daniel Reed [EMAIL PROTECTED] http://people.redhat.com/djr/ http://naim.n.ml.org/ Murphy's Law is recursive. Washing your car to make it rain doesn't work. ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: another 1.5 release
On 2004-12-03T11:08+0100, Ralf Wildenhues wrote: ) * Scott James Remnant wrote on Fri, Dec 03, 2004 at 10:06:01AM CET: ) On Thu, 2004-12-02 at 18:36 -0500, Daniel Reed wrote: ) Is there any chance .multilib2 can be incorporated into 1.5.12? As written, ) it simply causes libtool to ask gcc to find .la files if gcc is in use. It ) should have no impact on non-gcc builds and should not cause any files to be ) missed (the original behavior is used if gcc is unable to find a requested ) file). ) Do you have a copy of the patch to be considered? ) http://lists.gnu.org/archive/html/libtool-patches/2004-11/msg00123.html Yep, that is still the latest version. Instead of munging sys_lib_search_path_spec, this new patch causes Libtool to use gcc's -print-file-name feature if present. This has an added benefit of theoretically supporting multilib on non-Linux, gcc-using systems. It may also more-closely fit Libtool's .la search algorithm with what GCC uses. With the patch, Libtool will continue to honor -L paths first, then attempt to use gcc -print-file-name, then fall back on $sys_lib_search_path and $shlib_search_path. It should fail to use gcc -print-file-name gracefully if either gcc is not in use or the gcc in use does not support -print-file-name. -- 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: another 1.5 release
On 2004-12-03T11:48-0600, Bob Friesenhahn wrote: ) On Fri, 3 Dec 2004, Albert Chin wrote: ) Shouldn't we come up with a more general solution first? Embedding ) knowledge of a specific compiler in ltmain.sh is wrong. That's what ) libtool.m4 is for. The GCC-specific code operates (and must operate) per libtool invocation, not at configure time. GCC is used to find the files if a) GCC is in use (as determined by configure) and b) the GCC in use supports -print-file-name (as determined per libtool invocation). It might make sense to move the check to see if GCC supports -print-file-name into configure, but that would be an optimization rather than a user-visible behavior change. ) Is there general consensus of this patch as a model for other ) platforms (Solaris, Linux with non-GCC compilers, IRIX, etc.)? It ) seems way too Linux-specific to me. The patch is specific to GCC, not Linux. Any operating system that uses a multilib-capable GCC should be supported by the code introduced in this patch. ) that only bug-fixes should appear in branch-1-5 and this smells like a ) new feature to me. Since branch-2-0 has not yet produced a release, The patch is to solve the following problem: [EMAIL PROTECTED]:~/libtool-1.5.10_orig-build$ ./libtool --mode=link gcc -m64 -shared -o library.so -lpopt gcc -m64 -shared -o library.so /usr/lib/libpopt.so /usr/lib/libpopt.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status [EMAIL PROTECTED]:~/libtool-1.5.10_orig-build$ Like this: [EMAIL PROTECTED]:~/libtool-1.5.10-build$ ./libtool --mode=link gcc -m64 -shared -o library.so -lpopt gcc -m64 -shared -o library.so /usr/lib64/libpopt.so -Wl,--rpath -Wl,/usr/lib64 -Wl,--rpath -Wl,/usr/lib64 [EMAIL PROTECTED]:~/libtool-1.5.10-build$ Software packaged with a stock Libtool must be relibtoolized before it can be built in a multilib (64-bit and 32-bit compat) environment. Red Hat has been shipping a Libtool package with a Linux-specific patch since multilib became a supported target; I would like to see a more generic fix introduced upstream so Red Hat will not have to continue patching Libtool. -- Daniel Reed [EMAIL PROTECTED] http://people.redhat.com/djr/ http://naim.n.ml.org/ Murphy's Law is recursive. Washing your car to make it rain doesn't work. ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: another 1.5 release
On 2004-12-03T13:03-0600, Bob Friesenhahn wrote: ) On Fri, 3 Dec 2004, Daniel Reed wrote: ) The patch is specific to GCC, not Linux. Any operating system that uses a ) multilib-capable GCC should be supported by the code introduced in this ) patch. ) Profound changes like this should not be introduced in a bug-fix ) branch. Unfortunately, this problem must be resolved before Red Hat can ship Libtool. That is, either I have to see multilib support added to the stock Libtool or Red Hat will have to continue shipping a patched Libtool. We can not ship a non-multilib-aware Libtool: Without multilib support in Libtool, parts of our distribution do not build on some of our supported targets. (Specifically, any package that links against the libraries of another package, where such required libraries were built by Libtool and have .la files installed *and* where both 32-bit and 64-bit versions of said libraries are installed, fails to build.) Right now, Red Hat is shipping a Libtool patched to add Red Hat Linux-specific support (1.4.2-multilib); I would prefer to use GCC-specific support (such as 1.5.10.multilib2) instead. However, if both multilib patches are deemed inappropriate for canonical branch-1-5 and no third style of multilib support can be proposed in the next two weeks, I have to make a decision as to which existing patch to use in our [patched] Libtool package. So, if neither multilib patch can be added for 1.5.12, which one would be best to patch into our Libtool? My preference is to go with .multilib2, but it will be a harder sell to QA to allow changing our Libtool package if only to change which upstream-rejected patch we use :/ -- Daniel Reed [EMAIL PROTECTED] http://people.redhat.com/djr/ http://naim.n.ml.org/ It's true you can be anything you want--but it's far easier when your ambition is complemented by the ambition of others. -- Kurt Vonnegut ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: another 1.5 release
On 2004-12-03T17:18-0600, Bob Friesenhahn wrote: ) It is certainly much safer and wiser to make such changes to HEAD. ) It supports proving that the changes don't break for GCC users on ) other platforms without placing a stable release branch at risk. The ) reason for stable release branches is so that minor releases may be ) made without requiring re-testing the software on all supported Libtool 1.5.10 with .multilib2 (and .nopicfix2) passes all test suite checks on Linux i386 and x86_64 (and ppc, ppc64, ia64, s390, and s390x). As the changed behavior a) is isolated to the discovery of libraries on the link line, b) is only activated when GCC is in use, and c) only makes Libtool behave as GCC would have behaved if it were used directly (by causing Libtool to *use* GCC directly), the impact to all environments should be statistically identical to the impact on any one multilib environment or non-multilib environment (for untested environments that are multilib or non-multilib, respectively). That is, if Libtool+multilib2 is able to find libraries in Linux/i386, it is because GCC is able to find libraries in Linux/i386. If Libtool+multilib2 is unable to find libraries in Solaris/i386, it is because GCC itself is unable to find libraries in Solaris/i386. In this situation (where GCC itself is unable to handle -lfoo), Libtool's original library-finding algorithms are used to satisfy libtool ... -lfoo. I do not believe the behavior is a potential danger. At worst, faults in my implementation should be the only risk. ) I believe that we should adhere to Albert Chin's advice that compiler ) feature tests should be restricted to libtool.m4. The check for GCC is done outside of the scope of the change; all that is checked in the new code is whether -print-file-name works, which will pass for all recent versions of GCC. -- Daniel Reed [EMAIL PROTECTED] http://people.redhat.com/djr/ http://naim.n.ml.org/ It is a miracle that curiosity survives formal education. -- Albert Einstein, Physicist ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: another 1.5 release
On 2004-11-30T11:31-0500, Daniel Reed wrote: ) for multilib to be made available in branch-1-5 (possibly by incorporating ) .multilib2 into 1.5.12). It's looking like I may be able to get current Libtool into the final RHEL 4 release. Is there any chance .multilib2 can be incorporated into 1.5.12? As written, it simply causes libtool to ask gcc to find .la files if gcc is in use. It should have no impact on non-gcc builds and should not cause any files to be missed (the original behavior is used if gcc is unable to find a requested file). -- Daniel Reed [EMAIL PROTECTED] http://people.redhat.com/djr/ http://naim.n.ml.org/ he didn't speak much english, but i think he recognized the leatherman as a weapon -- sour, EFnet #naim ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: another 1.5 release
On 2004-11-30T23:01+0900, Peter O'Gorman wrote: ) Prior to releasing this I'd like to hear from libtool package maintainers on ) various distributions if they are patching their libtool packages, what the ) patches are, and if we can get them into HEAD and the stable branch prior to Red Hat's currently-supported base platforms[*] are RHEL 2.1, RHEL 3, FC 2, FC 3, RHEL 4 (in beta/QA), and FC 4 (in development). As shipping in the latest release/update pack for each: (inherited from RHL 7.2) RHEL-2_1/libtool.spec:Version: 1.4 RHEL-2_1/libtool.spec:Release: 8 RHEL-2_1/libtool.spec:Patch1: libtool-1.3.5-mktemp.patch RHEL-2_1/libtool.spec:Patch2: libtool-1.4-nonneg.patch RHEL-2_1/libtool.spec:Patch3: libtool-1.4-test.patch RHEL-2_1/libtool.spec:Patch4: libtool-1.4-cvs.patch RHEL-2_1/libtool.spec:Patch5: libtool-1.4.6-s390.patch (inherited from RHL 9) RHEL-3/libtool.spec:Version: 1.4.3 RHEL-3/libtool.spec:Release: 6 RHEL-3/libtool.spec:Patch1: libtool-1.3.5-mktemp.patch RHEL-3/libtool.spec:Patch2: libtool-1.4-nonneg.patch RHEL-3/libtool.spec:Patch4: libtool-1.4.2-s390_x86_64.patch RHEL-3/libtool.spec:Patch6: libtool-1.4.2-relink-58664.patch RHEL-3/libtool.spec:Patch9: libtool-1.4.2-multilib.patch RHEL-3/libtool.spec:Patch10: libtool-1.4.2-demo.patch FC-2/libtool.spec:Version: 1.5.6 FC-2/libtool.spec:Release: 1 FC-2/libtool.spec:Patch2: libtool-1.4-nonneg.patch FC-2/libtool.spec:Patch4: libtool-1.5-libtool.m4-x86_64.patch FC-2/libtool.spec:Patch9: libtool-1.4.2-multilib.patch FC-2/libtool.spec:Patch10: libtool-1.4.2-demo.patch FC-2/libtool.spec:Patch14: libtool-1.5-testfailure.patch FC-3/libtool.spec:Version: 1.5.6 FC-3/libtool.spec:Release: 4 FC-3/libtool.spec:Patch2: libtool-1.4-nonneg.patch FC-3/libtool.spec:Patch4: libtool-1.5-libtool.m4-x86_64.patch FC-3/libtool.spec:Patch9: libtool-1.4.2-multilib.patch FC-3/libtool.spec:Patch10: libtool-1.4.2-demo.patch FC-3/libtool.spec:Patch14: libtool-1.5-testfailure.patch (inherited from FC 3) RHEL-4/libtool.spec:Version: 1.5.6 RHEL-4/libtool.spec:Release: 4 RHEL-4/libtool.spec:Patch2: libtool-1.4-nonneg.patch RHEL-4/libtool.spec:Patch4: libtool-1.5-libtool.m4-x86_64.patch RHEL-4/libtool.spec:Patch9: libtool-1.4.2-multilib.patch RHEL-4/libtool.spec:Patch10: libtool-1.4.2-demo.patch RHEL-4/libtool.spec:Patch14: libtool-1.5-testfailure.patch (FC 4) devel/libtool.spec:Version: 1.5.10 devel/libtool.spec:Release: 1 I have removed all of Red Hat's patches for FC 4 (and hence RHEL 5 and beyond), but it may be causing some multilib-related build problems in our build roots. I would like to either receive approval from the list to re-enable libtool-1.4.2-multilib.patch (which I posted some months ago, but was generally not accepted), receive approval to enable libtool-1.5.10.multilib2 (which I posted recently), or be advised to wait for a different approach for multilib to be made available in branch-1-5 (possibly by incorporating .multilib2 into 1.5.12). [*] We still provide support for and updates to these six operating systems. Previous operating systems, such as Red Hat Linux 9 and below and Fedora Core 1, are no longer supported or maintained by Red Hat. Updates for these operating systems can only be made through the third parties such as the Fedora Legacy project (http://fedoralegacy.org/), which I do not speak for. (Still catching up on Thanksgiving backlog.) -- Daniel Reed [EMAIL PROTECTED] http://people.redhat.com/djr/ Desktop CMC ___ 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
../libcadet.la libcadet.la) (22:07)[EMAIL PROTECTED]:~/test env LD_LIBRARY_PATH=.libs ldd .libs/service libcadet.so.0 = .libs/libcadet.so.0 (0xf6ffe000) libgeneral.so.0 = .libs/libgeneral.so.0 (0xf6ffb000) libadmiral.so.0 = .libs/libadmiral.so.0 (0xf6ff9000) libc.so.6 = /lib/tls/libc.so.6 (0x00703000) libgeneral2.so.0 = /home/boston/dreed/test/.libs/libgeneral2.so.0 (0xf6fd7000) /lib/ld-linux.so.2 (0x006ea000) (22:07)[EMAIL PROTECTED]:~/test Brilliant. Because service was not recompiled against the new libcadet.la, it now links against both libgeneral.so and libgeneral2.so (the latter by way of the new libcadet.so) :( In situations where only the .so is present, Libtool arguably does the right thing. (It does not try to guess dependency dependencies based on ldd or anything like that; it just doesn't link in dependency dependencies.) In situations where the .la is present, Libtool *does* try to link in dependency dependencies, even though that isn't necessary. I believe the point of this proposed change is to eliminate that latter behavior. It would be a benefit on Linux and similar systems without directly hindering dissimilar systems (as the behavior would not change on those systems). As far as encouraging developers to list dependencies incorrectly or not at all, in the above scenario, even if the package developer had caused the service executable's build scripts to link explicitly against its dependencies dependencies (libgeneral, in this case), it still would have broken on systems that do not implicitly link dependencies dependencies at run time (as service would have been explicitly linked with libgeneral, not libgeneral2, just as with the current Libtool behavior when dealing with .la files). I do not believe there is a developer education danger from this proposed change. -- Daniel Reed [EMAIL PROTECTED] http://people.redhat.com/djr/ http://naim.n.ml.org/ Murphy's Law is recursive. Washing your car to make it rain doesn't work. ___ 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 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/package or /opt/provider directory tree, where package is a name that describes the software package and provider 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 [ATT 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/package, including files intended to be copied into /etc/opt/package and /var/opt/package 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: GNU Libtool 1.5.10 released.
On 2004-09-19T23:15+0900, Peter O'Gorman wrote: ) New in 1.5.10: September 19th 2004 ) ) * GNU/linux ia64 fixes. This is definitely the case; make check passes on all of the architectures in Red Hat's FC3 build root, including ia64, without patches. Thanks. ) * Works on platforms with no c++ compiler. This is true, but I am a little underwhelmed. After retooling with 1.5.10, my naim tarballs have increased significantly in size: -rw-r--r-- 543971 Sep 18 19:16 naim-0.11.7.3-2004-09-18-1916.tar.bz2 -rw-r--r-- 616059 Sep 19 12:14 naim-0.11.7.3-2004-09-19-1214.tar.bz2 Previously, I had been using an older libtool.m4 with a few lines removed as my acinclude.m4. This caused ./configure to not check for a C++ or Fortran compiler at all, as C++ and Fortran support are not even optionally useful in my package. I am now using no acinclude.m4, and am letting aclocal find libtool.m4 in share/aclocal/. The C++ and Fortran checks are performed, and are failing gracefully (without taking down the whole ./configure), but: ... -rw-r--r-- 2847 Jun 7 2003 README.es 2847 Jun 7 2003 README.es -rw-r--r-- 1176 Feb 1 2004 TODO 1176 Feb 1 2004 TODO -rw-r--r-- 219075 Nov 26 2003 acinclude.m4 -rw-r--r-- 28226 Sep 18 15:07 aclocal.m4 239043 Sep 19 12:10 aclocal.m4 -rwxr-xr-x 3642 Jan 16 2004 compile* 3642 Jan 16 2004 compile* -rwxr-xr-x 42918 Jan 16 2004 config.guess* 42918 Jan 16 2004 config.guess* -rwxr-xr-x 30925 Jan 16 2004 config.sub* 30925 Jan 16 2004 config.sub* -rwxr-xr-x 446922 Sep 18 15:07 configure* 796712 Sep 19 12:11 configure* -rw-r--r-- 8993 Sep 18 15:06 configure.in 8993 Sep 19 12:10 configure.in drwxr-xr-x 80 Sep 18 19:16 contrib/ 80 Sep 19 12:14 contrib/ ... aclocal.m4 is now the size of acinclude.m4+aclocal.m4 from before, which is reasonable, but configure is nearly twice as large (350kB bigger) as before. This is repeated in libltdl/ as well. I can reduce the tarball size by 20kB (to 594619) if I have libltdl/acinclude.m4 just be: m4_include([../aclocal.m4]) This reduces libltdl/aclocal.m4's size, but libltdl/configure is still 340kB larger than before 1.5.10. -- 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 release plans for the next few weeks
What is branch-1-5's current role? There have been patches checked in as of the 13th; will there be a 1.5.9 release? If so, can Ralf's patch (which corrects RH#55176) be applied to branch-1-5? I would like to pick the version of libtool to ship with our upcoming Fedora Core 3 release. Should I track CVS branch-1-5 and use a version number like libtool-1.5.8.0.200409171404, can I rely on there being a 1.5.9 release in the next few weeks, or should I track CVS 1.9? If I take no action, we are currently set to ship 1.5.6 with a number of patches--most of which have been applied or reproduced in branch-1-5 since 1.5.8. Thanks, -- Daniel Reed [EMAIL PROTECTED] http://people.redhat.com/djr/ Desktop and Cygwin ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool release plans for the next few weeks
On 2004-09-17T20:12+0100, Gary V. Vaughan wrote: ) Daniel Reed wrote: ) If so, can Ralf's patch (which corrects RH#55176) be applied to branch-1-5? ) If you point me at the thread in the mail archives, and it backports easily, ) I'll apply it. Bug report: http://lists.gnu.org/archive/html/bug-libtool/2004-09/msg00050.html Ralf's backported patch: http://lists.gnu.org/archive/html/bug-libtool/2004-09/msg00051.html Success report: http://lists.gnu.org/archive/html/bug-libtool/2004-09/msg00058.html ) I'll make a stable release from branch-1-5 (1.5.10 according to Release ) Numbering on http://www.gnu.org/software/libtool/contribute.html) if I can ) apply Ralf's patch... Great, thanks :) -- Daniel Reed [EMAIL PROTECTED] http://people.redhat.com/djr/ Desktop and Cygwin ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
On 2004-08-11T20:43-0400, Daniel Reed wrote: ) ) ) libtool-1.4.2-multilib.patch ) Would it be reasonable to make this a ./configure option at libtool build ) time? Actually, it wouldn't. :) The actual problem is that software packaged with stock Libtool does not build properly in our multilib build roots. Right now, we have to manually re-bootstrap several of our packages to use our modified libtool.m4. My goal is to allow us to stop doing that :) (I would like to be able to remove the autotools from our build roots altogether.) So, instead of a libtool-compile-time option, would it be reasonable to a) use an environment variable to set this behavior, or b) have Libtool add an option to libtoolized ./configure scripts, or something else? -- Daniel Reed [EMAIL PROTECTED] http://people.redhat.com/djr/ http://naim.n.ml.org/ There go my people. I must find out where they are going so I can lead them. -- Alexandre Ledru-Rollin ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
) On Fri, 13 Aug 2004, Ralf Corsepius wrote: ) However, you can not identify the multilib-variant and the multilib ) subdir being used from $host, because it is chosen depending upon the ) flags being passed to gcc: ) sparc-sun-solaris2.8-gcc .. - . (sparcv7) ) sparc-sun-solaris2.8-gcc -m64 .. - sparcv9 In the scheme we use, $host would be sparc64-sun-solaris2.8 . -- Daniel Reed [EMAIL PROTECTED] http://people.redhat.com/djr/ http://naim.n.ml.org/ The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
On 2004-08-11T10:06+0900, Peter O'Gorman wrote: ) Daniel Reed wrote: ) libtool-1.4.2-multilib.patch )This patch is needed for multilib support. It has been sent upstream )but basically rejected in its current form as being too Red Hat specific. ) [Is this still the case? Is there an alternate solution for this problem, or ) is .multilib still the only one?] ) Do you have a url for the thread? The original post is: http://lists.gnu.org/archive/html/libtool-patches/2004-02/msg00050.html Therefore I don't think we can accept this into Libtool in its current form. is: http://lists.gnu.org/archive/html/libtool-patches/2004-03/msg00033.html ) libtool-1.4.2-demo.patch (on x86_64 s390 s390x) )Yes, this is just to disable several nopic tests: afaicr nopic is )meaningless on those archs bicbw... ie a patch should really go upstream )to skip those tests on those archs I guess. ) Well, if you can be bothered to make a real patch, we might look at it. A ) patch that simply removes tests from the Makefile.am is not a good thing[tm] :). Would it be better to keep the test from running with an Automake conditional, or disable it in the test script itself? (I see tests being controlled both ways in Libtool.) tests/demo-nopic.test already skips itself if `config.guess` begins with hppa; should I just extend that check to skip x86_64 and s390? ) libtool-1.5-testfailure.patch )This was contributed by Owen: would probably be worth trying to )push it upstream - though I'm not entirely clear why/if it is needed. ) I can not understand the point of this one. Perhaps Owen can explain why it ) is needed. This was to address a warning generated by Automake. The affected files were being built to be included in both an ar library and a libtool library. demo/Makefile.am: 9: libhello_la_SOURCES = hello.c foo.c 125: libhell0_a_SOURCES = hello.c foo.c pdemo/Makefile.am: 9: libhello_la_SOURCES = longer_file_name_hello.c longer_file_name_foo.c longer_file_name_foo2.c 125: libhell0_a_SOURCES = longer_file_name_hello.c longer_file_name_foo.c Owen's patch duplicates hello.c to hell0.c and makes libhell0_a_SOURCES use that instead of hello.c, etc. The way I work around this in naim is to add an empty _CFLAGS for the libtool target (I believe this workaround was proposed on this list). Which would be more acceptable? Thanks for looking into this! -- Daniel Reed [EMAIL PROTECTED] http://people.redhat.com/djr/ http://naim.n.ml.org/ A man that is truly great is he who makes the world his debtor. ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
On 2004-08-12T00:30+0900, Peter O'Gorman wrote: ) ) libtool-1.4-nonneg.patch ) ) ) libtool-1.5-libtool.m4-x86_64.patch ) ) This too. ) Aw, with changelog entries and stuff :) The entry for libtool-1.4-nonneg.patch in the RPM changelog is: * Thu Jul 13 2000 Elliot Lee [EMAIL PROTECTED] - Fix recognition of ^0[0-9]+$ as a non-negative integer. libtool-1.5-libtool.m4-x86_64.patch, which was originally libtool-1.4.2-s390_x86_64.patch, does not have its own changelog entry. It adds the prefix x86_64 to the list of CPU types that have lt_cv_deplibs_check_method set to pass_all (libtool.m4:2212 in CVS). This may just be my inexperience with Libtool's code, but it appears that section is [now?] always setting lt_cv_deplibs_check_method to pass_all: | # This must be Linux ELF. | linux*) | case $host_cpu in | alpha*|hppa*|i*86|ia64*|m68*|mips*|powerpc*|sparc*|s390*|sh*) | lt_cv_deplibs_check_method=pass_all ;; | *) | # glibc up to 2.1.1 does not perform some relocations on ARM | # this will be overridden with pass_all, but let us keep it just in case | lt_cv_deplibs_check_method='file_magic ELF [[0-9]][[0-9]]*-bit [[LM]]SB (shared object|dynamic lib )' ;; | esac | lt_cv_file_magic_test_file=`echo /lib/libc.so* /lib/libc-*.so` | lt_cv_deplibs_check_method=pass_all | ;; If $host_os begins with linux, and if $host_cpu begins with ..., set lt_cv_deplibs_check_method to pass_all; otherwise, set lt_cv_deplibs_check_method to something else; and record the output of echo /lib/libc.so* /lib/libc-*.so; and set lt_cv_deplibs_check_method to pass_all. Is `echo /lib/libc.so* /lib/libc-*.so` affected by the value of lt_cv_deplibs_check_method, or can the internal case $host_cpu be removed entirely? -- Daniel Reed [EMAIL PROTECTED] http://people.redhat.com/djr/ Desktop and Cygwin ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
On 2004-08-12T09:00+0900, Peter O'Gorman wrote: ) Daniel Reed wrote: ) On 2004-08-11T10:06+0900, Peter O'Gorman wrote: ) ) Daniel Reed wrote: ) ) libtool-1.4.2-multilib.patch ) )This patch is needed for multilib support. It has been sent upstream ) )but basically rejected in its current form as being too Red Hat specific. ) ) [Is this still the case? Is there an alternate solution for this problem, or ) ) is .multilib still the only one?] ) Thanks for the url. I have to agree with Scott, looks like adding this patch ) here would be a bad thing, it may break other linux distros. Someone, ) someday, will come up with a generic way of doing this that works on all ) flavours of GNU/linux. They don't seem to have done so yet. Would it be reasonable to make this a ./configure option at libtool build time? Something like --enable-redhat-multilib or --with-multilib-flavor=RedHat ? Or even something like --with-multilibformat='lib64' versus --with-multilibformat='$host_os/lib' ? -- Daniel Reed [EMAIL PROTECTED] http://people.redhat.com/djr/ http://naim.n.ml.org/ True nobility lies not in being superior to another man, but in being superior to one's previous self. ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
(Hiya. I have recently become Red Hat's libtool package maintainer.) On 2004-08-11T00:32+0900, Peter O'Gorman wrote: ) Joe Orton wrote: ) It always disappoints me to do so too, that's why I'm making this plea ) :) The fact that libtool 1.5-based configure scripts fail on systems ) without a C++ compiler is a severe regression which outweighs all the ) great features and fixes since 1.4, unfortunately. ) I guess I must have seen this report at some point, but I don't remember ) having done so :( I have reported it at least twice, with several months in between. It had been reported numerous times by others and has been reported numerous times since :/ For my own projects, I patch the affected routines via acinclude.m4 to noop the C++ checks. The patch I use was originally posted here, probably over a year ago (it guts an M4 macro). However, I am hesitant to make such a change to Red Hat's shipped version of libtool. For one, the patch I am using disables C++ support entirely (my affected projects are just C). Most importantly, though, this is an actual [and serious] flaw in the autotools, and should be addressed in the upstream, canonical versions. On a related note, the libtool I inherited already has 5 patches applied to it. I would like to eventually ship a clean libtool, and would love to hear back on what the status of these patches are. From the previous maintainer: libtool-1.4-nonneg.patch Afaik this patch is not strictly necessary, but doesn't do any harm either. [it changes some shell script in libtool to detect non-negative numbers better] libtool-1.5-libtool.m4-x86_64.patch I guess this should go upstream if it is not in cvs stable branch already. It trivial but obviously needed to support hammer/ia32e. libtool-1.4.2-multilib.patch This patch is needed for multilib support. It has been sent upstream but basically rejected in its current form as being too Red Hat specific. [Is this still the case? Is there an alternate solution for this problem, or is .multilib still the only one?] libtool-1.4.2-demo.patch (on x86_64 s390 s390x) Yes, this is just to disable several nopic tests: afaicr nopic is meaningless on those archs bicbw... ie a patch should really go upstream to skip those tests on those archs I guess. libtool-1.5-testfailure.patch This was contributed by Owen: would probably be worth trying to push it upstream - though I'm not entirely clear why/if it is needed. I can post these to libtool-patches if the names are unfamiliar to anyone :) -- Daniel Reed [EMAIL PROTECTED] http://people.redhat.com/djr/ http://naim.n.ml.org/ Never be afraid to try something new. Remember: Amateurs built the ark. Professionals built the Titanic. ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.2 released
On 2004-01-29T10:36-, Scott James Remnant wrote: ) On Thu, 2004-01-29 at 01:35, Daniel Reed wrote: ) The problem I was reporting is not so much the testing for C++ as it was the ) failing of ./configure if a C++ preprocessor was not available. There is C ) code in the various examples directories, so failing for lack of a C ) compiler might at least be reasonable. ) That's actually an Autoconf macro that's failing, unfortunately. It's ) an irritant, but I've not figured out a way of getting around it short ) of overriding AC_MSG_ERROR. I believe I got this workaround from this list, but the problem goes away after changing the definition of _LT_AC_TAGCONFIG (in libtool.m4) from the several-page routine to just: AC_DEFUN([_LT_AC_TAGCONFIG],[]) I have been shipping my libtool-enabled software with this change (in acinclude.m4) and can happily report ./configure does successfully complete on machines without C++ compilers. A change like this to libtool proper's acinclude.m4 might allow me to install libtool on such machines without patching it first. -- Daniel Reed [EMAIL PROTECTED] http://naim-users.org/nmlorg/ http://naim.n.ml.org/ Never be afraid to try something new. Remember: Amateurs built the ark. Professionals built the Titanic. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.2 released
On 2004-01-25T14:47-, Scott James Remnant wrote: ) The Libtool Team is pleased to announce the release of GNU Libtool ) 1.5.2. Since there does not appear to be any C++ code (.cc, .cxx, .C) in libtool, would it be possible for the next release of libtool to not: checking whether ln -s works... yes checking for g++... no checking for c++... no checking for gpp... no checking for aCC... no checking for CC... no checking for cxx... no checking for cc++... no checking for cl... no checking for FCC... no checking for KCC... no checking for RCC... no checking for xlC_r... no checking for xlC... no checking whether we are using the GNU C++ compiler... no checking whether g++ accepts -g... no checking dependency style of g++... none checking for g77... no ... checking for dlfcn.h... yes checking how to run the C++ preprocessor... /lib/cpp configure: error: C++ preprocessor /lib/cpp fails sanity check See `config.log' for more details. [config.log] configure:5791: /lib/cpp conftest.cc cpp: conftest.cc: C++ compiler not installed on this system configure:5797: $? = 1 configure: failed program was: -- Daniel Reed [EMAIL PROTECTED] http://naim-users.org/nmlorg/ 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://mail.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.2 released
On 2004-01-28T15:59-, Scott James Remnant wrote: ) On Wed, 2004-01-28 at 15:15, Daniel Reed wrote: ) Since there does not appear to be any C++ code (.cc, .cxx, .C) in libtool, ) would it be possible for the next release of libtool to not: ) There isn't any C code either ... it checks for various compilers so it ) can provide support for them (ie. you can go libtool g++). The problem I was reporting is not so much the testing for C++ as it was the failing of ./configure if a C++ preprocessor was not available. There is C code in the various examples directories, so failing for lack of a C compiler might at least be reasonable. -- Daniel Reed [EMAIL PROTECTED] http://naim-users.org/nmlorg/ http://naim.n.ml.org/ A man that is truly great is he who makes the world his debtor. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Version numbering
On 2003-09-29T22:50+0200, Alexandre Duret-Lutz wrote: ) planning to make 2.2 2.3a 2.3. That would be counter ) intuitive. IMHO any numbering scheme ought to work with `ls -v'. ls ls -v ls -rt naim-0.11.5.1.tar.gz naim-0.11.5.1.tar.gz naim-0.11.5.tar.gz naim-0.11.5.7.tar.gz naim-0.11.5.7.tar.gz naim-0.11.5.1.tar.gz naim-0.11.5.8.1.tar.gz naim-0.11.5.8.1.tar.gz naim-0.11.5.7.tar.gz naim-0.11.5.8.tar.gz naim-0.11.5.8.tar.gz naim-0.11.5.8.tar.gz naim-0.11.5.9.cyg1.tar.gz naim-0.11.5.9.cyg1.tar.gz naim-0.11.5.8.1.tar.gz naim-0.11.5.9.cyg10.tar.gz naim-0.11.5.9.cyg9.tar.gz naim-0.11.5.9.tar.gz naim-0.11.5.9.cyg11.tar.gz naim-0.11.5.9.cyg10.tar.gz naim-0.11.5.9.cyg1.tar.gz naim-0.11.5.9.cyg9.tar.gz naim-0.11.5.9.cyg11.tar.gz naim-0.11.5.9.cyg9.tar.gz naim-0.11.5.9.tar.gz naim-0.11.5.9.tar.gz naim-0.11.5.9.cyg10.tar.gz naim-0.11.5.tar.gz naim-0.11.5.tar.gz naim-0.11.5.9.cyg11.tar.gz Several GNU projects (including GCC) do leave off .0's for anything past the minor number, so it seems ls -v can't be the final authority :/ What I do is timestamp pre-release snapshots, which does work with ls -v (and just ls). That is, I might have: naim-0.11.5-2002-12-08-1324.tar.gz naim-0.11.5.1-2002-12-18-0014.tar.gz naim-0.11.5.1-2002-12-21-1710.tar.gz naim-0.11.5.1.tar.gz naim-0.11.5.2-2002-12-23-0720.tar.gz ... naim-0.11.5.8-2003-06-03-1123.tar.gz naim-0.11.5.8.tar.gz naim-0.11.5.tar.gz 0.11.5.8-2003-06-03-1123 is the last pre-release before 0.11.5.8, and shows up before 0.11.5.8 in ls. The only problem is the lack of .0's that leave 0.11.5's pre-releases in the right spot, but sticks the 0.11.5 release after all of its subordinate releases. -- Daniel Reed [EMAIL PROTECTED] http://naim-users.org/nmlorg/ http://naim.n.ml.org/ There are people who do things and people who take the credit, and the trick is to be in the first group; there is a lot less competition. -- Dwight Morrow, American Diplomat http://site.n.ml.org/download/20030923195458/naim/naim-0.11.6.1.tar.bz2 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Building .so files only.
On 2003-08-29T14:14+1000, Tom Howard wrote: ) On Thursday 28 August 2003 16:08, Schleicher Ralph (LLI) wrote: ) So by patching my libtool I should be able to put the -shared flag in my ) AM_LDFLAGS for the Makefile.am and only get the shared.so file right? ) Yes, but it makes sense adding it to CFLAGS, too. ) Sorry if I'm being dense, but (after reading the referenced messages) I don't ) understand why using the -shared flag will only produce the a .so file. ) Won't it still produce a .so.X, .so.X.X.X and .la files as well? Or have I ) misunderstood the original question and Stephen is simply trying to prevent ) the .a file from being created? To produce only .la and .so files, you can pass -module -avoid-version to libtool. In Automake, you can do this by using something similar to: pkglib_LTLIBRARIES = mymod.la mymod_la_SOURCES = mymod.c mymod_la_LDFLAGS = -module -avoid-version This also removes the requirement that the library name start with lib. -- Daniel Reed [EMAIL PROTECTED] http://naim-users.org/nmlorg/ http://naim.n.ml.org/ I don't like sending my conversation hundreds of miles where a lot of people can read it o_0 even if I am just talking about cheese. -- Avatar214, re: encryption in naim http://site.n.ml.org/download/20030819120839/naim/naim-0.11.6.tar.gz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Request for option to disable building of static library
On 2003-07-22T22:02+0900, Peter O'Gorman wrote: ) On Tuesday, July 22, 2003, at 09:37 PM, Sander Niemeijer wrote: ) A few other libraries, however, are plug-ins (modules created with the ) '-module' flag) that only need to be delivered as shared libraries. ) Firstly, in case you were wondering why libtool builds static libraries ) even for loadable modules, libtool via. ltdl supports loading modules ) on systems without dynamic loading capabilities using the ) -dlopen/-dlpreopen flags. One use for modules could be to reduce executable size/memory footprint when unwanted features can be left unloaded, so in an environment where that's not possible, linking them in permanently is a fine alternative. However, if I were to distribute a core utility with module loading capabilities, then distribute extension/upgrade modules separately, the effort to build a static version for linking into the binary is a day late and a dollar short (the binary could be months or years old when the modules are compiled). It might make sense then for a -no-static option to not just switch it into shared-only mode, but to make it exclusively shared-only: Right now if I specify AC_DISABLE_STATIC, and libtool doesn't know how to build shared libraries, it goes ahead and builds static ones instead; I would prefer it emit an error. -- Daniel Reed [EMAIL PROTECTED] http://shell.n.ml.org/n/http://naim.n.ml.org/ It is a miracle that curiosity survives formal education. -- Albert Einstein, Physicist ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool 1.5 C++ issues, rehash
configure.in:
...
echo
echo
echo Configuring libtool
echo
AC_LIBLTDL_CONVENIENCE
AC_LIBTOOL_DLOPEN
AC_PROG_LIBTOOL
./configure:
...
Configuring libtool
checking for a sed that does not truncate output... /usr/bin/sed
checking for egrep... grep -E
checking for ld used by gcc... /bin/ld
checking if the linker (/bin/ld) is GNU ld... yes
checking for /bin/ld option to reload object files... -r
checking for BSD-compatible nm... /bin/nm -B
checking whether ln -s works... yes
checking how to recognise dependent libraries... pass_all
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for g++... no
checking for c++... no
checking for gpp... no
checking for aCC... no
checking for CC... no
checking for cxx... no
checking for cc++... no
checking for cl... no
checking for FCC... no
checking for KCC... no
checking for RCC... no
checking for xlC_r... no
checking for xlC... no
checking whether we are using the GNU C++ compiler... no
checking whether g++ accepts -g... no
checking dependency style of g++... none
checking how to run the C++ preprocessor... /lib/cpp
configure: error: C++ preprocessor /lib/cpp fails sanity check
See `config.log' for more details.
config.log:
configure:5177: /lib/cpp -I/software/linux/linux-2.4.20/dist/include
-I/software/ncurses/ncurses-5.3/dist/include conftest.cc
cpp: conftest.cc: C++ compiler not installed on this system
I do not have a C++ compiler on this system, so that error is that is
correct. However, my code is not written in C++, and I do not believe
anything in my configure.in should be adding in a dependency. Previous
versions of libtool's .m4 scripts did not add any checks for C++.
Looking through Google I seem to find references to this dated from April,
and discussion until early June, but no resolution. I just upgraded from
libtool-1.4.3 to libtool-1.5 today in order to get a working
AC_LIBTOOL_DLOPEN (the patches I found on Google didn't seem to work, and
I'd rather upgrade anyway). I have tried replacing the libtool.m4 and
ltdl.m4 files with the ones in ftp://alpha.gnu.org/gnu/cvs/libtool.tgz,
regenerated acinclude.m4 and aclocal.m4, same effect (the output above is
actually using the CVS .m4's). I've also tried setting CXX=no just before
calling AC_PROG_LIBTOOL, and the actual error persists (though the 15 search
lines for a C++ compiler disappear). In 1.4.3, ./configure never attempted
to do anything with C++ using the same configure.in, and unfortunately I
don't know m4 well enough to figure out what's causing the improper
dependency.
Original ./configure (from 1.4.3):
...
Configuring libtool
checking for ld used by GCC... /bin/ld
checking if the linker (/bin/ld) is GNU ld... yes
checking for /bin/ld option to reload object files... -r
checking for BSD-compatible nm... /bin/nm -B
checking for a sed that does not truncate output... /usr/bin/sed
checking whether ln -s works... yes
checking how to recognise dependent libraries... pass_all
checking command to parse /bin/nm -B output... ok
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for ranlib... ranlib
checking for strip... strip
checking for objdir... .libs
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.lo... yes
checking if gcc supports -fno-rtti -fno-exceptions... no
checking whether the linker (/bin/ld) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking whether -lc should be explicitly linked in... no
creating libtool
Does anyone have a {libtool.m4,ltdl.m4} pair that has a working
AC_LIBTOOL_DLOPEN and does not introduce the C++ dependency?
--
Daniel Reed [EMAIL PROTECTED] http://shell.n.ml.org/n/
It is a miracle that curiosity survives formal education -- Albert
