[sr #110674] Option --with-pic is a misnomer

Follow-up Comment #1, sr#110674 (group libtool): i don't know that we would ever really drop the option. since libtool is included in source distros, old versions that have --with-pic & not --enable-pic will stick around basically forever. ___

[sr #102300] libtool confused by depcomp

Update of sr#102300 (group libtool): Status:None => Need Info ___ Follow-up Comment #1: sorry, but i'm not quite following the issue here. can you include a full command line & error mes

[sr #110925] libtool 2.4.7.4-1ec8f-dirty infinite loop on unknown (out of order) argument

Follow-up Comment #1, sr#110925 (group libtool): please show an example command that fails, and ideally include a patch showing what change you want to make i tried to quickly reproduce this locally based on your description, but it works fine for me

[sr #100875] libtool and amanda-2.4.3b3

Update of sr#100875 (group libtool): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #2: seems like this might

[sr #100410] clean mode wants to remove unknown files

Update of sr#100410 (group libtool): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #1: i think current libtoo

[sr #109183] Problem on compiling on git-bash/mingw using libtool coming with mpfr3.1.5

Update of sr#109183 (group libtool): Status:None => Need Info ___ Follow-up Comment #1: if this is still an issue with current mpfr releases, please attach the generated "libtool" script

[sr #111011] restore shared library support on Android

Follow-up Comment #1, sr#111011 (group libtool): this report lacks detailed (or really, any) information. the git commit lacks detailed information, and the author e-mail is set to nonsense. ___ Reply to this item at:

Re: Introducing a new maintainer of libtool

On 18 Jan 2024 11:25, Ozkan Sezer wrote: > On 1/18/24, Mike Frysinger wrote: > > On 17 Jan 2024 20:07, Ozkan Sezer wrote: > [...] > >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52253 > > > > doesn't look like a regression. it can wait. > > It&#x

Re: Introducing a new maintainer of libtool

On 17 Jan 2024 18:43, Mike Frysinger wrote: > On 17 Jan 2024 16:09, Ileana Dumitrescu wrote: > > I'll need some time figuring out the release process, but otherwise I > > should be able to get an alpha release out soon. Mike has been helpful > > and has merged in many

Re: Introducing a new maintainer of libtool

On 17 Jan 2024 16:09, Ileana Dumitrescu wrote: > I'll need some time figuring out the release process, but otherwise I > should be able to get an alpha release out soon. Mike has been helpful > and has merged in many patches over the past few days. there doesn't seem to be libtool-specific relea

Re: Introducing a new maintainer of libtool

On 17 Jan 2024 20:07, Ozkan Sezer wrote: > Please remember to check with debbugs.gnu.org: > https://debbugs.gnu.org/cgi/pkgreport.cgi?package=libtool;max-bugs=100;base-order=1;bug-rev=1 > > There are plenty of bugs in there. E.g.: we're always going to have a bug backlog. if there's something sp

[sr #110525] Typos caught by codespell

Follow-up Comment #3, sr#110525 (group libtool): feel free to send a patch to libtool-patches@ for it ___ Reply to this item at: ___ Message sent vi

Re: Introducing a new maintainer of libtool

On 17 Jan 2024 15:56, Simon Josefsson wrote: > Looking at that, it seems the bootstrap and bootstrap.conf scripts are > really old. seems like they're up-to-date to me. it's using the fork: https://github.com/gnulib-modules/bootstrap > Do we have any GitLab CI/CD testing for libtool? there is n

[sr #107584] Fails to detect the global symbol pipe

Update of sr#107584 (group libtool): Status:None => Need Info ___ Reply to this item at: ___ Mes

[sr #110261] _LT_CMD_OLD_ARCHIVE should not inline AC_PROG_RANLIB

Follow-up Comment #1, sr#110261 (group libtool): LT_INIT already does AC_PREREQ(2.62), so relying on AC_PROG_RANLIB sounds fine want to send a patch to the mailing list ? ___ Reply to this item at:

[sr #111002] regression in libtool 2.4.7: build error in ncurses

Update of sr#111002 (group libtool): Status:None => Need Info ___ Follow-up Comment #1: are you using patched libtool in your system ? ncurses-6.4 builds fine for me with libtool-2.4.7.

[sr #110947] flang: error: unknown argument: '-soname'

Update of sr#110947 (group libtool): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #4: this is handled via ht

[sr #108559] libtool binary wrappers fall prey to aggressive optimizations

Update of sr#108559 (group libtool): Open/Closed:Open => Closed ___ Reply to this item at: ___ Mes

[sr #108558] libtool nm test does not really work for W32 versions of nm

Update of sr#108558 (group libtool): Open/Closed:Open => Closed ___ Reply to this item at: ___ Mes

[sr #107959] Libtool generates invalid .def files

Update of sr#107959 (group libtool): Open/Closed:Open => Closed ___ Reply to this item at: ___ Mes

[sr #107584] Fails to detect the global symbol pipe

Follow-up Comment #1, sr#107584 (group libtool): please attach a patch showing what you mean ___ Reply to this item at: ___ Message sent via Savanna

[sr #102915] Compilation errors with gcc -mno-cygwin

Update of sr#102915 (group libtool): Status:None => Invalid Open/Closed:Open => Closed ___ Follow-up Comment #2: i don't know what "pls

[sr #102833] doc

Update of sr#102833 (group libtool): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #1: i don't think there's

[sr #108987] libtool doesn't like simple RM defined (without options)

Follow-up Comment #4, sr#108987 (group libtool): bootstrap & build-aux/funclib.sh are not maintained in libtool. you'll want to send those fixes upstream. https://github.com/gnulib-modules/bootstrap ___ Reply to this item at:

[sr #110796] libtool-2.4.7/build-aux/git-version-gen uses kind of a hack

Update of sr#110796 (group libtool): Status:None => Wont Do Open/Closed:Open => Closed ___ Follow-up Comment #1: build-aux/git-version-

[sr #110525] Typos caught by codespell

Update of sr#110525 (group libtool): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #1: should be fixed in lat

[sr #110870] Typos in libtool.texi and libtool.m4

Update of sr#110870 (group libtool): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #1: should be fixed in lat

[sr #110962] pass_all for z/OS

Update of sr#110962 (group libtool): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #1: you posted the patch t

Re: Introducing a new maintainer of libtool

On 13 Jan 2024 14:49, Ileana Dumitrescu wrote: > My short term plans are to review the numerous mailing list patches and > get them merged in. This will be an easy and productive first step for > me and libtool. I will also look at the various distro patches and see > if any of them are fit to b

[sr #110978] libtool.m4: Not respecting $LD when checking for --whole-archive

Update of sr#110978 (group libtool): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #1: merged now, thanks htt

[sr #110936] libtool webpage update

Update of sr#110936 (group libtool): Status:None => Done Assigned to:None => vapier Open/Closed:Open => Closed _

Re: [PATCH] libtool: Use AC_CHECK_PROG instead of AC_CHECK_TOOL to find "find"

lgtm -mike signature.asc Description: PGP signature

Re: bug#67539: GNU Automake 1.16.5 FAILS one test objc-megademo

On 30 Nov 2023 22:45, Nick Bowler wrote: > Interestingly the libtool manual also says "If [libtool] can't infer a > tag, then it defaults to the configuration for the C language", which is > clearly not the case (it seems what actually happens is that if libtool > can't infer a tag then it exits

Re: libtool using AC_CHECK_TOOL to find file

On 25 Oct 2023 20:24, Uwe Kleine-König wrote: > while cross-building a package I noticed a warning emitted by configure: > > ... > checking for arm-v7a-linux-gnueabihf-file... no > checking for file... file > configure: WARNING: using cross tools not prefixed with host trip

Re: .gitmodules security

On 07 Feb 2022 12:24, Vincent Lefevre wrote: > On 2022-02-07 05:43:11 -0500, Mike Frysinger wrote: > > On 07 Feb 2022 09:32, Vincent Lefevre wrote: > > > what is done on Debian (where the libtool uses the version from the > > > gnulib package, so that it is interestin

Re: .gitmodules security

On 07 Feb 2022 09:32, Vincent Lefevre wrote: > what is done on Debian (where the libtool uses the version from the > gnulib package, so that it is interesting to know the behavior with > the current gnulib). eh ? packages that leverage gnulib don't get libtool from gnulib. they get it from libto

Re: .gitmodules security

On 07 Feb 2022 00:19, Vincent Lefevre wrote: > On 2022-02-06 16:43:47 -0500, Mike Frysinger wrote: > > it requires more than a MITM to be successful. you'd also have to > > come up with a sha1 collision which is non-trivial for most people. > > not out of the reach of

Re: .gitmodules security

On 06 Feb 2022 14:59, Alex Ameen wrote: > Hey, I can't claim to be an expert about this category of vulnerability; > but I appreciate you raising this concern. it requires more than a MITM to be successful. you'd also have to come up with a sha1 collision which is non-trivial for most people. n

Re: new release?

On 06 Feb 2022 11:56, Daniel Herring wrote: > FWIW, libtool is a particularly difficult code base to release. Long > history, many users, multi-platform, ... > > I would personally recommend the "slow" process unless you are confident > this release will "do no harm". It was made for a reason,

Re: new release?

On 05 Feb 2022 15:15, Alex Ameen wrote: > This is a good question. I plan on making a new release this month. > > When I first adopted the project I ambitiously thought I'd manage to > create a new release after about a month; but the truth is when I > started doing a deep dive into the internal

Re: Libtool and .s file

On 05 Apr 2021 09:35, Benoit Gschwind wrote: > Thank you for the highlight. > > Is .incbin considedred as preprocessor instruction ? if you're using assembler directives like .incbin, that isn't preprocessing, so .s is OK. usually when people say -I from CFLAGS/CXXFLAGS, they want the preprocess

Re: Libtool and .s file

On 02 Apr 2021 12:54, Benoit Gschwind wrote: > I trying to build a project that include assembler file ".s". > > Libtool seems to work with them and call gcc as follow: > > /bin/sh ../libtool--mode=compile gcc -Og -ggdb -march=native -c -o > myfile.lo ../../src/myfile.s > > But it does not

Re: Colons not escaped for setting LD_LIBRARY_PATH.

On 05 Feb 2018 11:10, Mike Frysinger wrote: > On 05 Feb 2018 10:30, Philipp Thomas wrote: > > * Russ Allbery (ea...@eyrie.org) [20180203 02:57]: > > > > > I believe directory names including colons are simply not supported for > > > LD_LIBRARY_PATH (and v

Re: Colons not escaped for setting LD_LIBRARY_PATH.

On 05 Feb 2018 10:30, Philipp Thomas wrote: > * Russ Allbery (ea...@eyrie.org) [20180203 02:57]: > > > I believe directory names including colons are simply not supported for > > LD_LIBRARY_PATH (and various other things, such as PATH). > > No no no, you get me wrong! What I meant is that colons

Re: How can I keep -lstdc++ out of $postdeps?

On 23 Feb 2017 12:22, Jack Bates wrote: > On 23/02/17 12:04 PM, Mike Frysinger wrote: > > On 23 Feb 2017 09:01, Jack Bates wrote: > >> On 22/02/17 12:16 PM, Mike Frysinger wrote: > >>> On 22 Feb 2017 10:32, Jack Bates wrote: > >>>> How can I avoid dynam

Re: How can I keep -lstdc++ out of $postdeps?

On 23 Feb 2017 09:01, Jack Bates wrote: > On 22/02/17 12:16 PM, Mike Frysinger wrote: > > On 22 Feb 2017 10:32, Jack Bates wrote: > >> How can I avoid dynamically linking with libstdc++? > >> or, how can I keep -lstdc++ out of $postdeps? > > > > let's ba

Re: How can I keep -lstdc++ out of $postdeps?

On 22 Feb 2017 10:32, Jack Bates wrote: > How can I avoid dynamically linking with libstdc++? > or, how can I keep -lstdc++ out of $postdeps? let's back up. what is it you're actually trying to do ? you want to create a statically linked C++ program ? you want to link a C program ? something else

Re: Broken Link

On 18 Jun 2016 00:03, Gummadi, Pranathi wrote: > Your links to any of the libtool 2.2.6 files are broken on the following > website: > > https://www.gnu.org/software/libtool/news.html > > I would like access to them, can they be fixed? just guess the URL base and browse for the files you want:

Re: [PATCH] Fix typo of non-existing function name

lgtm. hopefully a committer will wake up to merge it :). -mike signature.asc Description: Digital signature ___ https://lists.gnu.org/mailman/listinfo/libtool

Re: How to build libtool from git sources properly?

On 18 May 2016 11:15, Igor Zhbanov wrote: > How to properly build libtool from git sources. > > I see too many differences between > > git clone git://git.savannah.gnu.org/libtool.git > git checkout v2.4.6 > > and > > http://ftpmirror.gnu.org/libtool/libtool-2.4.6.tar.gz. > > How to make clone

Re: Why is this library not found?

On 01 May 2016 09:18, Robert Boehne wrote: > Run it under gdb and see why it doesn't find the library. or use strace -- that'll show quickly all the files/paths that the program is trying to use -mike signature.asc Description: Digital signature ___ ht

Re: Mailing Lists

On 12 Feb 2016 15:17, martin wrote: > Please unsubscribe. > > ___ > https://lists.gnu.org/mailman/listinfo/libtool use the link at the bottom of every e-mail to manage your subscription -mike signature.asc Description: Digital signature __

Re: Libtool does not generate shared libraries when cross compiling x86/64 -> sparc64 using fujitsu compiler

On 03 Feb 2016 14:30, Harald Servat wrote: >we have found that > > ./configure --prefix=/tmp/test CC=fccpx --build=x86_64-linux-gnu > --host=sparc64-linux-gnu > >did not work. See: > > ... > checking whether the fccpx linker (/usr/bin/ld -m elf64_sparc) supports > shared libraries...

Re: Libtool does not generate shared libraries when cross compiling x86/64 -> sparc64 using fujitsu compiler

On 02 Feb 2016 17:51, Harald Servat wrote: >we want to use libtool on a system on which we have to cross-compile > from intel x86/64 to sparc/64 using the Fujitsu compiler (fccpx). > Unfortunately, I'm unable to get libtool (version 2.4.2) to generate > shared libraries. > >I have writt

Re: Bash-specific performance by avoiding sed

On 09 Mar 2015 14:48, Eric Blake wrote: > On 03/09/2015 01:50 PM, Bob Friesenhahn wrote: > > On Mon, 9 Mar 2015, Mike Gran wrote: > >> I don't know if y'all saw this blogpost where a guy pushed > >> the sed regular expression handling into bash-specific > >> regular expressions when bash was availa

Re: libtool problem with --whole-archive/--no-whole-archive

On 26 Nov 2014 11:20, Venkatesh Vivekanandan wrote: > Problem is, platform linker command doesn't have > --whole-archive/--no-whole-archive around the lib. Instead it comes later > in the command line. iirc, libtool likes to sort things for you > How to propogate the --whole-archive/--no-whole-ar

Re: GNU Libtool-2.4.3 released [stable]

On 30 Oct 2014 14:06, Pavel Raiskup wrote: > On Monday 27 of October 2014 21:44:02 Gary V. Vaughan wrote: > > - Fix a long-standing bug when using libtoolize without automake; we > >no longer remove install-sh with --force, since it's not a file > >libtoolize will reinstall without --insta

Re: [RFC] any critical patches for a release this weekend?

this would be nice: http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=5f7f7d9615bf650cf99d581a33b3e18357f79951 -mike signature.asc Description: Digital signature ___ https://lists.gnu.org/mailman/listinfo/libtool

Re: no .pc file

On Friday 26 October 2012 14:27:32 Bob Friesenhahn wrote: > On Fri, 26 Oct 2012, Yaroslav Bulatov wrote: > > Oops my badthat was a bad paste from some auto-generated code. > > > > This is basically a modified version of .pc file I get when building > > zlib. Not sure how useful this is because

Re: no .pc file

On Friday 26 October 2012 16:26:29 Yaroslav Bulatov wrote: please don't top post > Sorry for confusing terminology, I actually needed pc file for libltdl > not libtool The .pc file above seems to have solved my problem the proposed .pc file is incorrect for libltdl. you need to specify -lltdl i

Re: no .pc file

On Friday 26 October 2012 01:05:10 Yaroslav Bulatov wrote: > I see. I needed it because a package management system was using > pkg-config to check if libtool was available, and refusing to proceed > because .pc file was missing. your package management system sounds broken. providing .pc files f

Re: Shared library versioning

On Tue, Jun 14, 2011 at 12:26, Lasse Collin wrote: > On 2011-06-14 Bob Friesenhahn wrote: >> On Tue, 14 Jun 2011, Lasse Collin wrote: >> > Please read the section "Understanding shared libraries >> > number rules" (it's short): >> > >> >    http://www.openbsd.org/faq/ports/specialtopics.html >> >>

Re: Shared library versioning

On Friday, June 10, 2011 14:47:49 Lasse Collin wrote: > I recently made a bug report that Libtool does shared library > versioning wrong on *BSDs: > > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8765 > > After that bug report I have got a feeling that Libtool may have > comparable bugs on a

Re: libtool won't link with static libraries

On Wednesday, April 27, 2011 22:49:11 Adam Nielsen wrote: > I'm trying to cross-compile a library under Linux to produce a Win32 .dll. > It needs to link in with static Boost libraries (which were also cross > compiled on the same machine) but libtool seems to refuse to do this: > > *** Warning:

Re: Problem with --as-needed flag

On Tuesday, November 23, 2010 08:04:45 Sergio Belkin wrote: > You can take a look the Makefile.am on: > > http://pastebin.com/jn4kiqTd please do not use pastebin type sites with mailing lists. post all your info into the e-mail itself. -mike signature.asc Description: This is a digitally sign

Re: How does libtool decide which so to link against?

On Mon, Oct 25, 2010 at 4:12 PM, Giles Anderson wrote: > I have upgraded Boost and find that I have to re-link my own executables. > Should I have to? I dont really want to. complain to the boost developers for not being ABI compatible (same SONAME). or manually keep the old SONAME on your system

Re: Blackfin and version scripts

On Tuesday, July 06, 2010 13:08:26 Mike Frysinger wrote: > On Tuesday, July 06, 2010 12:34:13 Kurt Roeckx wrote: > > But my point is that a version script is nothing arch specific, > > unlike a linker script. Version scripts even support saying in > > which language the symb

Re: Blackfin and version scripts

On Tuesday, July 06, 2010 12:34:13 Kurt Roeckx wrote: > On Mon, Jul 05, 2010 at 04:08:47PM -0400, Mike Frysinger wrote: > > On Mon, Jul 5, 2010 at 12:50, Kurt Roeckx wrote: > > > On Mon, Jul 05, 2010 at 03:43:21AM -0400, Mike Frysinger wrote: > > >> On Saturday, July

Re: Blackfin and version scripts

On Mon, Jul 5, 2010 at 12:50, Kurt Roeckx wrote: > On Mon, Jul 05, 2010 at 03:43:21AM -0400, Mike Frysinger wrote: >> On Saturday, July 03, 2010 05:48:13 Kurt Roeckx wrote: >> > On Tue, Jun 22, 2010 at 11:42:43AM +0200, Werner Koch wrote: >> > >

Re: Blackfin and version scripts

On Saturday, July 03, 2010 05:48:13 Kurt Roeckx wrote: > On Tue, Jun 22, 2010 at 11:42:43AM +0200, Werner Koch wrote: > > Hi! > > > > GCRYPT_1.2 { > > > > global: > > gcry_check_version; gcry_control; > > > > [...] > > > > Blackfin seems to be the only platform which has versi

Re: Blackfin and version scripts

On Wednesday, June 23, 2010 01:08:31 Ralf Wildenhues wrote: > * Russ Allbery wrote on Tue, Jun 22, 2010 at 11:00:04PM CEST: > > I would dearly, dearly love for libtool to pick up a --version-script > > option that would pass in the full version script on platforms with > > linkers that understand i

Re: why relink on successive "make install"?

On Tuesday 15 December 2009 15:52:39 Bob Friesenhahn wrote: > On Tue, 15 Dec 2009, Tom Vaughan wrote: > > I have a pretty vanilla shared library on the latest Ubuntu Karmic > > Koala that is built with autoconf, automake, and libtool. I've noticed > > that if I "make install" I always see "libtool:

Re: rpath

On Tuesday 08 December 2009 03:44:57 Joakim Tjernlund wrote: > rpath gets set to /usr/local/lib but this is wrong for me. > I am crosscompiling and point builddir to /some/dir and install > into /some/dir/opt/x/y so I want rpath to point to /opt/x/y > What controls rpath in libtool? what did you s

Re: -fpic support in libtool?

On Wednesday 02 December 2009 21:27:55 Bob Friesenhahn wrote: > On Thu, 3 Dec 2009, Joakim Tjernlund wrote: > > Several years ago I asked libtool to support -fpic too but > > I don't see it in never libtool(s). I guess it isn't > > impl.? > > > > The simplest fix for adding -fpic I can come up with

Re: Avoid installing .la files with libtool

On Thursday 08 October 2009 12:11:41 Ali Abdallah wrote: > I'm using libtool 2.2.6a, and i want to avoid installing the .la files, > however i spend a lot of time trying to figure out how but i couldn't > manage, please help. there is no hook for it. you'd have to add an automake post hook to rm

Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem

On Tuesday 01 September 2009 12:33:09 Kurt Roeckx wrote: > On Mon, Aug 31, 2009 at 04:38:04PM -0400, Mike Frysinger wrote: > > On Monday 31 August 2009 15:56:06 Kurt Roeckx wrote: > > > On Mon, Aug 31, 2009 at 08:55:21PM +0200, Ralf Wildenhues wrote: > > > > * Ku

Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem

On Monday 31 August 2009 15:56:06 Kurt Roeckx wrote: > On Mon, Aug 31, 2009 at 08:55:21PM +0200, Ralf Wildenhues wrote: > > * Kurt Roeckx wrote on Sun, Aug 30, 2009 at 10:31:39PM CEST: > > > I've mailed about this issue before. What I think needs to > > > happen, and have proposed before, is: > >

Re: segfault on library linking

On Thursday 27 August 2009 21:33:02 Adam Mercer wrote: > Recently I've started seeing messages of the following form when > linking my library on Mac OS X: > > ../../../libtool: line 7824: 39012 Segmentation fault dsymutil > .libs/liblalmetaio.0.dylib > > although it appears that the library i

Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem

On Wednesday 26 August 2009 16:30:06 Ralf Wildenhues wrote: > * Russ Allbery wrote on Wed, Aug 26, 2009 at 07:35:53AM CEST: > > dlopened modules are something of a special case; it's one of the places > > where Debian may not remove *.la files depending on the specific > > situation. > > I have a q

Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem

On Tuesday 25 August 2009 20:33:25 Anssi Hannula wrote: > Mike Frysinger wrote: > > On Tuesday 25 August 2009 18:37:54 Richard Purdie wrote: > >> On Tue, 2009-08-25 at 20:44 +0200, Ralf Wildenhues wrote: > >>> * Bob Friesenhahn wrote on Tue, Aug 25, 2009 at 05:17:49

Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem

On Tuesday 25 August 2009 18:37:54 Richard Purdie wrote: > On Tue, 2009-08-25 at 20:44 +0200, Ralf Wildenhues wrote: > > * Bob Friesenhahn wrote on Tue, Aug 25, 2009 at 05:17:49PM CEST: > > > On Tue, 25 Aug 2009, Anssi Hannula wrote: > > > >I think the proper way to solve this is to not link to dep

Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem

On Tuesday 25 August 2009 18:41:52 Russ Allbery wrote: > Bob Friesenhahn writes: > > How would you like to deal with the case where a library has multiple > > usable dependencies, which satisify identical purposes, but via > > different possible libraries? > > > > libfoo-s

Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem

On Tuesday 25 August 2009 17:52:07 Bob Friesenhahn wrote: > On Tue, 25 Aug 2009, Russ Allbery wrote: > >> Relying on the OS's implicit dependency features seems to be an approach > >> which is fraught with peril. > > > > Relying on the dynamic linker to resolve implicit dependencies is the > > only

Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem

On Tuesday 25 August 2009 13:50:18 dherr...@tentpost.com wrote: > Mike wrote: > > On Tuesday 25 August 2009 12:42:19 Bob Friesenhahn wrote: > >> On Tue, 25 Aug 2009, Mike Frysinger wrote: > >> >> Relying on the OS's implicit dependency features seems to be an

Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem

On Tuesday 25 August 2009 12:42:19 Bob Friesenhahn wrote: > On Tue, 25 Aug 2009, Mike Frysinger wrote: > >> Relying on the OS's implicit dependency features seems to be an > >> approach which is fraught with peril. > > > > why ? > > When viewin

Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem

On Tuesday 25 August 2009 11:17:49 Bob Friesenhahn wrote: > On Tue, 25 Aug 2009, Anssi Hannula wrote: > > I think the proper way to solve this is to not link to dependency_libs > > when linking dynamically on systems where it is not needed to link to > > those. I haven't seen any correctly working

Re: -no-undefined support for GNU/Linux

On Wednesday 18 March 2009 17:06:28 Ralf Wildenhues wrote: > * Mike Frysinger wrote on Wed, Mar 18, 2009 at 09:27:42AM CET: > > but a patch would be needed first ... there's the previous one in the > > archives that was ported to libtool-1.5 ... > > Do you have a URL

Re: -no-undefined support for GNU/Linux

On Wednesday 18 March 2009 03:00:07 Ralf Wildenhues wrote: > * Mike Frysinger wrote on Wed, Mar 18, 2009 at 06:22:18AM CET: > > in a project for a LD_PRELOAD module, i like to use -no-undefined because > > undefined symbols will not work in it at all. i would like to see a link >

-no-undefined support for GNU/Linux

in a project for a LD_PRELOAD module, i like to use -no-undefined because undefined symbols will not work in it at all. i would like to see a link error up front rather than random runtime failures. googling around shows patches from 6-8 years ago. they refer to an older glibc bug (which at t

Re: programs depending on staged libraries depending on staged libraries

On Friday 13 February 2009 06:46:49 Dennis van Dok wrote: > I'm breaking my head over a problem that others must also have found, > chewed on and spit out. I found plenty of messages related to my > problem, such as the chroot discussion, but I just can't find the > definitive answer anywhere. if

Re: How to instruct libtool to link .so files instead of .la files?

On Wednesday 04 February 2009 10:33:56 samrat kannikar wrote: > i have an issue with libtool 2.2.6. Some of the devel packages im using > were providing .la files for linking. Now .la files have been removed and > im forced to use .so files instead. Is there any way to force libtool to > use .so na

Re: Installed libs wrongly used on 64-bit Linux?

On Thursday 22 January 2009 16:52:51 Bob Friesenhahn wrote: > On Thu, 22 Jan 2009, Mike Frysinger wrote: > > Gentoo uses a "build root" in the same sense. all packages are compiled > > and then installed into a temporary root before being merged to the > > actual f

Re: Installed libs wrongly used on 64-bit Linux?

On Thursday 22 January 2009 15:13:37 Bob Friesenhahn wrote: > On Thu, 22 Jan 2009, Tim Mooney wrote: > > In my case, I'm 100% certain that the problem relates to the fact that > > I'm using a build root while packaging the software (RPM). Are both of > > your users doing the same? > > One user (th

Re: Cannot link correct libltdl.so. Is it a bug?

first off, dont spam every e-mail address you can find. On Thursday 08 January 2009 17:50:20 Gary Yang wrote: > ./configure runs successfully with the following warnings the warnings are from a deficiency in your setup, not bugs in autotools. you need to provide cross-compiler prefixed scripts.

Re: don't let libtool infer the tag

On Monday 14 April 2008, Ralf Wildenhues wrote: > * Mike Frysinger wrote on Mon, Apr 14, 2008 at 01:41:32AM CEST: > > On Sunday 13 April 2008, Ralf Wildenhues wrote: > > > So don't do this, please. Supply --tag=CC if your compiler name > > > doesn't match. >

Re: sysroot support in libtool

On Sunday 13 April 2008, Ralf Wildenhues wrote: > * Richard Purdie wrote on Sun, Apr 13, 2008 at 08:53:10PM CEST: > > The patches we're using are publicly available as: > > http://svn.o-hand.com/view/poky/trunk/meta/packages/libtool/libtool-1.5.1 > >0/ > > uclibc.patch - Tweaks to libtool.m4 to sup

Re: sysroot support in libtool

On Sunday 13 April 2008, Gary V. Vaughan wrote: > On 13 Apr 2008, at 07:55, Richard Purdie wrote: > > [1] Are there any plans to support sysroots with libtool? > > No one is sending us bug reports or patches... so we don't even know > there is a problem! that's not true ... there have been people

Re: don't let libtool infer the tag (was: sysroot support in libtool)

On Sunday 13 April 2008, Ralf Wildenhues wrote: > * Ralf Wildenhues wrote on Sun, Apr 13, 2008 at 10:26:11PM CEST: > > * Richard Purdie wrote on Sun, Apr 13, 2008 at 08:53:10PM CEST: > > > tag.patch - The tag errors were breaking things for no good reason so > > > we turned the error into a warning

Re: problem with libtool generated version script and underscores

libtool automatically discovers the prefix in _LT_CMD_GLOBAL_SYMBOLS and stores the result into ac_symprfx (in libtool.m4). i think all we need to do is have _LT_LINKER_SHLIBS declare an m4_require on _LT_CMD_GLOBAL_SYMBOLS and then we can use ac_symprfx in archive_expsym_cmds by adding an expr

[patch/rfc] setting version type based on vendor

i dont know if there's a policy on this, but we've been treating the shared libraries in the Gentoo/FreeBSD port like Linux shared libraries. we control this based upon the vendor field in the toolchain tuple. -mike signature.asc Description: This is a digitally signed message part. 2008-02-16

  1   2   >