bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libtool 2.2.6 bug: CR/LF result (from sed?) causes "not a valid .la


From: Rugxulo
Subject: Re: libtool 2.2.6 bug: CR/LF result (from sed?) causes "not a valid .la / .lo" errors [old Bash 2.05 bug, fixed]
Date: Sun, 21 Feb 2010 15:38:15 -0600

Hi,

   For the record, BRexx can be found here (he mostly develops on and
compiles for Linux these days, no surprise) although it's moot (see
below):

http://bnv.home.cern.ch/bnv/software/
ftp://ftp.gwdg.de/pub/languages/rexx/brexx


On Sun, Feb 21, 2010 at 9:22 AM, Ralf Wildenhues <address@hidden> wrote:
>
>> Anyways, it seems that libtool 2.2.6 (used by BRexx 2.1.8 and
>> presumably other stuff) doesn't like CR/LF .la .lo files, and it will
>> exit with a "not valid" error if found.
>
> Please provide a copy-and-paste of the full command that failed, plus
> all of its output.  libtool does not produce a "not valid" error message
> without any further details.  If it's a libtool command line, rerun it
> with --debug added as first argument to libtool, and send all of that
> output as well (gzip'ed is fine).

I did that, but I don't think you need it. It's Bash that's buggy
(specifically older versions of 2.05, apparently, before r2, although
2.04 works fine and was allegedly immune).

> Your description does not make it clear to me whether it's libtool or
> libltdl that fails.  I'm guessing though that one of the func_lalib_p
> or func_lalib_unsafe_p functions fails.  Does the command work if you
> replace the definition of func_lalib_unsafe_p in the generated libtool
> script with a call to
>  func_lalib_p "$@"
>
> ?

Yes, actually, replacing func_lalib_unsafe_p's contents with '
func_lalib_p "$@" ' does work (dunno why, though).

> It seems your shell does not cope well when reading scripts from text
> files with exec, a la
>  exec <text-file
>  read line
>  echo $line
>  exec <&-

When building BRexx 2.1.8, libtool was erroring out (causing Make to
quit), and I knew it was because it thought CR+LF wasn't valid. A
simple "dtou" would fix any .lo or .la file. So I (crazily?) thought
it was a libtool mistake. (My bad!)

But since I've tested more (old) shells, it seems I was wrong. The
shell indeed works, it's just my rebuild of Bash itself that didn't
(due to an old bug in 2.05b with "read" that has since been fixed).

http://groups.google.com/group/comp.os.msdos.djgpp/browse_frm/thread/f2875dfdc9c47034/c8d904b384841103?lnk=gst&q=announce+bash+release+2#c8d904b384841103

> Any chance you could run the Libtool testsuite on your system (see
> README for details)?

I doubt it. Back in the day, Libtool 1.5 was "ported" to DJGPP by
Richard Dawe. He got most of the tests to succeed but some were meant
to fail (no .so support except in unofficial DJELF fork), so he
skipped them. He is much more knowledgeable than I am, but he's more
focused on Linux these days, apparently. All of this AutoConf stuff
confuses me beyond measure, and my skills in *nix / POSIX shell
scripting are nil.

P.S. Sorry for wasting your time (though I wasted more than a few
hours on this myself, argh)!




reply via email to

[Prev in Thread] Current Thread [Next in Thread]