Re: 1 test ( tests/mdemo2-make.test ) fails on Solaris 10

[Ralf Wildenhues]

Hello,

* Dr. David Kirkby wrote on Sun, Jun 14, 2009 at 09:09:34PM CEST:
> I created a small script which redirected both stdout and stderr to
> the same file.
> 
> ./configure  > conf.log  2>&1
> make  > make.log 2>&1
> make check > make-check.log 2>&1
> make check -k TESTS="tests/mdemo-conf.test tests/mdemo-make.test \
> tests/mdemo-exec.test \
> tests/mdemo-inst.test tests/mdemo-unst.test tests/mdemo-dryrun.test \
> tests/mdemo2-conf.test tests/mdemo2-make.test tests/mdemo2-exec.test" \
> VERBOSE=yes > mdemo.log 2>&1
> 
> then I run it. Note there is a serious problem in the file mdemo.log, with
> 
> ../mdemo/.libs/libmlib.so: undefined reference to address@hidden'
> ../mdemo/.libs/libmlib.so: undefined reference to address@hidden'
> ../mdemo/.libs/libmlib.so: undefined reference to address@hidden'
> ../mdemo/.libs/libmlib.so: undefined reference to address@hidden'
> 
> I've noticed this exact same error message yesterday, or perhaps the
> day before. A Google search will show they have come up for years.
> In each case libtool has been used.

Yet before you, noone bothered to report it here, at least not that I
can remember.

> The reason sqlite was not building was that the link process when
> building a shared library had
> 
> -lpthread -lc
> 
> Changing the order to
> 
> -lc -lpthread
> 
> solved the problem, but I've no idea if that was possible to do in
> libtool anyway.

It is easily possible to avoid libtool from ever linking -lpthread on
Solaris 10, if that's what is universally desirable.  However,

- the mdemo does not link against libpthread at all, and your verbose
  test output shows no sign of pthread, so the test failure does not
  seem to be caused by this issue at all, but possibly by another,
  separate issue,

- if libpthread helps nothing except to cause problems (and to avoid a
  link failure for missing -lpthread), then why in the world did the
  Solaris developers not make libpthread.so an empty library, or at
  least one with symbol stub names consistent to that from libc?

- what do dlopen and friends have to do with libpthread anyway, not
  being listed in it?

Note that one reason I'm very reluctant to change the linking order here
is that virtually everywhere else (i.e., on other systems), it would
introduce rather than fix a bug.

> Note these 'undefined reference' messages with SUNW in the name have
> come up for years with different versions of gcc. In gcc 4.3.2 I
> don't see them, but I do see them in 4.4.0

Well, I don't see the testsuite failure in my test run on
sparc-sun-solaris2.10 wth GCC 4.2.4, but it uses Solaris ld not GNU ld.

What do I need to do in order to reproduce the issue with libpthread?
The Libtool testsuite should expose the bug we are trying to fix here,
and I would like to be able to see, or at least understand, the
underlying problem.  So far it merely looks like a GNU ld bug to me.
(Not saying that libtool shouldn't try to work around it, but it does
not look like a problem caused by libtool, only exposed by it.)

For the libmlib.so issue, can you try the following, to see whether we
should maybe omit adding -lc instead, and post all output from stdout
and stderr?

cd tests/mdemo
sed 's/^\(build_libtool_need_lc=\).*/\1no/' < libtool > libtool1
mv -f libtool1 libtool
./libtool --mode=clean rm -f libmlib.la
make
cd ../mdemo2
make

Thanks,
Ralf