GNU bug report logs - #12672
Wrong path to funclib.sh

Previous Next

Package: libtool;

Reported by: Peter Rosin <peda <at> lysator.liu.se>

Date: Thu, 18 Oct 2012 15:18:02 UTC

Severity: normal

To reply to this bug, email your comments to 12672 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-libtool <at> gnu.org:
bug#12672; Package libtool. (Thu, 18 Oct 2012 15:18:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Peter Rosin <peda <at> lysator.liu.se>:
New bug report received and forwarded. Copy sent to bug-libtool <at> gnu.org. (Thu, 18 Oct 2012 15:18:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: bug-libtool <at> gnu.org
Subject: Wrong path to funclib.sh
Date: Thu, 18 Oct 2012 17:16:06 +0200
Hi!

If I "make dist" in Cygwin, then extract the tarball
and configure it from a freshly created build dir, it
works just fine.

I.e.

$ cd /home/peda/libtool/git/cygwin
$ make dist
...
$ tar xf libtool-2.4.2.296-cfcb-dirty.tar.gz
$ cd libtool-2.4.2.296-cfcb-dirty
$ mkdir cyg
$ cd cyg
$ ../configure
...
$ make
...
$

So far so good, but if I then switch to MSYS/MinGW, which does not
have the same file system layout, I get:

$ cd /c/Cygwin/home/peda/libtool/git/cygwin/libtool-2.4.2.296-cfcb-dirty
$ mkdir mgw
$ cd mgw
$ ../configure
...
$ make
  GEN    libtoolize
  GEN    libltdl/argz.h
make  all-recursive
make[1]: Entering directory `/c/Cygwin/home/peda/libtool/git/cygwin/libtool-2.4.2.296-cfcb-dirty/mgw'
Making all in .
make[2]: Entering directory `/c/Cygwin/home/peda/libtool/git/cygwin/libtool-2.4.2.296-cfcb-dirty/mgw'
  CC     libltdl/loaders/libltdl_libltdl_la-preopen.lo
./libtool: line 525: /home/peda/libtool/git/libtool-msvc/build-aux/funclib.sh: No such file or directory
make[2]: *** [libltdl/loaders/libltdl_libltdl_la-preopen.lo] Error 1
make[2]: Leaving directory `/c/Cygwin/home/peda/libtool/git/cygwin/libtool-2.4.2.296-cfcb-dirty/mgw'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/c/Cygwin/home/peda/libtool/git/cygwin/libtool-2.4.2.296-cfcb-dirty/mgw'
make: *** [all] Error 2
$


/home/peda/libtool/git/libtool-msvc/build-aux/funclib.sh
isn't what you should use from MSYS, that file is called
/c/Cygwin/home/peda/libtool/git/libtool-msvc/build-aux/funclib.sh
from that side of the fence.

I have also checked to just build a pristine tarball from
the MSYS side, without building on Cygwin first, same problem.
It appears that the path to funclib.sh is fixed during
bootstrap which of course is totally b0rked.

Cheers,
Peter




Information forwarded to bug-libtool <at> gnu.org:
bug#12672; Package libtool. (Thu, 18 Oct 2012 17:59:01 GMT) Full text and rfc822 format available.

Message #8 received at 12672 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Earnie Boyd <earnie <at> users.sourceforge.net>
Cc: 12672 <at> debbugs.gnu.org
Subject: Re: bug#12672: Wrong path to funclib.sh
Date: Thu, 18 Oct 2012 19:58:17 +0200
[re-adding the bug, I hope that's ok]

On 2012-10-18 19:18, Earnie Boyd wrote:
> On Thu, Oct 18, 2012 at 11:16 AM, Peter Rosin <peda <at> lysator.liu.se> wrote:
>>
>> So far so good, but if I then switch to MSYS/MinGW, which does not
>> have the same file system layout, I get:
>>
>> $ cd /c/Cygwin/home/peda/libtool/git/cygwin/libtool-2.4.2.296-cfcb-dirty
>> $ mkdir mgw
>> $ cd mgw
>> $ ../configure
>> ...
>> $ make
>>   GEN    libtoolize
>>   GEN    libltdl/argz.h
>> make  all-recursive
>> make[1]: Entering directory `/c/Cygwin/home/peda/libtool/git/cygwin/libtool-2.4.2.296-cfcb-dirty/mgw'
>> Making all in .
>> make[2]: Entering directory `/c/Cygwin/home/peda/libtool/git/cygwin/libtool-2.4.2.296-cfcb-dirty/mgw'
>>   CC     libltdl/loaders/libltdl_libltdl_la-preopen.lo
>> ./libtool: line 525: /home/peda/libtool/git/libtool-msvc/build-aux/funclib.sh: No such file or directory
> 
> I'm not getting this from a fresh pull, bootstrap, configure process.

But I didn't try a fresh pull, bootstrap, configure process, and I don't
expect that to fail. I tried to move a tarball to another system and
use it there (in lose terms).

>> make[2]: *** [libltdl/loaders/libltdl_libltdl_la-preopen.lo] Error 1
>> make[2]: Leaving directory `/c/Cygwin/home/peda/libtool/git/cygwin/libtool-2.4.2.296-cfcb-dirty/mgw'
>> make[1]: *** [all-recursive] Error 1
>> make[1]: Leaving directory `/c/Cygwin/home/peda/libtool/git/cygwin/libtool-2.4.2.296-cfcb-dirty/mgw'
>> make: *** [all] Error 2
>> $
>>
>>
>> /home/peda/libtool/git/libtool-msvc/build-aux/funclib.sh
>> isn't what you should use from MSYS, that file is called
>> /c/Cygwin/home/peda/libtool/git/libtool-msvc/build-aux/funclib.sh
>> from that side of the fence.
>>
> 
> It wasn't funclib.sh that complained but your libtool script.

I never said so, I said that the path pointing out funclib.sh
was wrong, not that the funclib.sh script as such was wrong.

>> I have also checked to just build a pristine tarball from
>> the MSYS side, without building on Cygwin first, same problem.
>> It appears that the path to funclib.sh is fixed during
>> bootstrap which of course is totally b0rked.
> 
> WJFFM.  I will say that I was completely outside of the source
> directory for both builds.

You probably still had access to the original directory where
the bootstrap happened.

Try this instead if you don't want to move a tarball to another
system:

$ cd /tmp
$ git clone git://git.savannah.gnu.org/libtool.git
$ cd libtool
$ ./bootstrap -fc


bootstrap fails, why? Is that also a regression?
I had to fix the tail of gl/README-release.diff,
with this diff (which is why the checkout is dirty):


diff --git a/gl/top/README-release.diff b/gl/top/README-release.diff
index 19cc3ec..49e2a7e 100644
--- a/gl/top/README-release.diff
+++ b/gl/top/README-release.diff
@@ -33,6 +33,6 @@
 
 +  If there are any problems, fix them and start again.
 +
- * To (i) set the date, version number, and release type [stable/alpha/beta]
-   on line 3 of NEWS, (ii) commit that, and (iii) tag the release, run
+ * To (i) set the date, version number, and release TYPE on line 3 of
+   NEWS, (ii) commit that, and (iii) tag the release, run
 


Now retry the bootstrap:

$ ./bootstrap -fc
$ ./configure
$ make
$ make dist
$ cp libtool-2.4.2.296-cfcb-dirty.tar.gz ..
$ cd ..
$ rm -rf libtool
$ tar xf libtool-2.4.2.296-cfcb-dirty.tar.gz
$ cd libtool-2.4.2.296-cfcb-dirty
$ ./configure
$ make
  GEN      libtoolize
make  all-recursive
make[1]: Entering directory `/tmp/libtool-2.4.2.296-cfcb-dirty'
Making all in .
make[2]: Entering directory `/tmp/libtool-2.4.2.296-cfcb-dirty'
  CC       libltdl/loaders/libltdl_libltdl_la-preopen.lo
./libtool: line 525: /tmp/libtool/build-aux/funclib.sh: No such file or directory
Makefile:1163: recipe for target `libltdl/loaders/libltdl_libltdl_la-preopen.lo' failed
make[2]: *** [libltdl/loaders/libltdl_libltdl_la-preopen.lo] Error 1
make[2]: Leaving directory `/tmp/libtool-2.4.2.296-cfcb-dirty'
Makefile:1511: recipe for target `all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/libtool-2.4.2.296-cfcb-dirty'
Makefile:905: recipe for target `all' failed
make: *** [all] Error 2




Some further info, "git grep auxscriptsdir" in the git checkout
returns this:
$ git grep auxscriptsdir
Makefile.am:              -e '/^\. /s|@auxscriptsdir\@|'$(abs_aux_dir)'|g' \
build-aux/ltmain.in:. "@auxscriptsdir@/funclib.sh"
build-aux/ltmain.in:. "@auxscriptsdir@/options-parser"
libtoolize.in:. "@auxscriptsdir@/funclib.sh"
libtoolize.in:. "@auxscriptsdir@/options-parser"
libtoolize.in:. "@auxscriptsdir@/extract-trace"

which makes libtool and libtoolize suspect.

However, only the libtool script seems affected, this is from the
configured tarball tree on MSYS (the [^n] part is there to exclude
paths starting with /c/Cygwin/home/...):

$ grep -r [^n]/home/peda *
build-aux/ltmain.sh:. "/home/peda/libtool/git/libtool-msvc/build-aux/funclib.sh"
build-aux/ltmain.sh:. "/home/peda/libtool/git/libtool-msvc/build-aux/options-parser"
libtool:. "/home/peda/libtool/git/libtool-msvc/build-aux/funclib.sh"
libtool:. "/home/peda/libtool/git/libtool-msvc/build-aux/options-parser"

Cheers,
Peter





Information forwarded to bug-libtool <at> gnu.org:
bug#12672; Package libtool. (Thu, 18 Oct 2012 19:29:01 GMT) Full text and rfc822 format available.

Message #11 received at 12672 <at> debbugs.gnu.org (full text, mbox):

From: "Gary V. Vaughan" <gary <at> vaughan.pe>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: "12672 <at> debbugs.gnu.org" <12672 <at> debbugs.gnu.org>
Subject: Re: bug#12672: Wrong path to funclib.sh
Date: Fri, 19 Oct 2012 02:27:23 +0700
Hi Peter,

On 18 ต.ค. 2012, at 22:16, Peter Rosin <peda <at> lysator.liu.se> wrote:
> [[snip]]
> I have also checked to just build a pristine tarball from
> the MSYS side, without building on Cygwin first, same problem.
> It appears that the path to funclib.sh is fixed during
> bootstrap which of course is totally b0rked.

Oh! Nice catch, thank you :-)

Fixed. Please pull my updates.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



Information forwarded to bug-libtool <at> gnu.org:
bug#12672; Package libtool. (Thu, 18 Oct 2012 19:50:02 GMT) Full text and rfc822 format available.

Message #14 received at 12672 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: "Gary V. Vaughan" <gary <at> vaughan.pe>
Cc: "12672 <at> debbugs.gnu.org" <12672 <at> debbugs.gnu.org>
Subject: Re: bug#12672: Wrong path to funclib.sh
Date: Thu, 18 Oct 2012 21:48:56 +0200
close 12672

Hi Gary!

On 2012-10-18 21:27, Gary V. Vaughan wrote:
> On 18 ต.ค. 2012, at 22:16, Peter Rosin <peda <at> lysator.liu.se> wrote:
>> [[snip]]
>> I have also checked to just build a pristine tarball from
>> the MSYS side, without building on Cygwin first, same problem.
>> It appears that the path to funclib.sh is fixed during
>> bootstrap which of course is totally b0rked.
> 
> Oh! Nice catch, thank you :-)
> 
> Fixed. Please pull my updates.

Seems to have done it, and I'm back in business. Thanks for the
quick fix!

Cheers,
Peter





This bug report was last modified 12 years and 247 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.