GNU bug report logs - #16485
Using libtool in BusyBox

Previous Next

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

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

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

From: Joachim Bartz <joachim.bartz <at> t-online.de>
To: <bug-libtool <at> gnu.org>
Subject: Using libtool in BusyBox
Date: Sat, 18 Jan 2014 16:41:26 +0100

[Message part 1 (text/plain, inline)]

Hello all together.

I think I found a bug in the libtool 2.4.2, but I don¹t have any idea how
to get around the problem.

My environment is as follows:
I want to compile the current apache httpd 2.4.7 to run on my QNAP NAS.
All works fine, I can compile current apr & apr-util and install them
without any problem.
I can compile the httpd without any problem, too.

But if I use the command "make install³, I finally get these error lines:
install: unable to open `/opt/www/modules/mod_echo.la/mod_echo.lai': No
such file or directory
install: cannot change permissions of
/opt/www/modules/mod_echo.la/mod_echo.lai: No such file or directory
install: cannot change ownership of
/opt/www/modules/mod_echo.la/mod_echo.lai: No such file or directory

But if I enter the commands manually, all works fine. HmmmŠ
Using the "make install" multiple times gives - sometimes - different
failing file names.

I attached two log files using the libtool --debug option:
  * make-install.log is the output of the failing command using "make
install"
  * libtool-mod_echo-ok.log is the output of succeeding command

Maybe this information can help you the find a reason and/or bug.
I don¹t think this is a QNAP/BusyBox problem, because compiling and
installing other tools works fine.

Thanks a lot in advance.
If you have further questions do not hesitate to ask me.

Regards from Germany
Joachim Bartz

[libtool-mod_echo-ok.txt (text/plain, attachment)]

[make-install.txt (text/plain, attachment)]

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

From: Joachim Bartz <joachim.bartz <at> t-online.de>
To: <16485 <at> debbugs.gnu.org>
Subject: Re: bug#16485: Acknowledgement (Using libtool in BusyBox)
Date: Sat, 18 Jan 2014 23:47:53 +0100

Hi again.

I found no rest and had a clue: The BusyBox install utility could be bogus.

So I installed the coreutils package and renamed the bogus install utility
so that the correct install util can be found easily in the path.

And: It works, all modules are installed correctly.


But what I don¹t understand is, why does libtool sometimes fail and
sometimes not.
I expect a deterministic behavior - always.

Regards
Joachim Bartz
 

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

From: "Gary V. Vaughan" <gary <at> gnu.org>
To: Joachim Bartz <joachim.bartz <at> t-online.de>
Cc: 16485 <at> debbugs.gnu.org
Subject: Re: bug#16485: Acknowledgement (Using libtool in BusyBox)
Date: Sun, 19 Jan 2014 12:25:08 +1300

[Message part 1 (text/plain, inline)]

Hi Joachim,

Glad you solved it :)

On Jan 19, 2014, at 11:47 AM, Joachim Bartz <joachim.bartz <at> t-online.de> wrote:
> And: It works, all modules are installed correctly.
> 
> 
> But what I don¹t understand is, why does libtool sometimes fail and
> sometimes not.
> I expect a deterministic behavior - always.

It's probably a timestamp resolution issue, or a race condition of some sort - the kind of bug that can take hundreds of hours to pin down.  Patches welcome of course ;-)

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

[signature.asc (application/pgp-signature, attachment)]

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

From: Joachim Bartz <joachim.bartz <at> t-online.de>
To: <16485 <at> debbugs.gnu.org>
Subject: RE: bug#16485: Acknowledgement (Using libtool in BusyBox)
Date: Thu, 23 Jan 2014 21:41:37 +0100

Hi Gary,

I could not figure out, how to really get around the buggy BusyBox install
tool.

Debugging BusyBox is no option at all.

So I added a few lines to libtool's configure script.

I recommend to use the following patch for libtool 2.4.2:


# diff configure.bak configure

2735a2736,2739

>  elif test $ac_prog = install &&

>    grep "BusyBox v1.01" "$as_dir/$ac_prog$ac_exec_ext" >/dev/null 2>&1;
>then
>    # BusyBox v1.01 has a bogus install utility -- don't use.
>    :

It is very restrictive to a special BusyBox version.
But I think this BusyBox version is spread very wide.

If you really apply this path:
What about libtool derivates for example in apr?
Will this patch be applied there too?
--
Best regards
Joachim

Previous Next

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