Ian Mordey <ian.mor...@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
