Hi Peter,
On Apr 13, Peter Rosin wrote:
On 2013-04-13 02:31, Shaddy Baddah wrote:
Hi Peter,
On 13/04/13 09:15, Peter Rosin wrote:
Have I stumbled on a real problem?
This all sounds suspiciously like libtool bug 14022, where the reporter
had confused --build and --host. How did you run
On 2013-04-13 02:31, Shaddy Baddah wrote:
> Hi Peter,
>
> On 13/04/13 09:15, Peter Rosin wrote:
>
>>> Have I stumbled on a real problem?
>>
>> This all sounds suspiciously like libtool bug 14022, where the reporter
>> had confused --build and --host. Ho
Hi Peter,
On 13/04/13 09:15, Peter Rosin wrote:
Have I stumbled on a real problem?
This all sounds suspiciously like libtool bug 14022, where the reporter
had confused --build and --host. How did you run configure?
I'm emulating what is in setup/bootstrap.sh:
$ ../cygwin-setup/conf
from that build host, a Windows 8
> computer. However, I also encountered exactly the same problem on a
> Windows 7 computer.
>
> Have I stumbled on a real problem?
This all sounds suspiciously like libtool bug 14022, where the reporter
had confused --build and --host. How did you
Yaakov (Cygwin/X) wrote:
> There's a bug in LT_PATH_LD (AC_PROG_LD) when called prior to LT_INIT
> (AC_PROG_LIBTOOL):
...
>
> Patch attached.
Seems like an obvious fix. I've posted it upstream and am waiting for
approval.
But I'd planned to roll out a new libtool from latest git-master soon;
I'l
Chuck,
There's a bug in LT_PATH_LD (AC_PROG_LD) when called prior to LT_INIT
(AC_PROG_LIBTOOL):
checking for ld used by gcc...
/usr/lib/gcc/i686-pc-cygwin/4.3.2/../../../../i686-pc-cygwin/bin/ld: no
input files
./configure: line 3955: : command not found
Yet this does not occur when the sa
[EMAIL PROTECTED] writes:
> > /home/Hanwen/src/guile-1.7.1/libguile/.libs; however,
> > running GCC with
> >
> > -L/home/Hanwen/src/guile-1.7.1/libguile/.libs -lguile
> >
> > does work, so libtool is incorrectly translating the commandline.
> > I take that I don't need to run GCC with -Wl,verb
Han-Wen Nienhuys wrote:
Evidently, this fails, because libguile.dll.a lives in
/home/Hanwen/src/guile-1.7.1/libguile/.libs; however,
running GCC with
-L/home/Hanwen/src/guile-1.7.1/libguile/.libs -lguile
does work, so libtool is incorrectly translating the commandline.
I take that I don't need t
Han-Wen Nienhuys writes:
> At some point, make issues the following command line,
>
> /bin/bash ../libtool --mode=install /usr/bin/install -c
> libguile-srfi-srfi-1-v-2.la
> /usr/local/lib/libguile-srfi-srfi-1-v-2.la
> libtool: install: warning: relinking `
[EMAIL PROTECTED] writes:
> I wrote:
> > This:
> >
> > gcc -shared .libs/srfi-1.o -L/lib -L/usr/lib
> > -L/home/Hanwen/src/guile-1.7.1/libguile-ltdl/.libs -L/usr/local/lib
> > -lguile -lpthread -lgmp -lcrypt -o
> > .libs/cygguile-srfi-srfi-1-v-2-2.dll -Wl,--image-base=0x1000
>
Han-Wen Nienhuys wrote:
No, this is not correct. My original email exactly described the
problem: when linking the libsrfi-1 library with libtool 1.5.10 on
Cygwin, libguile.dll.a is not linked, causing the link to fail.
For mysterious reasons (libtool brokenness, I suppose), the compile
and make in
[EMAIL PROTECTED] writes:
> Charles Wilson writes:
>
> > BTW, Jan, I gather that, despite my earlier doubts, the libtool
> > changes in 1.5.10 fixed the "The application failed to initialize
> > properly (0xc005).
>
> Not exactly, it is fixed, but I cannot confirm that was the fix.
> Guile ha
Charles Wilson writes:
> BTW, Jan, I gather that, despite my earlier doubts, the libtool
> changes in 1.5.10 fixed the "The application failed to initialize
> properly (0xc005).
Not exactly, it is fixed, but I cannot confirm that was the fix.
Guile had a copy of libtool pre 1.4 or something,
Hello Reini,
[...]
> But it didn't help on another (related?) new cygwin libtool problem:
> Sometimes it switches to .exe instead of .dll. Will investigate this
> further. My current theory is that -o just missed the .dll
> extension and .exe is then taken as default.
I saw similar errors be
Charles Wilson wrote:
Whether to set the $PATH and produce wrapper scripts is clearly a
distinct issue from "should stuff be relinked on install" -- although on
platforms which encode -rpaths into sharedlibs and executables one issue
will affect the other.
Not true on cygwin.
These two question
BTW, note that the problem (whatever it is) exposed here, will be hidden
by the patch I'm about to post to this list and to libtool-patches.
I really hope somebody (Jan? Han-Wen Nienhuys?) will try their guile
build with unmodified libtool-1.5.10, and when the relink fails manually
execute
>
[CC:ed to libtool-patches list]
Background for the libtool-patches guys: Question revolves around a
problem with relinking executables (and DLLs which depend on other
uninstalled DLLs, actually) when installing stuff on cygwin. There are
actually two problems; only the first is addressed here
Charles Wilson wrote:
Jan Nieuwenhuizen wrote:
Do you have an insight wrt the start of this thread? That's stalling
a Guile-1.7/libguile16 release and with it the LilyPond 2.3 series.
BTW, Jan, I gather that, despite my earlier doubts, the libtool changes
in 1.5.10 fixed the "The application fai
Jan Nieuwenhuizen wrote:
Do you have an insight wrt the start of this thread? That's stalling
a Guile-1.7/libguile16 release and with it the LilyPond 2.3 series.
No, I don't. This:
gcc -shared .libs/srfi-1.o -L/lib -L/usr/lib
-L/home/Hanwen/src/guile-1.7.1/libguile-ltdl/.libs -L/u
Charles Wilson writes:
> Not entirely true. With your change (or one very similar), all of the
> *-exec.tests in the libtool test suite failed. These tests attempt to
> run the uninstalled executable. I'm not sure why; it's probably a
> side effect of the change, not just "relinking" itself.
>
Gerrit P. Haase wrote:
Hallo Jan,
Am Freitag, 8. Oktober 2004 um 09:16 schriebst du:
Charles Wilson writes:
What was my objection back then? I'm sure someone objected, because
otherwise it would have gone in; and I'm sure it was me, because
nobody else cares about the libtool internals. :-)
Wha
Hallo Jan,
Am Freitag, 8. Oktober 2004 um 09:16 schriebst du:
> Charles Wilson writes:
>> What was my objection back then? I'm sure someone objected, because
>> otherwise it would have gone in; and I'm sure it was me, because
>> nobody else cares about the libtool internals. :-)
> What is reli
Charles Wilson writes:
> What was my objection back then? I'm sure someone objected, because
> otherwise it would have gone in; and I'm sure it was me, because
> nobody else cares about the libtool internals. :-)
What is relinking supposed to achieve?
Jan.
--
Jan Nieuwenhuizen <[EMAIL PROTECT
Gerrit P. Haase wrote:
$ diff -ud ltmain.sh.old ltmain.sh
--- ltmain.sh.old 2004-10-08 01:56:36.797564800 +0200
+++ ltmain.sh 2004-10-02 02:24:08.852576000 +0200
@@ -2416,7 +2416,7 @@
{ test "$prefer_static_libs" = no || test -z "$old_library"; }; then
if test "$install
Hello Han-Wen,
> libtool: install: warning: relinking `libguile-srfi-srfi-1-v-2.la'
I saw also problems with the useless relinking, I think it is time to
remove this for Cygwin completely. I have already fixed it in my
local copy:
$ diff -ud ltmain.sh.old ltmain.sh
--- ltmain.sh.old
[EMAIL PROTECTED] writes:
>
>
> Hi,
>
> I'm trying to compile guile-1.7.1 on cygwin, with a recently installed
> libtool,
>
> ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.95 2004/04/11 05:50:42)
>
addendum: 1.5.10 has the same behavior.
--
Han-Wen Nienhuys | [EMAIL PROTECTED] | ht
Hi,
I'm trying to compile guile-1.7.1 on cygwin, with a recently installed
libtool,
ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.95 2004/04/11 05:50:42)
At some point, make issues the following command line,
/bin/bash ../libtool --mode=install /usr/bin/install -c
l
27 matches
Mail list logo
