Subversion 1.8.x on Solaris 10 x86

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Subversion 1.8.x on Solaris 10 x86

Ian Mordey
Hi there
Our Solaris 10 x86 build box blew up and I'm attempting to build a new one. I've got it building 1.9.6 fine but when I attempt anything 1.8.18 or 1.8.17 I get this error:

cd subversion/svn && /bin/bash /home/jenkins/SVN-Build/subversion-packaging/solaris/subversion-1.8.18/libtool --tag=CC --silent --mode=link suncc  -Werror=unknown-warning-option -I/opt/WANdisco/include -fast -xO5 -xunroll=20    -L/opt/WANdisco/lib -R/opt/WANdisco/lib  -L/opt/WANdisco/lib -L/opt/csw//lib -L/opt/WANdisco//lib  -rpath /opt/WANdisco/lib  -o svn  add-cmd.lo blame-cmd.lo cat-cmd.lo changelist-cmd.lo checkout-cmd.lo cl-conflicts.lo cleanup-cmd.lo commit-cmd.lo conflict-callbacks.lo copy-cmd.lo delete-cmd.lo deprecated.lo diff-cmd.lo export-cmd.lo file-merge.lo help-cmd.lo import-cmd.lo info-cmd.lo list-cmd.lo lock-cmd.lo log-cmd.lo merge-cmd.lo mergeinfo-cmd.lo mkdir-cmd.lo move-cmd.lo notify.lo patch-cmd.lo propdel-cmd.lo propedit-cmd.lo propget-cmd.lo proplist-cmd.lo props.lo propset-cmd.lo relocate-cmd.lo resolve-cmd.lo resolved-cmd.lo revert-cmd.lo status-cmd.lo status.lo svn.lo switch-cmd.lo unlock-cmd.lo update-cmd.lo upgrade-cmd.lo util.lo ../../subversion/libsvn_client/libsvn_client-1.la ../../subversion/libsvn_wc/libsvn_wc-1.la ../../subversion/libsvn_ra/libsvn_ra-1.la ../../subversion/libsvn_delta/libsvn_delta-1.la ../../subversion/libsvn_diff/libsvn_diff-1.la ../../subversion/libsvn_subr/libsvn_subr-1.la -L/opt/WANdisco/lib -laprutil-1 -L/opt/WANdisco/lib -lapr-1 -lsocket
ld: warning: file ../../subversion/libsvn_wc/.libs/libsvn_wc-1.so: linked to /home/jenkins/SVN-Build/subversion-packaging/solaris/subversion-1.8.18/subversion/libsvn_wc/.libs/libsvn_wc-1.so: attempted multiple inclusion of file
ld: warning: file ../../subversion/libsvn_ra/.libs/libsvn_ra-1.so: linked to /home/jenkins/SVN-Build/subversion-packaging/solaris/subversion-1.8.18/subversion/libsvn_ra/.libs/libsvn_ra-1.so: attempted multiple inclusion of file
ld: warning: file ../../subversion/libsvn_delta/.libs/libsvn_delta-1.so: linked to /home/jenkins/SVN-Build/subversion-packaging/solaris/subversion-1.8.18/subversion/libsvn_delta/.libs/libsvn_delta-1.so: attempted multiple inclusion of file
ld: warning: file ../../subversion/libsvn_diff/.libs/libsvn_diff-1.so: linked to /home/jenkins/SVN-Build/subversion-packaging/solaris/subversion-1.8.18/subversion/libsvn_diff/.libs/libsvn_diff-1.so: attempted multiple inclusion of file
ld: warning: file ../../subversion/libsvn_subr/.libs/libsvn_subr-1.so: linked to /home/jenkins/SVN-Build/subversion-packaging/solaris/subversion-1.8.18/subversion/libsvn_subr/.libs/libsvn_subr-1.so: attempted multiple inclusion of file
Undefined                       first referenced
 symbol                             in file
