Re: How to build a noinst_ but still shared library?

On 22/03/2010 21:13, Robert Boehne wrote: > I didn't think convenience libraries were meant to result in shared libs, > just a bucket of object files with a convenient handle. Yes indeed. The problem is that I didn't want a convenience library, I did want a shared lib. Ralf's answer solved the

Re: how to "parse" gcc -v output

On 04/04/2010 20:08, Joseph S. Myers wrote: > I think extracting compiler/linker *internal commands* and trying to > process or adapt them is inherently fragile and liable to break whenever > new compiler/linker options (internal or otherwise) are added. If > possible the aim should be to work

Re: bogus warning 'seems to be moved'

On 22/09/2010 09:49, Marco Atzeri wrote: > Dear developers, > is this bogus warning avoidable in the next release ? > > libtool: link: warning: > `/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libfontconfig.la' > seems to be moved > libtool: link: warning: > `/usr/lib/gcc/i686-pc-cygwin/4.3.4/../..

Re: bindir.at takes forever.

On 28/09/2010 21:36, Ralf Wildenhues wrote: > Hi Peter, > > * Peter Rosin wrote on Tue, Sep 28, 2010 at 02:28:48PM CEST: >> I have been looking at the loops in tests/bindir.at and I see >> this: > > bindir.at has several problems. Argh. Sorry for the mess, it's the first and only libtool test

Re: Extend libtool dll namespaces for mingw-w64

On 29/01/2010 01:10, JonY wrote: > On 1/29/2010 04:07, Ralf Wildenhues wrote: > Yes, GCC trunk uses that, but right now, -bindir for both 32bit and > 64bit subsystems point to the same dir. > > Another solution it to stop installing DLLs to bindir and follow unix > style installs into libdir, rig

Re: Extend libtool dll namespaces for mingw-w64

On 30/01/2010 14:56, Ralf Wildenhues wrote: > web site, refer to this page, rebuild your binutils ld to automatically > search for the changed prefix when it encounters -lfoo on the command Not binutils, I don't think: > [1] My ld.info contains, speaking about cygwin, > > For instance, w

Can anyone think of a way to get circular dependencies between windows DLLs?

Hi all, I have an interesting problem to try and solve: I need to create circularly-dependent shared libs using libtool on Windows(*). This is trivial on the ELF targets that libtool supports because you just leave undefined references in both the libraries, link them against each other,

Re: Can anyone think of a way to get circular dependencies between windows DLLs?

On 17/03/2010 21:24, Ralf Wildenhues wrote: > You can use '-Wc,', '-Wl,', '-Xcompiler ', or '-Xlinker ' to get command > line arguments to by-pass libtool mangling and interpretation, and end > up being passed to the compiler driver or the linker, respectively. > The arguments may be ordered diffe

Re: Can anyone think of a way to get circular dependencies between windows DLLs?

On 18/03/2010 18:57, Ralf Wildenhues wrote: > Hi Dave, > > * Dave Korn wrote on Thu, Mar 18, 2010 at 02:49:35AM CET: >> Can I build an import library in the .libs/ subdir and leave an empty one >> by >> the same name in the parent dir and the -L paths will make sur

How to build a noinst_ but still shared library?

Hi all, Well, here I am again with another dumb n00b question. From the automake manual: " Libtool convenience libraries are declared by directory-less variables such as `noinst_LTLIBRARIES', `check_LTLIBRARIES', or even `EXTRA_LTLIBRARIES'. " So: how do you build a shared library i

Re: How to build a noinst_ but still shared library?

On 20/03/2010 00:23, Ralf Wildenhues wrote: > libfoo_la_LDFLAGS = -rpath /nowhere Ah, right, that overrides the implied -static, even on systems where -rpath doesn't mean anything? Perfect, I'll give it a go. cheers, DaveK ___ http://li