You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ian Mordey <ia...@wandisco.com> on 2017/08/01 16:17:33 UTC
Subversion 1.8.x on Solaris 10 x86
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
*wandisco.com* <http://www.wandisco.com/>
--
World Leader in Active Data Replication™
*Find out more wandisco.com <http://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.
Re: Subversion 1.8.x on Solaris 10 x86
Posted by Philip Martin <ph...@codematters.co.uk>.
Ian Mordey <ia...@wandisco.com> 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
Re: Subversion 1.8.x on Solaris 10 x86
Posted by Ian Mordey <ia...@wandisco.com>.
>
>
> 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
*wandisco.com* <http://www.wandisco.com/>
--
World Leader in Active Data Replication™
*Find out more wandisco.com <http://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.
Re: Subversion 1.8.x on Solaris 10 x86
Posted by Philip Martin <ph...@codematters.co.uk>.
Ian Mordey <ia...@wandisco.com> 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
Re: Subversion 1.8.x on Solaris 10 x86
Posted by Ian Mordey <ia...@wandisco.com>.
>
>
>
> 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:
https://pastebin.com/HhvEZFRq
Thanks
Ian
>
> --
> Philip
>
--
*IAN MORDEY* HEAD OF INFRASTRUCTURE
*wandisco.com* <http://www.wandisco.com/>
--
World Leader in Active Data Replication™
*Find out more wandisco.com <http://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.
Re: Subversion 1.8.x on Solaris 10 x86
Posted by Philip Martin <ph...@codematters.co.uk>.
Ian Mordey <ia...@wandisco.com> 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
Re: Subversion 1.8.x on Solaris 10 x86
Posted by Ian Mordey <ia...@wandisco.com>.
>
>
>>
> 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
>
> *wandisco.com* <http://www.wandisco.com/>
>
--
*IAN MORDEY* HEAD OF INFRASTRUCTURE
*wandisco.com* <http://www.wandisco.com/>
--
World Leader in Active Data Replication™
*Find out more wandisco.com <http://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.
Re: Subversion 1.8.x on Solaris 10 x86
Posted by Philip Martin <ph...@codematters.co.uk>.
Ian Mordey <ia...@wandisco.com> 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
Re: Subversion 1.8.x on Solaris 10 x86
Posted by Ian Mordey <ia...@wandisco.com>.
>
>
> 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
*wandisco.com* <http://www.wandisco.com/>
--
World Leader in Active Data Replication™
*Find out more wandisco.com <http://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.
Re: Subversion 1.8.x on Solaris 10 x86
Posted by Philip Martin <ph...@codematters.co.uk>.
Ian Mordey <ia...@wandisco.com> 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
Re: Subversion 1.8.x on Solaris 10 x86
Posted by Ian Mordey <ia...@wandisco.com>.
>
>
> 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
*wandisco.com* <http://www.wandisco.com/>
--
World Leader in Active Data Replication™
*Find out more wandisco.com <http://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.
Re: Subversion 1.8.x on Solaris 10 x86
Posted by Philip Martin <ph...@codematters.co.uk>.
Ian Mordey <ia...@wandisco.com> 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
Re: Subversion 1.8.x on Solaris 10 x86
Posted by Ian Mordey <ia...@wandisco.com>.
>
>
> 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
*wandisco.com* <http://www.wandisco.com/>
--
World Leader in Active Data Replication™
*Find out more wandisco.com <http://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.
Re: Subversion 1.8.x on Solaris 10 x86
Posted by Philip Martin <ph...@codematters.co.uk>.
Ian Mordey <ia...@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
Re: Subversion 1.8.x on Solaris 10 x86
Posted by Ian Mordey <ia...@wandisco.com>.
On Wed, Aug 2, 2017 at 11:23 AM Philip Martin <ph...@codematters.co.uk>
wrote:
> Ian Mordey <ia...@wandisco.com> 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
*wandisco.com* <http://www.wandisco.com/>
--
World Leader in Active Data Replication™
*Find out more wandisco.com <http://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.
Re: Subversion 1.8.x on Solaris 10 x86
Posted by Philip Martin <ph...@codematters.co.uk>.
Ian Mordey <ia...@wandisco.com> 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