__sync_add_and_fetch                /home/jenkins/SVN-Build/subversion-packaging/solaris/subversion-1.8.18/subversion/libsvn_subr/.libs/libsvn_subr-1.so
__sync_val_compare_and_swap         /home/jenkins/SVN-Build/subversion-packaging/solaris/subversion-1.8.18/subversion/libsvn_subr/.libs/libsvn_subr-1.so
__sync_lock_test_and_set            /home/jenkins/SVN-Build/subversion-packaging/solaris/subversion-1.8.18/subversion/libsvn_subr/.libs/libsvn_subr-1.so
ld: fatal: symbol referencing errors. No output written to .libs/svn
*** Error code 2
make: Fatal error: Command failed for target `subversion/svn/svn'
+ fatal 'error compiling subversion'
+ echo '[FATAL]: error compiling subversion'
[FATAL]: error compiling subversion
+ exit -1


This is attempting to build with Oracle Developer Studio 12.6 and the following dependencies built:
apr-1.6.2
apr-util-1.6.0
db-6.2.32
expat-2.2.2
httpd-2.2.34
neon-0.30.2
openssl-1.0.2l
pcre-8.41
sqlite-autoconf-3200000
zlib-1.2.11

Any idea what's wrong?

Thanks
Ian
--
IAN MORDEY HEAD OF INFRASTRUCTURE


World Leader in Active Data Replication™
Find out more wandisco.com

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED

If this message was misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. If you are not the intended recipient, please notify us immediately and destroy the message without disclosing its contents to anyone. Any distribution, use or copying of this email or the information it contains by other than an intended recipient is unauthorized. The views and opinions expressed in this email message are the author's own and may not reflect the views and opinions of WANdisco, unless the author is authorized by WANdisco to express such views or opinions on its behalf. All email sent to or from this address is subject to electronic storage and review by WANdisco. Although WANdisco operates anti-virus programs, it does not accept responsibility for any damage whatsoever caused by viruses being passed.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Subversion 1.8.x on Solaris 10 x86

Philip Martin
Ian Mordey <[hidden email]> writes:

> Undefined                       first referenced
>  symbol                             in file
> __sync_add_and_fetch

Modern compilers usually provide fast "atomics" and most code will try
to use compiler atomics if possible.  Subversion itself relies on APR
for atomics so what matters is how you configured and built APR.  I am
surprised Subversion 1.8 and 1.9 are different.  Do they use the same
APR?  Is APR built the same way using the same compiler?

Looking at include/arch/unix/apr_arch_atomic.h in the APR build it
appears that there are three possible atomic implementations on Solaris:
1) generic, 2) builtin, 3) solaris.

From the error message your build appears to use 2) builtin, so I expect
you to have USE_ATOMICS_GENERIC unset and HAVE_ATOMIC_BUILTINS set.  If
you look at include/arch/unix/apr_private.h in your APR build you should
be able to confirm that.  APR's configure script controls both symbols.

Your compiler is not providing the functions required for 2) builtin to
work.  You can force the APR build to use 1) generic with the configure
option --disable-nonportable-atomics.  It might be better to get APR to
use 3) solaris by unsetting HAVE_ATOMIC_BUILTINS after configure and
before building.

It would be good to understand which atomics you are using, why APR
chooses the wrong ones, how we can fix APR to choose the right ones
automatically, and why 1.8 and 1.9 are different.

--
Philip
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Subversion 1.8.x on Solaris 10 x86

Ian Mordey
On Wed, Aug 2, 2017 at 11:23 AM Philip Martin <[hidden email]> wrote:
Ian Mordey <[hidden email]> writes:

> Undefined                       first referenced
>  symbol                             in file
> __sync_add_and_fetch

Modern compilers usually provide fast "atomics" and most code will try
to use compiler atomics if possible.  Subversion itself relies on APR
for atomics so what matters is how you configured and built APR.  I am
surprised Subversion 1.8 and 1.9 are different.  Do they use the same
APR?  Is APR built the same way using the same compiler?

Yup. APR 1.6.2 was configured with:
./configure CC=suncc CXX=sunCC \
    CFLAGS="-I/opt/WANdisco/include" \
    CXXFLAGS="-I/opt/WANdisco/include" \
    LDFLAGS="-R/opt/WANdisco/lib -L/opt/WANdisco/lib" \
    --prefix=/opt/WANdisco \
    --enable-shared --enable-static

 

Looking at include/arch/unix/apr_arch_atomic.h in the APR build it
appears that there are three possible atomic implementations on Solaris:
1) generic, 2) builtin, 3) solaris.

From the error message your build appears to use 2) builtin, so I expect
you to have USE_ATOMICS_GENERIC unset and HAVE_ATOMIC_BUILTINS set.  If
you look at include/arch/unix/apr_private.h in your APR build you should
be able to confirm that.  APR's configure script controls both symbols.

Your compiler is not providing the functions required for 2) builtin to
work.  You can force the APR build to use 1) generic with the configure
option --disable-nonportable-atomics.  It might be better to get APR to
use 3) solaris by unsetting HAVE_ATOMIC_BUILTINS after configure and
before building.

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..

Finally I tried downgrading APR  and APU to 1.5.x versions. Still the same issue.
 

It would be good to understand which atomics you are using, why APR
chooses the wrong ones, how we can fix APR to choose the right ones
automatically, and why 1.8 and 1.9 are different.

With configure from above I get:
#define HAVE_ATOMIC_BUILTINS 1
/* #undef USE_ATOMICS_GENERIC */

With --disable-nonportable-atomics I get:
#define HAVE_ATOMIC_BUILTINS 1
#define USE_ATOMICS_GENERIC 1


--
Philip

Thanks
Ian 
--
IAN MORDEY HEAD OF INFRASTRUCTURE


World Leader in Active Data Replication™
Find out more wandisco.com

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED

If this message was misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. If you are not the intended recipient, please notify us immediately and destroy the message without disclosing its contents to anyone. Any distribution, use or copying of this email or the information it contains by other than an intended recipient is unauthorized. The views and opinions expressed in this email message are the author's own and may not reflect the views and opinions of WANdisco, unless the author is authorized by WANdisco to express such views or opinions on its behalf. All email sent to or from this address is subject to electronic storage and review by WANdisco. Although WANdisco operates anti-virus programs, it does not accept responsibility for any damage whatsoever caused by viruses being passed.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Subversion 1.8.x on Solaris 10 x86

Philip Martin
Ian Mordey <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Subversion 1.8.x on Solaris 10 x86

Ian Mordey

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?
 
So with USE_ATOMICS_GENERIC I have this:
solaris.o:

[Index]   Value      Size      Type  Bind  Other Shndx   Name



mutex.o:

[Index]   Value      Size      Type  Bind  Other Shndx   Name

[33]    |         0|         0|FUNC |GLOB |0    |UNDEF  |abort
[37]    |       512|       107|FUNC |GLOB |0    |2      |apr_atomic_add32
[41]    |       928|       110|FUNC |GLOB |0    |2      |apr_atomic_cas32
[43]    |      1152|        96|FUNC |GLOB |0    |2      |apr_atomic_casptr
[40]    |       800|       107|FUNC |GLOB |0    |2      |apr_atomic_dec32
[39]    |       736|        35|FUNC |GLOB |0    |2      |apr_atomic_inc32
[27]    |        64|       176|FUNC |GLOB |0    |2      |apr_atomic_init
[34]    |       384|        35|FUNC |GLOB |0    |2      |apr_atomic_read32
[35]    |       448|        63|FUNC |GLOB |0    |2      |apr_atomic_set32
[38]    |       640|        74|FUNC |GLOB |0    |2      |apr_atomic_sub32
[42]    |      1056|        96|FUNC |GLOB |0    |2      |apr_atomic_xchg32
[44]    |      1248|        88|FUNC |GLOB |0    |2      |apr_atomic_xchgptr
[28]    |         0|         0|FUNC |GLOB |0    |UNDEF  |apr_palloc
[29]    |         0|         0|FUNC |GLOB |0    |UNDEF  |apr_pool_cleanup_null
[30]    |         0|         0|FUNC |GLOB |0    |UNDEF  |apr_pool_cleanup_register
[31]    |         0|         0|FUNC |GLOB |0    |UNDEF  |apr_thread_mutex_create
[32]    |         0|         0|FUNC |GLOB |0    |UNDEF  |apr_thread_mutex_lock
[36]    |         0|         0|FUNC |GLOB |0    |UNDEF  |apr_thread_mutex_unlock


builtins.o:

[Index]   Value      Size      Type  Bind  Other Shndx   Name

-bash-3.2# for i in solaris.o mutex.o builtins.o ; do nm -u $i; done


Undefined symbols from solaris.o:



Undefined symbols from mutex.o:

    abort
    apr_palloc
    apr_pool_cleanup_null
    apr_pool_cleanup_register
    apr_thread_mutex_create
    apr_thread_mutex_lock
    apr_thread_mutex_unlock


Undefined symbols from builtins.o:

With the default build I have this:
Undefined symbols from solaris.o:



Undefined symbols from mutex.o:



Undefined symbols from builtins.o:

bash-3.2# for i in solaris.o mutex.o builtins.o ; do nm -g $i; done


solaris.o:

[Index]   Value      Size      Type  Bind  Other Shndx   Name



mutex.o:

[Index]   Value      Size      Type  Bind  Other Shndx   Name



builtins.o:

[Index]   Value      Size      Type  Bind  Other Shndx   Name

[27]    |       128|        30|FUNC |GLOB |0    |2      |apr_atomic_add32
[31]    |       288|       100|FUNC |GLOB |0    |2      |apr_atomic_cas32
[33]    |       480|        88|FUNC |GLOB |0    |2      |apr_atomic_casptr
[30]    |       224|        35|FUNC |GLOB |0    |2      |apr_atomic_dec32
[29]    |       192|        32|FUNC |GLOB |0    |2      |apr_atomic_inc32
[24]    |         0|        25|FUNC |GLOB |0    |2      |apr_atomic_init
[25]    |        32|        35|FUNC |GLOB |0    |2      |apr_atomic_read32
[26]    |        96|        13|FUNC |GLOB |0    |2      |apr_atomic_set32
[28]    |       160|        17|FUNC |GLOB |0    |2      |apr_atomic_sub32
[32]    |       416|        55|FUNC |GLOB |0    |2      |apr_atomic_xchg32
[34]    |       576|        55|FUNC |GLOB |0    |2      |apr_atomic_xchgptr

So I don't see any __sync symbols anywhere..

Does this mean they're in another dependency somewhere?

Cheers
Ian
--
IAN MORDEY HEAD OF INFRASTRUCTURE


World Leader in Active Data Replication™
Find out more wandisco.com

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED

If this message was misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. If you are not the intended recipient, please notify us immediately and destroy the message without disclosing its contents to anyone. Any distribution, use or copying of this email or the information it contains by other than an intended recipient is unauthorized. The views and opinions expressed in this email message are the author's own and may not reflect the views and opinions of WANdisco, unless the author is authorized by WANdisco to express such views or opinions on its behalf. All email sent to or from this address is subject to electronic storage and review by WANdisco. Although WANdisco operates anti-virus programs, it does not accept responsibility for any damage whatsoever caused by viruses being passed.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Subversion 1.8.x on Solaris 10 x86

Philip Martin
Ian Mordey <[hidden email]> writes:

> So I don't see any __sync symbols anywhere..

Yes, that is what is expected for an APR_ATOMICS_GENERIC build.

> Does this mean they're in another dependency somewhere?

There are several options, including:

  - the __sync symbols are in one of the dependencies, zlib, openssl,
    etc.

  - the link is not picking up the APR library you just built but is
    picking up an APR installed somewhere else on the system and that
    APR refers to the __sync symbols.

  - the __sync symbols are in one of the Subversion libraries, but this
    is not supposed to happen.

Looking at your first email again it does appear that Subversion's
libsvn_subr might be the problem which is odd because Suversion is
supposed to use APR.  I think you are building sqlite3 as part of
Subversion, so there will be sqlite code in Subversion's libsvn_subr but
I only see __sync_syncronize in sqlite3.c.

You can run nm on the Subversion object files, e.g:

   nm subversion/libsvn_subr/*.o

You can run nm on the various libraries to identify which library has
the references to the __sync symbols:

  nm subversion/libsvn_subr/.libs/libsvn_subr-1.a
  nm /opt/WANdisco/lib/libssl1.so

--
Philip
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Subversion 1.8.x on Solaris 10 x86

Ian Mordey





You can run nm on the Subversion object files, e.g:

   nm subversion/libsvn_subr/*.o

Aha! Found it!

nm subversion/libsvn_subr/named_atomic.o
subversion/libsvn_subr/named_atomic.o:

[Index]   Value      Size      Type  Bind  Other Shndx   Name

[29]    |         0|         0|SECT |LOCL |0    |17     |
[2]     |         0|         0|SECT |LOCL |0    |2      |
[28]    |         0|         0|SECT |LOCL |0    |16     |
[27]    |         0|         0|SECT |LOCL |0    |14     |
[26]    |         0|         0|SECT |LOCL |0    |15     |
[25]    |         0|         0|SECT |LOCL |0    |13     |
[30]    |         0|         0|SECT |LOCL |0    |18     |
[16]    |         0|         0|SECT |LOCL |0    |7      |
[18]    |         0|         0|SECT |LOCL |0    |8      |
[19]    |         0|         0|SECT |LOCL |0    |9      |
[20]    |         0|         0|SECT |LOCL |0    |10     |
[21]    |         0|         0|SECT |LOCL |0    |11     |
[23]    |         0|         0|SECT |LOCL |0    |12     |
[10]    |         0|         0|SECT |LOCL |0    |3      |
[11]    |         0|         0|SECT |LOCL |0    |4      |
[12]    |         0|         0|SECT |LOCL |0    |5      |
[14]    |         0|         0|SECT |LOCL |0    |6      |
[22]    |         0|         0|NOTY |LOCL |0    |11     |Bbss.bss
[24]    |         0|         0|OBJT |LOCL |0    |12     |Blbss.lbss
[13]    |         0|         0|NOTY |LOCL |0    |5      |Ddata.data
[9]     |         0|         0|OBJT |LOCL |0    |8      |Dldata.ldata
[8]     |         0|         0|OBJT |LOCL |0    |9      |Dlrodata.lrodata
[17]    |         0|         0|NOTY |LOCL |0    |7      |Dpicdata.picdata
[15]    |         0|         0|NOTY |LOCL |0    |6      |Drodata.rodata
[66]    |         0|         0|FUNC |GLOB |0    |UNDEF  |__sync_add_and_fetch
[64]    |         0|         0|FUNC |GLOB |0    |UNDEF  |__sync_lock_test_and_set
[68]    |         0|         0|FUNC |GLOB |0    |UNDEF  |__sync_val_compare_and_swap
[60]    |         0|         0|FUNC |GLOB |0    |UNDEF  |apr_atomic_read32
[61]    |         0|         0|FUNC |GLOB |0    |UNDEF  |apr_atomic_set32
[33]    |         0|         0|FUNC |GLOB |0    |UNDEF  |apr_file_close
[34]    |         0|         0|FUNC |GLOB |0    |UNDEF  |apr_file_name_get
[35]    |         0|         0|FUNC |GLOB |0    |UNDEF  |apr_file_remove
[50]    |         0|         0|FUNC |GLOB |0    |UNDEF  |apr_mmap_create
[39]    |         0|         0|FUNC |GLOB |0    |UNDEF  |apr_palloc
[43]    |         0|         0|FUNC |GLOB |0    |UNDEF  |apr_pool_cleanup_null
[44]    |         0|         0|FUNC |GLOB |0    |UNDEF  |apr_pool_cleanup_register
[51]    |         0|         0|FUNC |GLOB |0    |UNDEF  |apr_pool_destroy
[40]    |         0|         0|FUNC |GLOB |0    |UNDEF  |apr_pstrcat
[5]     |        64|        81|FUNC |LOCL |0    |2      |delete_lock_file
[54]    |         0|         0|FUNC |GLOB |0    |UNDEF  |dgettext
[3]     |         0|        38|FUNC |LOCL |0    |2      |init_thread_mutex
[7]     |         0|         4|OBJT |LOCL |0    |5      |mutex_initialized
[1]     |         0|         0|FILE |LOCL |0    |ABS    |named_atomic.c
[6]     |       160|        53|FUNC |LOCL |0    |2      |return_atomic
[41]    |         0|         0|FUNC |GLOB |0    |UNDEF  |svn_atomic__init_once
[57]    |      1056|       105|FUNC |GLOB |0    |2      |svn_atomic_namespace__cleanup
[38]    |       288|       741|FUNC |GLOB |0    |2      |svn_atomic_namespace__create
[53]    |         0|         0|FUNC |GLOB |0    |UNDEF  |svn_error_compose_create
[56]    |         0|         0|FUNC |GLOB |0    |UNDEF  |svn_error_create
[55]    |         0|         0|FUNC |GLOB |0    |UNDEF  |svn_error_createf
[42]    |         0|         0|FUNC |GLOB |0    |UNDEF  |svn_io_file_open
[49]    |         0|         0|FUNC |GLOB |0    |UNDEF  |svn_io_file_write_full
[46]    |         0|         0|FUNC |GLOB |0    |UNDEF  |svn_io_lock_open_file
[58]    |         0|         0|FUNC |GLOB |0    |UNDEF  |svn_io_remove_file2
[48]    |         0|         0|FUNC |GLOB |0    |UNDEF  |svn_io_stat
[52]    |         0|         0|FUNC |GLOB |0    |UNDEF  |svn_io_unlock_open_file
[32]    |         0|         0|FUNC |GLOB |0    |UNDEF  |svn_mutex__init
[45]    |         0|         0|FUNC |GLOB |0    |UNDEF  |svn_mutex__lock
[47]    |         0|         0|FUNC |GLOB |0    |UNDEF  |svn_mutex__unlock
[65]    |      2656|       115|FUNC |GLOB |0    |2      |svn_named_atomic__add
[67]    |      2784|       131|FUNC |GLOB |0    |2      |svn_named_atomic__cmpxchg
[59]    |      1184|      1245|FUNC |GLOB |0    |2      |svn_named_atomic__get
[37]    |       256|         6|FUNC |GLOB |0    |2      |svn_named_atomic__is_efficient
[36]    |       224|         6|FUNC |GLOB |0    |2      |svn_named_atomic__is_supported
[62]    |      2432|        94|FUNC |GLOB |0    |2      |svn_named_atomic__read
[63]    |      2528|       115|FUNC |GLOB |0    |2      |svn_named_atomic__write
[31]    |         0|         0|FUNC |GLOB |0    |UNDEF  |svn_pool_create_ex
[4]     |         4|         4|OBJT |LOCL |0    |5      |thread_mutex

subversion/libsvn_subr/named_atomic.o doesn't exist in 1.9.6 which explains why that built and 1.8 doesn't..

Still doesn't explain why 1.8.17 built fine on my old Solaris 10 x86 box did though..

Cheers


You can run nm on the various libraries to identify which library has
the references to the __sync symbols:

  nm subversion/libsvn_subr/.libs/libsvn_subr-1.a
  nm /opt/WANdisco/lib/libssl1.so

--
Philip
--
IAN MORDEY HEAD OF INFRASTRUCTURE


World Leader in Active Data Replication™
Find out more wandisco.com

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED

If this message was misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. If you are not the intended recipient, please notify us immediately and destroy the message without disclosing its contents to anyone. Any distribution, use or copying of this email or the information it contains by other than an intended recipient is unauthorized. The views and opinions expressed in this email message are the author's own and may not reflect the views and opinions of WANdisco, unless the author is authorized by WANdisco to express such views or opinions on its behalf. All email sent to or from this address is subject to electronic storage and review by WANdisco. Although WANdisco operates anti-virus programs, it does not accept responsibility for any damage whatsoever caused by viruses being passed.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Subversion 1.8.x on Solaris 10 x86

Philip Martin
Ian Mordey <[hidden email]> writes:

> Aha! Found it!
>
> nm subversion/libsvn_subr/named_atomic.o
> subversion/libsvn_subr/named_atomic.o:

> subversion/libsvn_subr/named_atomic.o doesn't exist in 1.9.6 which explains
> why that built and 1.8 doesn't..

I'd forgotten about that one :-(

Looks like you need to unset SVN_HAS_ATOMIC_BUILTINS in

   subversion/svn_private_config.h

That file is generated by configure which is supposed to detect the
presence/absence of the builtins but for some reason the detection is
broken.  Edit svn_private_config.h after running configure and set
SVN_HAS_ATOMIC_BUILTINS to 0, or remove the line altogether -- that
should cause the fallback code to be used.

> Still doesn't explain why 1.8.17 built fine on my old Solaris 10 x86 box
> did though..

Perhaps you used gcc rather than suncc?

--
Philip
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Subversion 1.8.x on Solaris 10 x86

Ian Mordey

Looks like you need to unset SVN_HAS_ATOMIC_BUILTINS in

   subversion/svn_private_config.h

Awesome. It looks like it's compiling now. 
 
Perhaps you used gcc rather than suncc?
 
Nope.. It's always been suncc but it was a much, much older version so maybe the detection worked on that old version but not the latest?

Thanks very much for your assistance. If you require any further info/tests running please let me know and I'll sort it out.

Cheers
Ian

--
IAN MORDEY HEAD OF INFRASTRUCTURE


World Leader in Active Data Replication™
Find out more wandisco.com

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED

If this message was misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. If you are not the intended recipient, please notify us immediately and destroy the message without disclosing its contents to anyone. Any distribution, use or copying of this email or the information it contains by other than an intended recipient is unauthorized. The views and opinions expressed in this email message are the author's own and may not reflect the views and opinions of WANdisco, unless the author is authorized by WANdisco to express such views or opinions on its behalf. All email sent to or from this address is subject to electronic storage and review by WANdisco. Although WANdisco operates anti-virus programs, it does not accept responsibility for any damage whatsoever caused by viruses being passed.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Subversion 1.8.x on Solaris 10 x86

Philip Martin
Ian Mordey <[hidden email]> writes:

> Thanks very much for your assistance. If you require any further info/tests
> running please let me know and I'll sort it out.

Subversion 1.8 has regression tests for the atomic code:

   make check TESTS=subversion/tests/libsvn_subr/named_atomic-test

It would be good it you could verify that the tests pass.

These tests also get run if you run any of the full Subversion
regression tests, things like:

   make check PARALLEL=1 CLEANUP=1               # file:// URLs
   make check PARALLEL=1 CLEANUP=1 FS_TYPE=bdb   # BDB repositories
   make davautocheck PARALLEL=1 CLEANUP=1        # svn:// URLs
   make svnserveautocheck PARALLEL=1 CLEANUP=1   # http:// URLs

--
Philip
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Subversion 1.8.x on Solaris 10 x86

Philip Martin
In reply to this post by Ian Mordey
Ian Mordey <[hidden email]> writes:

> Thanks very much for your assistance. If you require any further info/tests
> running please let me know and I'll sort it out.

configure attempts to detect the builtin atomics by building and running
the following code:

int main()
{
      unsigned long long val = 1010, tmp, *mem = &val;

      if (__sync_fetch_and_add(&val, 1010) != 1010 || val != 2020)
          return 1;

      tmp = val;

      if (__sync_fetch_and_sub(mem, 1010) != tmp || val != 1010)
          return 1;

      if (__sync_sub_and_fetch(&val, 1010) != 0 || val != 0)
          return 1;

      tmp = 3030;

      if (__sync_val_compare_and_swap(mem, 0, tmp) != 0 || val != tmp)
          return 1;

      if (__sync_lock_test_and_set(&val, 4040) != 3030)
          return 1;

      mem = &tmp;

      if (__sync_val_compare_and_swap(&mem, &tmp, &val) != &tmp)
          return 1;

      __sync_synchronize();

      if (mem != &val)
          return 1;

      return 0;
}

So something like:

   suncc -o conftest conftest.c
   ./conftest
   echo $?

with whatever other optimisation flags you pass to cc.  Does that
program compile and run?  I'd expect it to fail.  Do you see the failure
in config.log.

--
Philip
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Subversion 1.8.x on Solaris 10 x86

Ian Mordey
In reply to this post by Ian Mordey


Awesome. It looks like it's compiling now. 

I spoke too soon.. Got another compiler error on gnome-keyring. Again, this works fine on 1.9.x:

bash-3.2# suncc -std=c90 -DSOLARIS2=10 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_LARGEFILE64_SOURCE -Werror=unknown-warning-option -I/opt/WANdisco/include -fast -xO5 -xunroll=20 -I./subversion/include -I./subversion -I/opt/WANdisco/include/apr-1 -I/opt/WANdisco/include/apr-1 -I/opt/WANdisco/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gnome-keyring-1 -I/opt/WANdisco/include/serf-1 -I/opt/WANdisco/include -I/opt/WANdisco//include -c subversion/libsvn_auth_gnome_keyring/gnome_keyring.c  -KPIC -DPIC -o subversion/libsvn_auth_gnome_keyring/.libs/gnome_keyring.o
"/usr/include/glib-2.0/glib/gutils.h", line 208: syntax error before or at: gint
"/usr/include/glib-2.0/glib/gutils.h", line 210: syntax error before or at: gint
"/usr/include/glib-2.0/glib/gutils.h", line 212: syntax error before or at: guint
"/usr/include/glib-2.0/glib/gutils.h", line 223: syntax error before or at: void
"/usr/include/glib-2.0/glib/gutils.h", line 225: syntax error before or at: gpointer
"/usr/include/glib-2.0/glib/gutils.h", line 226: syntax error before or at: gpointer
"/usr/include/glib-2.0/glib/gutils.h", line 227: syntax error before or at: guint
"/usr/include/glib-2.0/glib/gutils.h", line 232: syntax error before or at: gint
"/usr/include/glib-2.0/glib/gutils.h", line 245: syntax error before or at: gint
"/usr/include/glib-2.0/glib/gutils.h", line 260: syntax error before or at: guint
"/usr/include/glib-2.0/glib/gutils.h", line 273: syntax error before or at: void
"/usr/include/glib-2.0/glib/gutils.h", line 282: syntax error before or at: gpointer
"/usr/include/glib-2.0/glib/gutils.h", line 299: syntax error before or at: gpointer
"/usr/include/glib-2.0/glib/gutils.h", line 308: syntax error before or at: guint
"/usr/include/glib-2.0/glib/gstring.h", line 121: syntax error before or at: GString
"/usr/include/glib-2.0/glib/gmessages.h", line 114: invalid token in #define macro parameters: ...
"/usr/include/glib-2.0/glib/gmessages.h", line 117: invalid token in #define macro parameters: ...
"/usr/include/glib-2.0/glib/gmessages.h", line 120: invalid token in #define macro parameters: ...
"/usr/include/glib-2.0/glib/gmessages.h", line 123: invalid token in #define macro parameters: ...
"subversion/libsvn_auth_gnome_keyring/gnome_keyring.c", line 125: warning: assignment type mismatch:
        pointer to function(pointer to pointer to char, pointer to const char, pointer to void, pointer to struct apr_pool_t {}) returning pointer to struct svn_error_t {int apr_err, pointer to const char message, pointer to struct svn_error_t {..} child, pointer to struct apr_pool_t {..} pool, pointer to const char file, long line} "=" pointer to void
cc: acomp failed for subversion/libsvn_auth_gnome_keyring/gnome_keyring.c

Any ideas on this one?

Cheers
Ian

 
 
Perhaps you used gcc rather than suncc?
 
Nope.. It's always been suncc but it was a much, much older version so maybe the detection worked on that old version but not the latest?

Thanks very much for your assistance. If you require any further info/tests running please let me know and I'll sort it out.

Cheers
Ian

--
IAN MORDEY HEAD OF INFRASTRUCTURE

--
IAN MORDEY HEAD OF INFRASTRUCTURE


World Leader in Active Data Replication™
Find out more wandisco.com

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED

If this message was misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. If you are not the intended recipient, please notify us immediately and destroy the message without disclosing its contents to anyone. Any distribution, use or copying of this email or the information it contains by other than an intended recipient is unauthorized. The views and opinions expressed in this email message are the author's own and may not reflect the views and opinions of WANdisco, unless the author is authorized by WANdisco to express such views or opinions on its behalf. All email sent to or from this address is subject to electronic storage and review by WANdisco. Although WANdisco operates anti-virus programs, it does not accept responsibility for any damage whatsoever caused by viruses being passed.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Subversion 1.8.x on Solaris 10 x86

Philip Martin
Ian Mordey <[hidden email]> writes:

> bash-3.2# suncc -std=c90 -DSOLARIS2=10 -D_POSIX_PTHREAD_SEMANTICS
> -D_REENTRANT -D_LARGEFILE64_SOURCE -Werror=unknown-warning-option
> -I/opt/WANdisco/include -fast -xO5 -xunroll=20 -I./subversion/include
> -I./subversion -I/opt/WANdisco/include/apr-1 -I/opt/WANdisco/include/apr-1
> -I/opt/WANdisco/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
> -I/usr/include/gnome-keyring-1 -I/opt/WANdisco/include/serf-1
> -I/opt/WANdisco/include -I/opt/WANdisco//include -c
> subversion/libsvn_auth_gnome_keyring/gnome_keyring.c  -KPIC -DPIC -o
> subversion/libsvn_auth_gnome_keyring/.libs/gnome_keyring.o
> "/usr/include/glib-2.0/glib/gutils.h", line 208: syntax error before or at:
> gint
> "/usr/include/glib-2.0/glib/gutils.h", line 210: syntax error before or at:
> gint
> "/usr/include/glib-2.0/glib/gutils.h", line 212: syntax error before or at:
> guint
> "/usr/include/glib-2.0/glib/gutils.h", line 223: syntax error before or at:
> void
> "/usr/include/glib-2.0/glib/gutils.h", line 225: syntax error before or at:
> gpointer
> "/usr/include/glib-2.0/glib/gutils.h", line 226: syntax error before or at:
> gpointer
> "/usr/include/glib-2.0/glib/gutils.h", line 227: syntax error before or at:
> guint
> "/usr/include/glib-2.0/glib/gutils.h", line 232: syntax error before or at:
> gint
> "/usr/include/glib-2.0/glib/gutils.h", line 245: syntax error before or at:
> gint
> "/usr/include/glib-2.0/glib/gutils.h", line 260: syntax error before or at:
> guint
> "/usr/include/glib-2.0/glib/gutils.h", line 273: syntax error before or at:
> void
> "/usr/include/glib-2.0/glib/gutils.h", line 282: syntax error before or at:
> gpointer
> "/usr/include/glib-2.0/glib/gutils.h", line 299: syntax error before or at:
> gpointer
> "/usr/include/glib-2.0/glib/gutils.h", line 308: syntax error before or at:
> guint
> "/usr/include/glib-2.0/glib/gstring.h", line 121: syntax error before or
> at: GString
> "/usr/include/glib-2.0/glib/gmessages.h", line 114: invalid token in
> #define macro parameters: ...
> "/usr/include/glib-2.0/glib/gmessages.h", line 117: invalid token in
> #define macro parameters: ...
> "/usr/include/glib-2.0/glib/gmessages.h", line 120: invalid token in
> #define macro parameters: ...
> "/usr/include/glib-2.0/glib/gmessages.h", line 123: invalid token in
> #define macro parameters: ...


The types gint, guint should be defined in gtypes.h but the cause of the
error message may not be use of type itself but something earlier.  What
do the lines around 208 in gutils.h look like? And 121 in gstring.h and
114 in gmessages.h.  Is there something common between those bits of the
files?

Another option is to run the compile command manually but change '-c' to
'-E', remove '-o subversion/libsvn_auth_gnome_keyring/gnome_keyring.o',
and redirect stdout to a file.  That gives us the preprocessed source
with all the includes resolved (probably quite a big file).

--
Philip
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Subversion 1.8.x on Solaris 10 x86

Ian Mordey


The types gint, guint should be defined in gtypes.h but the cause of the
error message may not be use of type itself but something earlier.  What
do the lines around 208 in gutils.h look like? And 121 in gstring.h and
114 in gmessages.h.  Is there something common between those bits of the
files?
Not that I can spot:
gutils.h
G_INLINE_FUNC gint      g_bit_nth_lsf (gulong  mask,
                                       gint    nth_bit);
G_INLINE_FUNC gint      g_bit_nth_msf (gulong  mask,
                                       gint    nth_bit);
G_INLINE_FUNC guint     g_bit_storage (gulong  number);

gstring.h
#ifdef G_CAN_INLINE
static inline GString*
g_string_append_c_inline (GString *gstring,
                          gchar    c)
{

gmessages.h
#ifdef G_HAVE_ISO_VARARGS
#define g_error(...)    g_log (G_LOG_DOMAIN,         \
                               G_LOG_LEVEL_ERROR,    \
                               __VA_ARGS__)
#define g_message(...)  g_log (G_LOG_DOMAIN,         \
                               G_LOG_LEVEL_MESSAGE,  \
                               __VA_ARGS__)
#define g_critical(...) g_log (G_LOG_DOMAIN,         \
                               G_LOG_LEVEL_CRITICAL, \
                               __VA_ARGS__)
#define g_warning(...)  g_log (G_LOG_DOMAIN,         \
                               G_LOG_LEVEL_WARNING,  \
                               __VA_ARGS__)
#elif defined(G_HAVE_GNUC_VARARGS)r 


Another option is to run the compile command manually but change '-c' to
'-E', remove '-o subversion/libsvn_auth_gnome_keyring/gnome_keyring.o',
and redirect stdout to a file.  That gives us the preprocessed source
with all the includes resolved (probably quite a big file).
It is quite big! Here you go:

Thanks
Ian

 

--
Philip
--
IAN MORDEY HEAD OF INFRASTRUCTURE


World Leader in Active Data Replication™
Find out more wandisco.com

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED

If this message was misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. If you are not the intended recipient, please notify us immediately and destroy the message without disclosing its contents to anyone. Any distribution, use or copying of this email or the information it contains by other than an intended recipient is unauthorized. The views and opinions expressed in this email message are the author's own and may not reflect the views and opinions of WANdisco, unless the author is authorized by WANdisco to express such views or opinions on its behalf. All email sent to or from this address is subject to electronic storage and review by WANdisco. Although WANdisco operates anti-virus programs, it does not accept responsibility for any damage whatsoever caused by viruses being passed.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Subversion 1.8.x on Solaris 10 x86

Philip Martin
Ian Mordey <[hidden email]> writes:

> Not that I can spot:
> gutils.h
> G_INLINE_FUNC gint      g_bit_nth_lsf (gulong  mask,
>                                        gint    nth_bit);
> G_INLINE_FUNC gint      g_bit_nth_msf (gulong  mask,
>                                        gint    nth_bit);
> G_INLINE_FUNC guint     g_bit_storage (gulong  number);
>
> gstring.h
> #ifdef G_CAN_INLINE
> static inline GString*
> g_string_append_c_inline (GString *gstring,
>                           gchar    c)
> {
>
> gmessages.h
> #ifdef G_HAVE_ISO_VARARGS
> #define g_error(...)    g_log (G_LOG_DOMAIN,         \
>                                G_LOG_LEVEL_ERROR,    \
>                                __VA_ARGS__)
> #define g_message(...)  g_log (G_LOG_DOMAIN,         \
>                                G_LOG_LEVEL_MESSAGE,  \
>                                __VA_ARGS__)
> #define g_critical(...) g_log (G_LOG_DOMAIN,         \
>                                G_LOG_LEVEL_CRITICAL, \
>                                __VA_ARGS__)
> #define g_warning(...)  g_log (G_LOG_DOMAIN,         \
>                                G_LOG_LEVEL_WARNING,  \
>                                __VA_ARGS__)
> #elif defined(G_HAVE_GNUC_VARARGS)r
>
>
>> Another option is to run the compile command manually but change '-c' to
>> '-E', remove '-o subversion/libsvn_auth_gnome_keyring/gnome_keyring.o',
>> and redirect stdout to a file.  That gives us the preprocessed source
>> with all the includes resolved (probably quite a big file).
>>
> It is quite big! Here you go:
> https://pastebin.com/HhvEZFRq

The problem is that the header files do not appear to work with the
compiler option -std=c90.  The problems: G_INLINE_FUNC is expanding to
"static inline", G_CAN_INLINE is allowing "static inline" and
G_HAVE_ISO_VARARGS is allowing ... in macros. None of those are
supported with -std=c90.

Also, the compiler error messages are poor.

I think the 1.9 build that works also passes -std=c90, it certainly does
on my machine here.  If I am correct then the glib headers have compiler
feature detection but it is broken for the 1.8 build.  I don't know what
would break it, but if you can work out what is different between 1.8
and 1.9 I would be interested, maybe we can fix it.

It would be good to work out why -std=c90 is broken but you can probably
fix the build by forcing -std=c99.  Either build using:

   make EXTRA_CFLAGS=-std=c99

or configure using

   CFLAGS=-std=c99 ./configure ...

--
Philip
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Subversion 1.8.x on Solaris 10 x86

Ian Mordey

It would be good to work out why -std=c90 is broken but you can probably
fix the build by forcing -std=c99.  Either build using:

   make EXTRA_CFLAGS=-std=c99

or configure using

   CFLAGS=-std=c99 ./configure ...

That's fixed it. Thanks very much. I'll have a look at the differences next week.

Cheers
 
--
IAN MORDEY HEAD OF INFRASTRUCTURE


World Leader in Active Data Replication™
Find out more wandisco.com

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED

If this message was misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. If you are not the intended recipient, please notify us immediately and destroy the message without disclosing its contents to anyone. Any distribution, use or copying of this email or the information it contains by other than an intended recipient is unauthorized. The views and opinions expressed in this email message are the author's own and may not reflect the views and opinions of WANdisco, unless the author is authorized by WANdisco to express such views or opinions on its behalf. All email sent to or from this address is subject to electronic storage and review by WANdisco. Although WANdisco operates anti-virus programs, it does not accept responsibility for any damage whatsoever caused by viruses being passed.

Loading...