a build issue came up in Gentoo when people attempted to upgrade from
file-4.12 to file-4.15. the issue was tracked back to users having
LD_LIBRARY_PATH set in their env and was causing the wrong library to be
loaded. this e-mail isnt about whether users should be screwing around with
On Wednesday 14 September 2005 11:36 pm, Albert Chin wrote:
On Wed, Sep 14, 2005 at 08:32:12PM -0400, Mike Frysinger wrote:
normally this is no problem for libtool ... it installs a wrapper in
src/file which runs src/.libs/lt-file which is compiled with RUNPATH tags
so that the libmagic.so
On Thursday 15 September 2005 12:59 pm, Albert Chin wrote:
On Wed, Sep 14, 2005 at 11:50:05PM -0400, Mike Frysinger wrote:
On Wednesday 14 September 2005 11:36 pm, Albert Chin wrote:
If gcc/ld was used to build the new 'file' program, they would
have the same error as that generated
On Friday 23 September 2005 11:49 am, Brian wrote:
http://cvs.freedesktop.org/gstreamer/common/m4/as-libtool-tags.m4?rev=1.2v
iew=markup
http://cvs.freedesktop.org/gstreamer/gstreamer/configure.ac?r1=1.373r2=1.3
74
i wish that libtool tag patch was added to the official libtool package :/
the
On Friday 23 September 2005 06:50 pm, Peter O'Gorman wrote:
Mike Frysinger wrote:
| the CXX check is especially annoying ... if you have a host which only
| has a C
| compiler and you try to build a library which is pure C, configure will
| abort because it cant find a C++ compiler even
On Wednesday 28 September 2005 07:56 am, Jan Engelhardt wrote:
Shared libraries, however, may only be built from
position-independent code (PIC). So, special flags must be passed to
the compiler to tell it to generate PIC rather than the standard
position-dependent code. [libtool.info.gz]
On Wed, Nov 16, 2005 at 11:53:24AM -0800, Ross Boylan wrote:
On Wed, 2005-11-16 at 19:10 +, Mike Frysinger wrote:
On Wed, Nov 16, 2005 at 10:47:20AM -0800, Ross Boylan wrote:
after this line in the makefile output:
./libtool --mode=link g++-3.3 -o test1 -g AbstractTimeStepsGenerator.o
On Wed, Nov 16, 2005 at 12:50:58PM -0800, Ross Boylan wrote:
Does libtoolize have its own info files? So far, all I've seen is the
relatively brief description of the man page and libtool's info pages.
nope ... it does have its own subsection in the libtool info files though
-mike
On Sat, Nov 26, 2005 at 06:17:10AM +, Paul Jakma wrote:
Problem 2:
I tried to upgrade to a 1.5.18 in order to see if Problem 1 had been
addressed at all (i had been using 1.5.6 i think - perhaps with some
m4 files from CVS circa 2004 which dont have this problem). However,
I found
On Sat, Nov 26, 2005 at 02:16:18PM -0500, Daniel Reed wrote:
On Sat, 26 Nov 2005, Mike Frysinger wrote:
On Sat, Nov 26, 2005 at 06:17:10AM +, Paul Jakma wrote:
I tried to upgrade to a 1.5.18 in order to see if Problem 1 had been
addressed at all (i had been using 1.5.6 i think - perhaps
On Sat, Nov 26, 2005 at 12:06:40PM -0800, Howard Chu wrote:
Mike Frysinger wrote:
On Sat, Nov 26, 2005 at 02:16:18PM -0500, Daniel Reed wrote:
On Sat, 26 Nov 2005, Mike Frysinger wrote:
On Sat, Nov 26, 2005 at 06:17:10AM +, Paul Jakma wrote:
I tried to upgrade to a 1.5.18 in order to see
On Sun, Nov 27, 2005 at 09:15:12AM +0100, Ralf Wildenhues wrote:
* Mike Frysinger wrote on Sat, Nov 26, 2005 at 09:40:43PM CET:
- do not error out if C++ is not detected and C++ is not required
Yes, works in HEAD.
- do not even include extraneous language checks (CXX/F77/GCJ)
Yes
On Wed, Nov 30, 2005 at 06:10:30PM +, Paul Jakma wrote:
On Tue, 29 Nov 2005, Ralf Wildenhues wrote:
This seems to me the superior solution. Thus, let's kill the
--with-pic idea, too. It won't get us over main.o
compiled-without-libtool and neither one of -fpic or -fpie in
CFLAGS
since Gentoo is a from-source distribution, we do a lot of compiling ...
as such, our maintainers often have to fix bugs in autotool source files
in misc packages (bugs in say configure.ac, not bugs in autoconf). thus
it is not uncommon that we re-run portions of autotools so that we dont
have
On Mon, Dec 19, 2005 at 10:22:04AM +0100, Ralf Wildenhues wrote:
* Mike Frysinger wrote on Mon, Dec 19, 2005 at 06:41:09AM CET:
(thus no relinking) ...
False conclusion. Whether relinking is done for an uninstalled or an
installed binary, depends on several different factors, one of them
On Tuesday 24 January 2006 14:10, syn (sent by Nabble.com) wrote:
If i try to dlsym that symbol it works correctly. Can anyone help me to fix
this problem?
it isnt a bug
C++ code automatically mangles names in such a form as you've shown
-mike
___
:
%{fprofile-arcs|fprofile-generate|coverage:-lgcov}\
also, it would seem that -p is filtered but -pg is let through ...
the attached patch against CVS head should do the trick i think
-mike
pgpQjpzYuuIdL.pgp
Description: PGP signature
gcov-libtool.tar.bz2
Description: application/tbz
2006-12-30 Mike
i'm looking to add support for Linux on the Blackfin processor ... we use
FDPIC ELF as our format, so naturally it'd be nice if libtool didnt get in
our way when generating shared libraries :)
-mike
pgpCbvJNUdMNg.pgp
Description: PGP signature
Index: libltdl/m4/libtool.m4
that on
the patch list still ?
* Mike Frysinger wrote on Fri, Jan 12, 2007 at 11:42:30PM CET:
i'm looking to add support for Linux on the Blackfin processor ... we use
FDPIC ELF as our format, so naturally it'd be nice if libtool didnt get
in our way when generating shared libraries :)
Well, for a new
On Tuesday 16 January 2007 17:30, Ed Hartnett wrote:
When I call AC_PROG_LIBTOOL it seems to call AC_PROG_F77 and
AC_PROG_FC, but I don't want it to.
this should be fixed in the latest cvs, just not latest release
Is there any way to tell libtool that I've already called these
macros, and
On Thursday 18 January 2007 07:41, Ralf Wildenhues wrote:
* Mike Frysinger wrote on Tue, Jan 16, 2007 at 11:48:31PM CET:
On Tuesday 16 January 2007 17:30, Ed Hartnett wrote:
When I call AC_PROG_LIBTOOL it seems to call AC_PROG_F77 and
AC_PROG_FC, but I don't want it to.
this should
On Friday 19 January 2007 01:46, Ralf Wildenhues wrote:
The misunderstanding, as far as I see it, is that you overlooked that
Ed's code *does* use Fortran. He simply wanted to change the test order
in order to avoid duplicate tests.
ok ... i'm going to clock out then
cheers
-mike
is it right that i expect libtool to produce .dlls for my library when
targetting mingw ? if so, what sort of information should i post to track
down why i'm only getting a static archive ?
ive tested libtool 1.5.22 and 1.5.23b ... during configure, the output says
that static and shared libs
On Monday 19 February 2007, Bob Friesenhahn wrote:
On Mon, 19 Feb 2007, Mike Frysinger wrote:
is it right that i expect libtool to produce .dlls for my library when
targetting mingw ? if so, what sort of information should i post to
track down why i'm only getting a static archive
On Tuesday 17 July 2007, Dalibor Topic wrote:
Gary Kumfert wrote:
How does one get new build system triplets cannonized
into config.guess?
The config project owns config.guess. See
http://savannah.gnu.org/projects/config for more information.
the header of the file should already contain
there a list of good hints out there for managing libs across directories ? i
flipped through the libtool manual and the autobook but didnt really find
anything ...
consider:
c/Makefile.am: create a simple C app, needs lib/libfoo.la via LIBADD
lib/Makefile.am: create a simple libfoo.la
On Tuesday 21 August 2007, Jason Curl wrote:
ld.so.1: /home/user/myprog: fatal: libgcc_s.so.1: open failed: No such
file or directory
Killed
the distribution should be taking care of making sure libgcc_s.so.1 is readily
available (or not needed). this is an internal gcc library and has no
On Wednesday 22 August 2007, Peter O'Gorman wrote:
libsuff=`ldd conftest 2/dev/null | awk '/libc\.so/
{n=split([$]3,x,/); for (i=0; i n; i++) { if (x[[i]] == lib64) {print
64}}}'`
this test would still be subject to the environment of ldd ... in otherwords,
it is still possible to have ldd
On Wednesday 22 August 2007, Peter O'Gorman wrote:
On Wed, 2007-08-22 at 06:40 -0400, Mike Frysinger wrote:
On Wednesday 22 August 2007, Peter O'Gorman wrote:
libsuff=`ldd conftest 2/dev/null | awk '/libc\.so/
{n=split([$]3,x,/); for (i=0; i n; i++) { if (x[[i]] == lib64)
{print 64
On Wednesday 24 October 2007, Tom Treadway wrote:
I've seen very frequent references to LD_LIBRARY_PATH bad.
Is there a reference that summaries this badness?
it largely depends on what you're trying to do. must of the it's bad dont do
it mantra is based around people shipping libraries and
archives seem to indicate this has always been an issue, and while it's been
getting better over time, it hasnt really been considered fully fixed.
what i'm looking at here is:
src/one/libone.la:
SOURCES = some files
src/two/libtwo.la:
SOURCES = some files
LDFLAGS =
On Wednesday 09 January 2008, Ralf Wildenhues wrote:
* Bob Rossi wrote on Wed, Jan 09, 2008 at 08:52:20PM CET:
When I do a 'make -s', I usually get no output from the compiler
commands. However with libtool, when it goes into,
mkdir .libs
then I see the compiler output.
To me, you
On Thursday 10 January 2008, Ralf Wildenhues wrote:
Hello Mike,
* Mike Frysinger wrote on Mon, Dec 31, 2007 at 09:52:36PM CET:
archives seem to indicate this has always been an issue, and while it's
been getting better over time, it hasnt really been considered fully
fixed. what i'm
On Thursday 10 January 2008, Ralf Wildenhues wrote:
* Mike Frysinger wrote on Thu, Jan 10, 2008 at 08:29:29PM CET:
On Thursday 10 January 2008, Ralf Wildenhues wrote:
* Mike Frysinger wrote on Mon, Dec 31, 2007 at 09:52:36PM CET:
when doing `make install DESTDIR=/some/place
On Thursday 10 January 2008, Ralf Wildenhues wrote:
* Richard Hacker wrote on Thu, Jan 10, 2008 at 01:39:31PM CET:
On Thursday 10 January 2008 08:29, Ralf Wildenhues wrote:
For whatever output is left done by libtool I expect that whoever
want's it silenced hard enough will have enough
On Thursday 10 January 2008, Ralf Wildenhues wrote:
* Mike Frysinger wrote on Thu, Jan 10, 2008 at 08:58:09PM CET:
On Thursday 10 January 2008, Ralf Wildenhues wrote:
What I meant was: even with
make -s LIBTOOLFLAGS=--silent
there will be some leftover output done by libtool
On Wednesday 06 February 2008, Aleksey Demakov wrote:
On Feb 6, 2008 9:18 PM, Peter O'Gorman [EMAIL PROTECTED] wrote:
What is the host triplet for the system that you are building for?
Umm the canonical host name must be something like
bfin-unknown-linux.
You need to set
On Wednesday 06 February 2008, Peter O'Gorman wrote:
Mike Frysinger wrote:
Blackfin is not the only target that utilizes underscore prefixes. a
more generic check (as noted in the previous thread you cited) would be
to consider the define from gcc __USER_LABEL_PREFIX__.
Feel free to send
On Tuesday 05 February 2008, Gary V. Vaughan wrote:
On 1 Feb 2008, at 01:06, Gary V. Vaughan wrote:
The Libtool Team is pleased to announce alpha release 2.1b of GNU
Libtool.
With only one bug reported and fixed since Feb 1, either this is the
most spectacularly well engineered release in
On Saturday 09 February 2008, Ralf Wildenhues wrote:
* Mike Frysinger wrote on Sat, Feb 09, 2008 at 05:38:19AM CET:
all of the tests pass with libtool-1.5.26 ...
Do all of the old-style tests of 2.1b pass for you, too? The Autotest
ones are all new.
the ones that just say PASS/SKIP/FAIL
On Wednesday 13 February 2008, Ralf Wildenhues wrote:
Argh. AC_LANG_PROGRAM does not produce a meaningful program for Java,
as Autoconf has no decent Java support. Gah! And we test for RUNPATH
using $OBJDUMP in each tag, GCJ last, so there it does not get set to
yes, and
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.
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
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
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
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 support
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.
i doubt people will care at this point
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.
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 (the one
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 file system. we utilize DESTDIR very
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
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
error up front rather
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 handy? Anyway, should be little more
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
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
approach which is fraught with peril
On Tuesday 25 August 2009 18:41:52 Russ Allbery wrote:
Bob Friesenhahn bfrie...@simple.dallas.tx.us 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?
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
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:49PM CEST:
On Tue, 25 Aug 2009, Anssi
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:
- The .la
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:
* Kurt Roeckx wrote on Sun, Aug 30, 2009 at 10:31
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 it
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 is
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 set
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 it,
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 version script support
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:
Hi!
GCRYPT_1.2 {
global
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 03, 2010 05:48:13 Kurt Roeckx wrote
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 symbol is, so that it can
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.
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:
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
If this web page
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 for
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 in
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 you
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
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
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 available. He
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:
lgtm. hopefully a committer will wake up to merge it :).
-mike
signature.asc
Description: Digital signature
___
https://lists.gnu.org/mailman/listinfo/libtool
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
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
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
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
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
___
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
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
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 back
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
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
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
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
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
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 inter
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 natio
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.
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
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
Update of sr#110936 (group libtool):
Status:None => Done
Assigned to:None => vapier
Open/Closed:Open => Closed
Update of sr#110978 (group libtool):
Status:None => Done
Open/Closed:Open => Closed
___
Follow-up Comment #1:
merged now, thanks
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
1 - 100 of 270 matches
Mail list logo
