You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@wandisco.com> on 2012/12/21 15:55:36 UTC
Re: Second try at build system changes
Branko Čibej <br...@wandisco.com> writes:
> Please take time to review these changes and test them. I did my best to
> test on Mac OS and Linux, but as we saw in the previous iteration,
> autoconf isn't exactly obvious. As usual, I can't build swig-db and
> swig-py, but did touch their configury.
A plain 'make' works as does 'make swig-pl', 'make swig-py' and 'make
javahl'. 'make swig-py' is better than trunk where it fails due to
passing -Werror=implicit-function-declaration.
'make swig-rb' fails so is worse than trunk where it works. The error is
/usr/lib/ruby/1.8/x86_64-linux/ruby.h:709:1: error: unknown type name 'inline'
/usr/lib/ruby/1.8/x86_64-linux/ruby.h:711:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'rb_class_of'
/usr/lib/ruby/1.8/x86_64-linux/ruby.h:726:15: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'int'
/usr/lib/ruby/1.8/x86_64-linux/ruby.h:743:15: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'int'
In file included from /usr/lib/ruby/1.8/x86_64-linux/ruby.h:756:0,
from subversion/bindings/swig/ruby/svn_client.c:832:
The code in question is:
709 static inline VALUE
710 #if defined(HAVE_PROTOTYPES)
711 rb_class_of(VALUE obj)
712 #else
713 rb_class_of(obj)
714 VALUE obj;
715 #endif
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: Second try at build system changes
Posted by Daniel Shahaf <da...@elego.de>.
Branko Čibej wrote on Fri, Dec 21, 2012 at 23:05:14 +0100:
> On 21.12.2012 20:41, Daniel Shahaf wrote:
> > Branko Čibej wrote on Fri, Dec 21, 2012 at 19:40:03 +0100:
> >> On 21.12.2012 19:17, Philip Martin wrote:
> >>> Branko Čibej <br...@wandisco.com> writes:
> >>>
> >>>> On 21.12.2012 18:30, Philip Martin wrote:
> >>>>> Branko Čibej <br...@wandisco.com> writes:
> >>>>>
> >>>>>> Does "make EXTRA_CFLAGS=..." not give you exactly that?
> >>>>> I want to set the flags at configure.
> >>>> Sure, I understand that. But in order to do that, we'd have to introduce
> >>>> another variable besides C(XX)FLAGS, because those override whatever
> >>>> AC_PROG_CC would attempt to set, and always get used for bindings.
> >>>>
> >>>> Internally, configure already uses C(XX)USERFLAGS that could be
> >>>> repurposed for that kind of use, or even C(XX)MAINTAINERFLAGS, which
> >>>> have the right properties in that they're not used to compile swig
> >>>> wrappers and such.
> >>>>
> >>>> Would that satisfy your requirements?
> >>> I suppose I want to be able to specify an initial value for
> >>> CMAINTAINERFLAGS:
> >>>
> >>> configure CMAINTAINERFLAGS=--something-special
> >>>
> >>> Then our code builds with --something-special, in addition to whatever
> >>> configure chooses to add, while the generated code builds without my
> >>> extra flag.
> >>>
> >>> I wouldn't hold up your branch for this, trunk doesn't support it
> >>> either.
> >> Sure. But this exact use is amazingly easy to support, given the
> >> infrastructure already present on the branch. So I'll just make it work,
> >> even without --maintainer-mode.
> > Can someone spell out the conclusion please? How do I add something to
> > CFLAGS at configure time --- by setting CMAINTAINERFLAGS? What if I set
> > CFLAGS, would that append or replace to whatever configure things the
> > flags should be?
>
> It's all explained in the BRANCH-README, and here's how it works:
>
Thanks for the detailed reply; I did read BRANCH-README, I guess not
attentively enough.
Re: Second try at build system changes
Posted by Branko Čibej <br...@wandisco.com>.
On 21.12.2012 20:41, Daniel Shahaf wrote:
> Branko Čibej wrote on Fri, Dec 21, 2012 at 19:40:03 +0100:
>> On 21.12.2012 19:17, Philip Martin wrote:
>>> Branko Čibej <br...@wandisco.com> writes:
>>>
>>>> On 21.12.2012 18:30, Philip Martin wrote:
>>>>> Branko Čibej <br...@wandisco.com> writes:
>>>>>
>>>>>> Does "make EXTRA_CFLAGS=..." not give you exactly that?
>>>>> I want to set the flags at configure.
>>>> Sure, I understand that. But in order to do that, we'd have to introduce
>>>> another variable besides C(XX)FLAGS, because those override whatever
>>>> AC_PROG_CC would attempt to set, and always get used for bindings.
>>>>
>>>> Internally, configure already uses C(XX)USERFLAGS that could be
>>>> repurposed for that kind of use, or even C(XX)MAINTAINERFLAGS, which
>>>> have the right properties in that they're not used to compile swig
>>>> wrappers and such.
>>>>
>>>> Would that satisfy your requirements?
>>> I suppose I want to be able to specify an initial value for
>>> CMAINTAINERFLAGS:
>>>
>>> configure CMAINTAINERFLAGS=--something-special
>>>
>>> Then our code builds with --something-special, in addition to whatever
>>> configure chooses to add, while the generated code builds without my
>>> extra flag.
>>>
>>> I wouldn't hold up your branch for this, trunk doesn't support it
>>> either.
>> Sure. But this exact use is amazingly easy to support, given the
>> infrastructure already present on the branch. So I'll just make it work,
>> even without --maintainer-mode.
> Can someone spell out the conclusion please? How do I add something to
> CFLAGS at configure time --- by setting CMAINTAINERFLAGS? What if I set
> CFLAGS, would that append or replace to whatever configure things the
> flags should be?
It's all explained in the BRANCH-README, and here's how it works:
* The effect of ./configure C(XX)FLAGS=... did not change and is the
same as with any normal autoconf-driven build: explicit C(XX)FLAGS
override whatever default autoconf would set in AC_PROG_CC(XX)
(usually -g -O2) and these flags are used throughout the build.
* Our configury additionally tries to find the proper flags that put
the compiler into C90 and C++98 mode, and stores them in
C(XX)MODEFLAGS. These flags are used to build all Subversion
sources, but not, e.g., Swig-generated sources.
* If you run ./configure C(XX)USERFLAGS=..., these flags are
internally stored in C(XX)MAINTAINERFLAGS and are always used with
Subversion sources, but not with, e.g., Swig-generated sources.
* Maintainer-mode warnings etc. are prepended to C(XX)MAINTAINERFLAGS.
Additionally, the option --enable-optimize can be used to turn on our
default optimizations, which override autoconf's default -O2.
Furthermore, --enable-optimize works in conjunction with --enable-debug,
yielding -O1 -g3 (if, of course, the compiler supports these flags).
Eventually I'll make it so that CMODEFLAGS and CMAINTAINERFLAGS are not
used when compiling the amalgamated SQLite sources and any other
similarly incorporated 3rd-party sources. But to get there, I'll have to
change gen-make.py and friends.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: Second try at build system changes
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Branko Čibej wrote on Fri, Dec 21, 2012 at 19:40:03 +0100:
> On 21.12.2012 19:17, Philip Martin wrote:
> > Branko Čibej <br...@wandisco.com> writes:
> >
> >> On 21.12.2012 18:30, Philip Martin wrote:
> >>> Branko Čibej <br...@wandisco.com> writes:
> >>>
> >>>> Does "make EXTRA_CFLAGS=..." not give you exactly that?
> >>> I want to set the flags at configure.
> >> Sure, I understand that. But in order to do that, we'd have to introduce
> >> another variable besides C(XX)FLAGS, because those override whatever
> >> AC_PROG_CC would attempt to set, and always get used for bindings.
> >>
> >> Internally, configure already uses C(XX)USERFLAGS that could be
> >> repurposed for that kind of use, or even C(XX)MAINTAINERFLAGS, which
> >> have the right properties in that they're not used to compile swig
> >> wrappers and such.
> >>
> >> Would that satisfy your requirements?
> > I suppose I want to be able to specify an initial value for
> > CMAINTAINERFLAGS:
> >
> > configure CMAINTAINERFLAGS=--something-special
> >
> > Then our code builds with --something-special, in addition to whatever
> > configure chooses to add, while the generated code builds without my
> > extra flag.
> >
> > I wouldn't hold up your branch for this, trunk doesn't support it
> > either.
>
> Sure. But this exact use is amazingly easy to support, given the
> infrastructure already present on the branch. So I'll just make it work,
> even without --maintainer-mode.
Can someone spell out the conclusion please? How do I add something to
CFLAGS at configure time --- by setting CMAINTAINERFLAGS? What if I set
CFLAGS, would that append or replace to whatever configure things the
flags should be?
Thanks,
Daniel
Re: Second try at build system changes
Posted by Branko Čibej <br...@wandisco.com>.
On 21.12.2012 19:17, Philip Martin wrote:
> Branko Čibej <br...@wandisco.com> writes:
>
>> On 21.12.2012 18:30, Philip Martin wrote:
>>> Branko Čibej <br...@wandisco.com> writes:
>>>
>>>> Does "make EXTRA_CFLAGS=..." not give you exactly that?
>>> I want to set the flags at configure.
>> Sure, I understand that. But in order to do that, we'd have to introduce
>> another variable besides C(XX)FLAGS, because those override whatever
>> AC_PROG_CC would attempt to set, and always get used for bindings.
>>
>> Internally, configure already uses C(XX)USERFLAGS that could be
>> repurposed for that kind of use, or even C(XX)MAINTAINERFLAGS, which
>> have the right properties in that they're not used to compile swig
>> wrappers and such.
>>
>> Would that satisfy your requirements?
> I suppose I want to be able to specify an initial value for
> CMAINTAINERFLAGS:
>
> configure CMAINTAINERFLAGS=--something-special
>
> Then our code builds with --something-special, in addition to whatever
> configure chooses to add, while the generated code builds without my
> extra flag.
>
> I wouldn't hold up your branch for this, trunk doesn't support it
> either.
Sure. But this exact use is amazingly easy to support, given the
infrastructure already present on the branch. So I'll just make it work,
even without --maintainer-mode.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: Second try at build system changes
Posted by Philip Martin <ph...@wandisco.com>.
Branko Čibej <br...@wandisco.com> writes:
> On 21.12.2012 18:30, Philip Martin wrote:
>> Branko Čibej <br...@wandisco.com> writes:
>>
>>> Does "make EXTRA_CFLAGS=..." not give you exactly that?
>> I want to set the flags at configure.
>
> Sure, I understand that. But in order to do that, we'd have to introduce
> another variable besides C(XX)FLAGS, because those override whatever
> AC_PROG_CC would attempt to set, and always get used for bindings.
>
> Internally, configure already uses C(XX)USERFLAGS that could be
> repurposed for that kind of use, or even C(XX)MAINTAINERFLAGS, which
> have the right properties in that they're not used to compile swig
> wrappers and such.
>
> Would that satisfy your requirements?
I suppose I want to be able to specify an initial value for
CMAINTAINERFLAGS:
configure CMAINTAINERFLAGS=--something-special
Then our code builds with --something-special, in addition to whatever
configure chooses to add, while the generated code builds without my
extra flag.
I wouldn't hold up your branch for this, trunk doesn't support it
either.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: Second try at build system changes
Posted by Branko Čibej <br...@wandisco.com>.
On 21.12.2012 18:30, Philip Martin wrote:
> Branko Čibej <br...@wandisco.com> writes:
>
>> Does "make EXTRA_CFLAGS=..." not give you exactly that?
> I want to set the flags at configure.
Sure, I understand that. But in order to do that, we'd have to introduce
another variable besides C(XX)FLAGS, because those override whatever
AC_PROG_CC would attempt to set, and always get used for bindings.
Internally, configure already uses C(XX)USERFLAGS that could be
repurposed for that kind of use, or even C(XX)MAINTAINERFLAGS, which
have the right properties in that they're not used to compile swig
wrappers and such.
Would that satisfy your requirements?
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: Second try at build system changes
Posted by Philip Martin <ph...@wandisco.com>.
Branko Čibej <br...@wandisco.com> writes:
> Does "make EXTRA_CFLAGS=..." not give you exactly that?
I want to set the flags at configure.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: Second try at build system changes
Posted by Branko Čibej <br...@wandisco.com>.
On 21.12.2012 18:12, Philip Martin wrote:
> Branko Čibej <br...@wandisco.com> writes:
>
>> On 21.12.2012 18:03, Branko Čibej wrote:
>>> On 21.12.2012 18:02, Philip Martin wrote:
>>>> Branko Čibej <br...@wandisco.com> writes:
>>>>
>>>>> On 21.12.2012 16:36, Philip Martin wrote:
>>>>>> So the build system used to strip -std=c89 and now does not. If I
>>>>>> remove -std=c89 from SWIG_RB_COMPILE in Makefile the build works.
>>>>> Thanks. Apparently I either missed that somehow, or this option came
>>>>> from the Ruby compile flags, not ours. Will try to fix.
>>>> I added it when I ran configure.
>>> Oh. Dare I say, "don't do that"? :)
>> Just to be clear: The intent of the changes is, amongst other things,
>> that configure determines these kinds of flags and keeps them in a
>> separate variable, precisely so that we don't have to strip them from
>> anywhere. Of course, running "env CFLAGS=-ansi ./configure" defeats that.
>>
>> I'd prefer to not support that kind of usage.
> trunk doesn't add a -std flag and I wanted to build with one. I'd like
> a system that allows me to specify arbitrary flags that get used to
> compile our code but that do not get used when compiling "other"
> generated code.
Does "make EXTRA_CFLAGS=..." not give you exactly that?
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: Second try at build system changes
Posted by Philip Martin <ph...@wandisco.com>.
Branko Čibej <br...@wandisco.com> writes:
> On 21.12.2012 18:03, Branko Čibej wrote:
>> On 21.12.2012 18:02, Philip Martin wrote:
>>> Branko Čibej <br...@wandisco.com> writes:
>>>
>>>> On 21.12.2012 16:36, Philip Martin wrote:
>>>>> So the build system used to strip -std=c89 and now does not. If I
>>>>> remove -std=c89 from SWIG_RB_COMPILE in Makefile the build works.
>>>> Thanks. Apparently I either missed that somehow, or this option came
>>>> from the Ruby compile flags, not ours. Will try to fix.
>>> I added it when I ran configure.
>> Oh. Dare I say, "don't do that"? :)
>
> Just to be clear: The intent of the changes is, amongst other things,
> that configure determines these kinds of flags and keeps them in a
> separate variable, precisely so that we don't have to strip them from
> anywhere. Of course, running "env CFLAGS=-ansi ./configure" defeats that.
>
> I'd prefer to not support that kind of usage.
trunk doesn't add a -std flag and I wanted to build with one. I'd like
a system that allows me to specify arbitrary flags that get used to
compile our code but that do not get used when compiling "other"
generated code.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: Second try at build system changes
Posted by Branko Čibej <br...@wandisco.com>.
On 21.12.2012 18:03, Branko Čibej wrote:
> On 21.12.2012 18:02, Philip Martin wrote:
>> Branko Čibej <br...@wandisco.com> writes:
>>
>>> On 21.12.2012 16:36, Philip Martin wrote:
>>>> So the build system used to strip -std=c89 and now does not. If I
>>>> remove -std=c89 from SWIG_RB_COMPILE in Makefile the build works.
>>> Thanks. Apparently I either missed that somehow, or this option came
>>> from the Ruby compile flags, not ours. Will try to fix.
>> I added it when I ran configure.
> Oh. Dare I say, "don't do that"? :)
Just to be clear: The intent of the changes is, amongst other things,
that configure determines these kinds of flags and keeps them in a
separate variable, precisely so that we don't have to strip them from
anywhere. Of course, running "env CFLAGS=-ansi ./configure" defeats that.
I'd prefer to not support that kind of usage.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: Second try at build system changes
Posted by Branko Čibej <br...@wandisco.com>.
On 21.12.2012 18:02, Philip Martin wrote:
> Branko Čibej <br...@wandisco.com> writes:
>
>> On 21.12.2012 16:36, Philip Martin wrote:
>>> So the build system used to strip -std=c89 and now does not. If I
>>> remove -std=c89 from SWIG_RB_COMPILE in Makefile the build works.
>> Thanks. Apparently I either missed that somehow, or this option came
>> from the Ruby compile flags, not ours. Will try to fix.
> I added it when I ran configure.
Oh. Dare I say, "don't do that"? :)
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: Second try at build system changes
Posted by Branko Čibej <br...@wandisco.com>.
On 21.12.2012 18:07, Philip Martin wrote:
> Philip Martin <ph...@wandisco.com> writes:
>
>> Branko Čibej <br...@wandisco.com> writes:
>>
>>> On 21.12.2012 16:36, Philip Martin wrote:
>>>> So the build system used to strip -std=c89 and now does not. If I
>>>> remove -std=c89 from SWIG_RB_COMPILE in Makefile the build works.
>>> Thanks. Apparently I either missed that somehow, or this option came
>>> from the Ruby compile flags, not ours. Will try to fix.
>> I added it when I ran configure.
> So your branch adds -std=c90 automatically so I suppose I could stop
> adding -std=c89.
I added flag stripping for Ruby anyway; it's true that otherwise the
build system would be too flaky. Of course ... it heavily depends on
GCC-compatible command-line parsing; but, well, that's hardly new.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: Second try at build system changes
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@wandisco.com> writes:
> Branko Čibej <br...@wandisco.com> writes:
>
>> On 21.12.2012 16:36, Philip Martin wrote:
>>> So the build system used to strip -std=c89 and now does not. If I
>>> remove -std=c89 from SWIG_RB_COMPILE in Makefile the build works.
>>
>> Thanks. Apparently I either missed that somehow, or this option came
>> from the Ruby compile flags, not ours. Will try to fix.
>
> I added it when I ran configure.
So your branch adds -std=c90 automatically so I suppose I could stop
adding -std=c89.
--
Philip
Re: Second try at build system changes
Posted by Philip Martin <ph...@wandisco.com>.
Branko Čibej <br...@wandisco.com> writes:
> On 21.12.2012 16:36, Philip Martin wrote:
>> So the build system used to strip -std=c89 and now does not. If I
>> remove -std=c89 from SWIG_RB_COMPILE in Makefile the build works.
>
> Thanks. Apparently I either missed that somehow, or this option came
> from the Ruby compile flags, not ours. Will try to fix.
I added it when I ran configure.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: Second try at build system changes
Posted by Branko Čibej <br...@wandisco.com>.
On 21.12.2012 16:36, Philip Martin wrote:
> So the build system used to strip -std=c89 and now does not. If I
> remove -std=c89 from SWIG_RB_COMPILE in Makefile the build works.
Thanks. Apparently I either missed that somehow, or this option came
from the Ruby compile flags, not ours. Will try to fix.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: Second try at build system changes
Posted by Philip Martin <ph...@wandisco.com>.
Branko Čibej <br...@wandisco.com> writes:
> Can you post the actual compiler-via-libtool invocation, so that I can
> see which options came through to confuse the compiler?
This is the working line (with a number of compiler flags from my normal
build):
/bin/sh /home/pm/sw/subversion/obj/libtool --tag=CC --silent --mode=compile gcc-4.6 -g -DSVN_DEPRECATED= -DAPR_POOL_DEBUG -Wpointer-arith -Wdeclaration-after-statement -Wold-style-definition -Wwrite-strings -Wbad-function-cast -Wstrict-overflow -pthread -Werror=implicit-function-declaration -DSVN_DEBUG -DAP_DEBUG -Wno-int-to-pointer-cast -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -I/home/pm/sw/subversion/obj/subversion -I/home/pm/sw/subversion/obj/../src/subversion/include -I/home/pm/sw/subversion/obj/../src/subversion/bindings/swig -I/home/pm/sw/subversion/obj/../src/subversion/bindings/swig/include -I/home/pm/sw/subversion/obj/../src/subversion/bindings/swig/proxy -I/home/pm/sw/subversion/obj/subversion/bindings/swig/proxy -I/usr/include/apr-1.0 -I/usr/include/apr-1.0 -I/usr/include -I. -I/usr/lib/ruby/1.8/x86_64-linux -I/home/pm/sw/subversion/obj/../src/subversion/bindings/swig/ruby/libsvn_swig_ruby -prefer-pic -c -o subversion/bindings/swig/ruby/svn_client.lo subversion/bindings/swig/ruby/svn_client.c
This is the failing line:
/bin/sh /home/pm/sw/subversion/obj2/libtool --tag=CC --silent --mode=compile gcc-4.6 -g -DSVN_DEPRECATED= -DAPR_POOL_DEBUG -std=c89 -Wall -Wshadow -Wpointer-arith -Wdeclaration-after-statement -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wwrite-strings -Wbad-function-cast -Wstrict-overflow -pthread -DSVN_DEBUG -DAP_DEBUG -Wno-int-to-pointer-cast -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -I/home/pm/sw/subversion/obj2/subversion -I/home/pm/sw/subversion/obj2/../src2/subversion/include -I/home/pm/sw/subversion/obj2/../src2/subversion/bindings/swig -I/home/pm/sw/subversion/obj2/../src2/subversion/bindings/swig/include -I/home/pm/sw/subversion/obj2/../src2/subversion/bindings/swig/proxy -I/home/pm/sw/subversion/obj2/subversion/bindings/swig/proxy -I/usr/include/apr-1.0 -I/usr/include/apr-1.0 -I/usr/include -I. -I/usr/lib/ruby/1.8/x86_64-linux -I/home/pm/sw/subversion/obj2/../src2/subversion/bindings/swig/ruby/libsvn_swig_ruby -prefer-pic -c -o subversion/bindings/swig/ruby/svn_client.lo subversion/bindings/swig/ruby/svn_client.c
So the build system used to strip -std=c89 and now does not. If I
remove -std=c89 from SWIG_RB_COMPILE in Makefile the build works.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: Second try at build system changes
Posted by Branko Čibej <br...@wandisco.com>.
On 21.12.2012 15:55, Philip Martin wrote:
> Branko Čibej <br...@wandisco.com> writes:
>
>> Please take time to review these changes and test them. I did my best to
>> test on Mac OS and Linux, but as we saw in the previous iteration,
>> autoconf isn't exactly obvious. As usual, I can't build swig-db and
>> swig-py, but did touch their configury.
> A plain 'make' works as does 'make swig-pl', 'make swig-py' and 'make
> javahl'. 'make swig-py' is better than trunk where it fails due to
> passing -Werror=implicit-function-declaration.
Good! Thanks for taking time to look into that.
> 'make swig-rb' fails so is worse than trunk where it works. The error is
>
> /usr/lib/ruby/1.8/x86_64-linux/ruby.h:709:1: error: unknown type name 'inline'
> /usr/lib/ruby/1.8/x86_64-linux/ruby.h:711:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'rb_class_of'
> /usr/lib/ruby/1.8/x86_64-linux/ruby.h:726:15: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'int'
> /usr/lib/ruby/1.8/x86_64-linux/ruby.h:743:15: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'int'
> In file included from /usr/lib/ruby/1.8/x86_64-linux/ruby.h:756:0,
> from subversion/bindings/swig/ruby/svn_client.c:832:
>
> The code in question is:
>
> 709 static inline VALUE
> 710 #if defined(HAVE_PROTOTYPES)
> 711 rb_class_of(VALUE obj)
> 712 #else
> 713 rb_class_of(obj)
> 714 VALUE obj;
> 715 #endif
Can you post the actual compiler-via-libtool invocation, so that I can
see which options came through to confuse the compiler?
(I sure hope -DHAVE_PROTOTYPES was one of them.)
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com