On Tue, 17 Apr 2007, Ralf Wildenhues wrote:
If you can find out the set of libraries at 'configure' time, then there
is no need for dlopen.
There is in my case: I do know the set of libraries at configure time, but I
can't link against all of them. The particular case I have in mind is
Hi,
I have been having problems with building modules to be installed
into pkglibdir automatically, but I have been having problems using
pkglib_LTLIBRARIES and EXTRA_LTLIBRARIES to work together. Instead I
have been using lib_LTLIBRARIES and EXTRA_LTLIBRARIES and setting rpath.
However
On Wed, Apr 18, 2007 at 03:54:13PM +0100, Nicholas J Humfrey wrote:
I have been having problems with building modules to be installed
into pkglibdir automatically, but I have been having problems using
pkglib_LTLIBRARIES and EXTRA_LTLIBRARIES to work together. Instead I
have been using
Aha, so your not using EXTRA_LTLIBRARIES at all.
I quite liked having a string list of modules to be built, but
perhaps I will have a go at using Automake Conditionals instead.
Thanks for your reply,
nick.
On 18 Apr 2007, at 16:51, David Nečas (Yeti) wrote:
On Wed, Apr 18, 2007 at
[added libtool to CC list]
Corinna Vinschen wrote:
On Apr 18 04:49, Charles Wilson wrote:
The current .exe behavior has benefited from many years of tweaking and
fine-tuning, across many different packages (cygwin, gcc, gdb, binutils,
automake, autoconf, libtool, bash, coreutils, ...) to work
* Nicholas J Humfrey wrote on Wed, Apr 18, 2007 at 04:54:13PM CEST:
I have been having problems with building modules to be installed
into pkglibdir automatically, but I have been having problems using
pkglib_LTLIBRARIES and EXTRA_LTLIBRARIES to work together. Instead I
have been using
Hello Richard,
* richard wrote on Tue, Apr 17, 2007 at 11:18:24PM CEST:
I'd like to start slow by just crosscompile a executable and a dynamic
library,
but i fail at building the .dll with libtool complaining about
libtool: link: warning: undefined symbols not allowed in
[Added libtool-patches to CC list. Discussion of this patch
should probably drop libtool and cygwin]
Ralf Wildenhues wrote:
* Charles Wilson wrote on Wed, Apr 18, 2007 at 08:49:31PM CEST:
Caveat: over a year after the message referenced above, but libtool2.0
is STILL in code-slush, so the
Charles Wilson wrote:
Charles Wilson wrote:
Charles Wilson wrote:
I'll whip up a patch and post it to the newlib list.
So, I posted the following:
http://sourceware.org/ml/newlib/2007/msg00271.html
However, there's no telling how long it'll be before a new cygwin
kernel is released that
On Wed, 18 Apr 2007, Charles Wilson wrote:
[snip long description of ugly runtime test]
See
http://lists.gnu.org/archive/html/libtool-patches/2007-03/msg00030.html
After discussion with Bob F, I've reimplemented this fix without the actual
runtime test. Instead, if $host_os is cygwin, and
[Added libtool-patches to CC list. Discussion of this patch
should probably drop libtool and cygwin]
Ralf Wildenhues wrote:
* Charles Wilson wrote on Wed, Apr 18, 2007 at 08:49:31PM CEST:
Caveat: over a year after the message referenced above, but libtool2.0
is STILL in code-slush, so the
Bob Friesenhahn wrote:
On Wed, 18 Apr 2007, Charles Wilson wrote:
[snip long description of ugly runtime test]
See
http://lists.gnu.org/archive/html/libtool-patches/2007-03/msg00030.html
After discussion with Bob F, I've reimplemented this fix without the
actual runtime test. Instead, if
Charles Wilson wrote:
Okay, here's the first bit. It's pretty simple. Testing is in progress
(and in conjuction with the new argz fix I just posted to
libtool-patches), but looks good so far: the new wrapper scripts are
identical to old ones generated without this patch.
Test results -- old
13 matches
Mail list logo
