[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion 1.8.x on Solaris 10 x86

From: Philip Martin <philip_at_codematters.co.uk>
Date: Wed, 02 Aug 2017 17:42:37 +0100

Ian Mordey <ian.mordey_at_wandisco.com> writes:

> I first added --disable-nonportable-atomics to the configure and rebuilt
> APR. SVN fails in the same way.
>
> I tried running unsetting HAVE_ATOMIC_BUILTINS after configure but before
> running make and still get the same error..

I think the __sync symbols were originally GCC specific, although other
compilers may now provide them. My guess at present is that the SunCC
compiler doesn't provide them but APR thinks is does (although I suppose
the problem could be one of the other dependencies, zlib, openssl, etc.
making the mistake rather than APR).

Lets look at the symbols in APR object files:

  atomic/unix/builtin.o
  atomic/unix/mutex.o
  atomic/unix/solaris.o

You can run nm on those files to see which symbols they provide and
which are undefined. Only one of the files should have symbols, the
other two are effectively empty.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/nm.html

For the original build the file builtin.o is the one that should have
symbols. You should see various svn_atomic defined (T) and various
__sync undefined (U). nm should report no symbols for the other two
files.

For the --disable-nonportable-atomics build the apr_atomic symbols
should move to the mutex.o file, but there should no longer be any
reference to __sync symbols. builtin.o should have no symbols.

Finally for the build with USE_ATOMICS_GENERIC and HAVE_ATOMIC_BUILTINS
unset the apr_atomic symbols should move to solaris.o and there should
be no reference to __sync symbols. builtin.o should have no symbols.

Can you confirm that is what happens?

If the above is correct but the links are still failing with undefined
references to __sync symbols then that means that the link is not using
the APR you just built but is finding some other APR on the system (or
that the problem is one of the other dependencies using __sync symbols).

If you look at the failing link command:

  cd some/dir && libtool --mode=link --silent ...

you can execute the command manually but change --silent to --verbose

  (cd some/dir && libtool --mode=link --verbose ... )

where I added () so the cd only affects the one command. That will cause
libtool to print the exact command used to invoke the compiler. Then
you can execute that command manually but add the -# option which is the
compiler version of verbose according to
https://docs.oracle.com/cd/E19205-01/820-4180/man1/cc.1.html

That should tell you exactly how the linker is being invoked and which
paths are being searched for libraries.
 
You can also run nm on the libraries, rather than the object files, and
see if there are undefined references to __sync symbols. You could try
running nm on the other dependencies to see if the problem is one of
those libraries trying to use __sync symbols. You should be able to run
nm on the Subversion libraries and verify that they do not refer to
__sync symbols directly and that the problem is APR or one of the other
dependencies.

-- 
Philip
Received on 2017-08-02 18:42:52 CEST

This is an archived mail posted to the Subversion Dev mailing list.