[sane-devel] problems on OS/2

[Chris Bagwell]

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