Olaf Meeuwissen wrote:
> "Franz Bakan" <fbakan at gmx.net> writes:
>
>
>> Hi,
>>
>> After the latest modifications with the libtool stuff I now get this error:
>>
>> [snip]
>> make[1]: Entering directory `G:/src/432/sane-backends/backend'
>> sh ../libtool --silent --tag=CC --mode=link gcc -D__EMX__ -DOS2
>> -D__ST_MT_ERR
>> NO__ -fno-omit-frame-pointer -O2 -W -Wall -Wcast-align -Wcast-qual
>> -Wmissing-dec
>> larations -Wmissing-prototypes -Wpointer-arith -Wreturn-type
>> -Wstrict-prototypes
>> -pedantic -rpath '/usr/lib' -version-number 1:1:0 -Zexe -Zmtd
>> -D__ST_MT_ERRNO_
>> _ -s -o libsane.la -rpath /usr/lib libsane_la-dll-s.lo ../lib/liblib.la
>> libdll.
>> la sane_strstatus.lo ../sanei/sanei_init_debug.lo
>> ../sanei/sanei_constrain_value
>> .lo ../sanei/sanei_config.lo ../sanei/sanei_config2.lo ../sanei/sanei_usb.lo
>> ../
>> sanei/sanei_scsi.lo ../sanei/sanei_pv8630.lo ../sanei/sanei_pp.lo
>> ../sanei/sanei
>> _thread.lo ../sanei/sanei_lm983x.lo ../sanei/sanei_access.lo
>> ../sanei/sanei_net
>> .lo ../sanei/sanei_wire.lo ../sanei/sanei_codec_bin.lo
>> ../sanei/sanei_pa4s2.lo .
>> ./sanei/sanei_ab306.lo ../sanei/sanei_pio.lo ../sanei/sanei_tcp.lo
>> ../sanei/sane
>> i_udp.lo ../sanei/sanei_jpeg.lo -ldl -lm -ljpeg
>> libtool: link: CURRENT `' must be a nonnegative integer
>> libtool: link: `1:1:0' is not valid version information
>> make[1]: *** [libsane.la] Fehler 1
>> make[1]: Leaving directory `G:/src/432/sane-backends/backend'
>> make: *** [all-recursive] Fehler 1
>>
>> What does this mean?
>> What's CURRENT ?
>> What's a valid version information?
>>
I've found out some interesting facts... I've arrived at why its broke
but not sure I know the fix quite yet. I went back to a copy of CVS
that pre-dates my automake changes. When I look at output of make, I
see that "-rpath /path -version-number x:x:x" was never passed to
linker! Wonder how long thats been broke?
When I converted over to automake, I made sure the following original
rule was working:
libsane.la: dll.lo dll-s.lo $(EXTRA) $(addsuffix .lo,$(DLL_PRELOAD))
$(LIBOBJS)
@$(LIBTOOL) $(MLINK) $(CC) -o $@ $(LDFLAGS) $(BACKENDLIBS) $^ \
$(addsuffix .lo,$(DLL_PRELOAD_EXTRAS))
@LIBTOOL_LINK_EXTRA@ \
-rpath $(libdir) -version-number
$(V_MAJOR):$(V_MINOR):$(V_REV)
It looks like the rule wasn't working *before* my conversion under
Linux. Basically, everything starting from @LIBTOOL_LINK_EXTRA@ was not
being passed to libtool. I think its because of bug in configure.in:
dnl Windows/Cygwin needs this, else the library creation fails
dnl BeOS also needs this (why isnt it the default anyway ???)
if test "$ac_cv_header_windows_h" = "yes" -o
"$ac_cv_header_be_kernel_OS_h" = "y
es" ; then
LIBTOOL_LINK_EXTRA=-no-undefined
AC_SUBST(LIBTOOL_LINK_EXTRA)
fi
That AC_SUBST() should be outside the if() statement. As is, the
Makefile contains literally @LIBTOOL_LINK_EXTRA@ on anything but
Windows/BeOS and confuses; but doesn't crash; libtool. I noticed the
bug during review and fixed it without realizing the above behaviour was
occurring. Fix went into CVS along with backend/Makefile.am.
Before the bugfix and on OS/2 it would not see the -rpath or
-version-info flags. Now its seeing it.
Theoretically, if OS/2 is building shared libraries then it should
support -version-info. I don't think support shared libraries though
because on other apps I've worked on everyone tells me they add
"-no-undefined" for OS/2. I think thats affectively same as running
"./configure --disable-shared --enable-static".
Franz, can you try compiling as follows? If it works on OS/2 then I
know how to update configure to have it always work:
./configure LDFLAGS="-no-undefined"
make
Chris
