Re: somewhat misleading -no-undefined documentation
Ralf Wildenhues writes: > I kinda like Simon's patch you referenced (wow, that's old!), so how > about this patch which takes from both your suggestions? I like it. Thanks, this closes a long-standing libtool concern of mine. Generally, having to use -no-undefined to get things to work on some
Re: [RFC] w32 and Libtool.
First, thanks for working on this. It is definitely needed in the manual. I have re-engineered this a couple of times already, but the collected wisdom should be in the manual in the first place. Peter Rosin writes: > #if defined _WIN32 && !defined __GNUC__ > # ifdef BUILDING_LIBFOO > # ifdef
Re: [RFC] w32 and Libtool.
Peter Rosin writes: > DLL_EXPORT comes from libtool, so it should not be changed to > LIBFOO_DLL_EXPORT. Right. > And while I approve of starting with LIBFOO_ instead of BUILDING_, > LIBFOO_BUILDING sounds very wrong as BUILDING changes from a verb to a > noun. LIBFOO_BUILD perhaps? Other sugg
Re: [RFC] w32 and Libtool.
Peter Rosin writes: >> The first issue (i.e., MSC static builds) could be handled by the means >> in the second point (i.e., project specifying -DGSASL_API="") though. >> Then there would be no need for GSASL_STATIC. >> >> Anyway, I think the block will likely need to be adapted by each >> proje
modules have a soname?
I'm tracking down why I get warnings from dpkg-shlibdeps on a package that builds dlopen modules with libtool. For reference, a build log is available here: https://buildd.debian.org/status/fetch.php?pkg=jabberd2&arch=amd64&ver=2.3.4-1%2Bb1&stamp=1446749350 According to dpkg-shlibdeps dlopen mod
Re: modules have a soname?
Russ Allbery writes: > Simon Josefsson writes: > >> I'm tracking down why I get warnings from dpkg-shlibdeps on a package >> that builds dlopen modules with libtool. For reference, a build log is >> available here: > >> https://buildd.debian.org/status
Re: modules have a soname?
Simon Josefsson writes: >> In other words, this is probably an upstream Makefile issue rather than a >> problem with either libtool or dpkg-shlibdeps. > > Upstream do use -avoid-version in their Makefile.am, but I just noticed > that it might not be used in all places. I
Building mingw32 DLLs without -no-undefined?
Hi! I'm able to build a win32 DLL of libidn using libtool and mingw32, but it didn't work with libgsasl. The difference was that libidn specified a -no-undefined where as libgsasl didn't. libgsasl depend on libidn, so that is understandable. `-no-undefined' Declare that OUTPUT-FILE does no
Re: Building mingw32 DLLs without -no-undefined?
Ralf Wildenhues <[EMAIL PROTECTED]> writes: > Hi Simon, > > * Simon Josefsson wrote on Tue, Mar 07, 2006 at 03:15:29PM CET: >> Hi! I'm able to build a win32 DLL of libidn using libtool and >> mingw32, but it didn't work with libgsasl. The difference was tha
Re: mingw and dlls
Bob Friesenhahn <[EMAIL PROTECTED]> writes: > 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 ? >> >> i
Re: Libtool fails to build working binary when -no-install is used
On 4 apr 2007, at 00.21, Peter O'Gorman wrote: On Apr 3, 2007, at 5:16 PM, Simon Josefsson wrote: On 3 apr 2007, at 23.44, Ralf Wildenhues wrote: Do I understand correctly that Darwin has no way to hardcode library paths (other than the ones given by -install-name)? OK to appl
Re: relinking makes libtool link to the wrong library
FWIW, I have a theory that this may be caused by having -L/-l in LIBADD variables rather than in LDFLAGS variables. Since there are many instances of this in various nested levels in gnutls, it will take some time to see if this is indeed the problem. Do you think fixing this will solve the probl
Re: relinking makes libtool link to the wrong library
Ralf Wildenhues <[EMAIL PROTECTED]> writes: > Hello Simon, > > * Simon Josefsson wrote on Fri, Jan 11, 2008 at 03:20:44PM CET: >> Hi! We have received a bug report about some parts of recent gnutls >> (libgnutls-extra.so.26) incorrectly links to the libgnutls.so in
Re: relinking makes libtool link to the wrong library
Ralf Wildenhues <[EMAIL PROTECTED]> writes: > Hi Simon, > > 0) I forgot to ask: is this libtool 1.5.24? Yes. From debian testing. > 1) ../lib/libgnutls.la has dependency_libs entry that contains -L/usr/lib > and -L/usr/local/lib, both wrongly I think. Why is that? To find out, > please send `
relinking makes libtool link to the wrong library
Hi! We have received a bug report about some parts of recent gnutls (libgnutls-extra.so.26) incorrectly links to the libgnutls.so in /usr/lib/ rather than in $prefix, see original report: http://lists.gnu.org/archive/html/gnutls-devel/2007-12/msg00038.html To understand how this works, GnuTLS co
Re: GNU Libtool 2.1b released (alpha release)
"Gary V. Vaughan" <[EMAIL PROTECTED]> writes: > 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 i
Re: shared library symbol exports and versioning
Bruno Haible writes: > Simon Josefsson wrote: >> I won't dispute that ELF version symbol scripts are overrated because >> they aren't portable. But they do provide some features, and together >> with a scheme like you suggest you get more complete cross-platfor
Re: running libtool from emacs gud mode
"Justin Randall" <[EMAIL PROTECTED]> writes: > I know this was asked once before, but I couldn't find any answers to the question. > Sorry if this is a FAQ. > > I can usually run gdb from emacs using > M-x gdb > Run gdb (like this): gdb > > Of course, to run gdb on a libtool output file that has
Re: Introducing a new maintainer of libtool
2024-01-16
Thread
Simon Josefsson via Discussion list for the GNU libtool shared library maintenance tool
Welcome Ileana! Mike Frysinger writes: > 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
Re: Introducing a new maintainer of libtool
2024-01-17
Thread
Simon Josefsson via Discussion list for the GNU libtool shared library maintenance tool
Ileana Dumitrescu writes: >> On 16/01/2024 22:59, Simon Josefsson wrote: >> If what's on git master passes self checks, I would package it and >> prepare an alpha release and announce that to pretesters mailing list. >> Assuming there is nothing in git master tha