>
>
> 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 diff
Ian Mordey writes:
> Not that I can spot:
> gutils.h
> G_INLINE_FUNC gint g_bit_nth_lsf (gulong mask,
>gintnth_bit);
> G_INLINE_FUNC gint g_bit_nth_msf (gulong mask,
>gintnth_bit);
> G_INLINE_FUNC
>
>
>
> 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 o
Ian Mordey 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
>
>
>>
> 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/WANdisc
Ian Mordey 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,
Ian Mordey 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 yo
>
>
> 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
Ian Mordey 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 uns
>
>
> 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
Ian Mordey 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, openss
>
>
> 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 effectivel
Ian Mordey 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 G
On Wed, Aug 2, 2017 at 11:23 AM Philip Martin
wrote:
> Ian Mordey 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 a
Ian Mordey 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 w
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
16 matches
Mail list logo
