Re: bash versus printf -exported_symbol on OSF

[Christian Cornelssen]

Hi,

On Tue, 14 Jan 2003, [iso-8859-2] Martin MOKREJ© wrote:

> No, it doesn't work. Actually, there's something more rotten in todays
> cvs!

(That's why I still use 1.4.3 with some workarounds for C++.)

Apparently some feature detections have had ignored failures,
resulting in some unexpectedly empty shell variables:

> ../libtool: test: : integer expression expected
> ../libtool: test: : integer expression expected
> using reloadable object file for export list...
>  -e "^[^_].*" ".libs/libgdk_pixbuf-2.0.exp" > ".libs/libgdk_pixbuf-2.0.expT"
> ../libtool: -e: command not found

(Presumably something like "test $num -gt 0" and "$grep -e ...")

> for i in `cat .libs/libgdk_pixbuf-2.0.exp`; do printf "-exported_symbol " >> 
> .libs/libgdk_pixbuf-2.0.so.200.200.0.exp; echo "$i" >> 
> .libs/libgdk_pixbuf-2.0.so.200.200.0.exp; done; echo "-hidden">> 
> .libs/libgdk_pixbuf-2.0.so.200.200.0.exp
> ../libtool: printf: illegal option: -e

Hey, that libtool is not the patched one!

After building the new libtool, you have to "libtoolize -f -c" your
package (where libtool is used), in order to regenerate its copy
of libtool.  (And then "aclocal", "autoconf", "automake -f -a -c", or
just "autoreconf -f -i").  Then reconfigure and rebuild.  The typical
risk taken with that is that the package may have been tuned for
autoconf-2.13 and thus be incompatible with later versions...

Regards,

Christian Cornelssen