You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Lev Serebryakov <le...@serebryakov.spb.ru> on 2018/04/13 16:20:38 UTC
Strange libtool errors when try to build pyhton and ruby bindings
(1.10.0)
I'm preparing FreeBSD of subversion-1.10.0 and have very strange errors
when try to build bindings.
subversion itself builds without problems.
python one:
/bin/sh
"/usr/home/lev/FreeBSD/ports/devel/py-subversion/work-py34/subversion-1.10.0/libtool"
--tag=CC --silent --mode=compile -DSWIGPYTHON
-I/usr/home/lev/FreeBSD/ports/devel/py-subversion/work-py34/subversion-1.10.0/subversion/bindings/swig/python/libsvn_swig_py
-I./subversion/include -I./subversion -I/usr/local/include/apr-1
-I/usr/local/include/apr-1 -I/usr/local/include
-I/usr/local/include/serf-1 -I/usr/local/include -I/usr/local/include
-I/usr/local/include -o
subversion/bindings/swig/python/libsvn_swig_py/swigutil_py.lo -c
subversion/bindings/swig/python/libsvn_swig_py/swigutil_py.c
Usage:
/usr/home/lev/FreeBSD/ports/devel/py-subversion/work-py34/subversion-1.10.0/libtool
[OPTION]... [MODE-ARG]...
Try 'libtool --help' for more information.
libtool: error: unrecognised option: '-DSWIGPYTHON'
*** Error code 1
ruby one:
/bin/sh
"/usr/home/lev/FreeBSD/ports/devel/ruby-subversion/work/subversion-1.10.0/libtool"
--tag=CC --silent --mode=compile
-I/usr/home/lev/FreeBSD/ports/devel/ruby-subversion/work/subversion-1.10.0/subversion/bindings/swig/ruby/libsvn_swig_ruby
-I./subversion/include -I./subversion -I/usr/local/include/apr-1
-I/usr/local/include/apr-1 -I/usr/local/include
-I/usr/local/include/serf-1 -I/usr/local/include -I/usr/local/include
-I/usr/local/include -o
subversion/bindings/swig/ruby/libsvn_swig_ruby/swigutil_rb.lo -c
subversion/bindings/swig/ruby/libsvn_swig_ruby/swigutil_rb.c
Usage:
/usr/home/lev/FreeBSD/ports/devel/ruby-subversion/work/subversion-1.10.0/libtool
[OPTION]... [MODE-ARG]...
Try 'libtool --help' for more information.
libtool: error: unrecognised option:
'-I/usr/home/lev/FreeBSD/ports/devel/ruby-subversion/work/subversion-1.10.0/subversion/bindings/swig/ruby/libsvn_swig_ruby'
*** Error code 1
--
// Black Lion AKA Lev Serebryakov
Re: Strange libtool errors when try to build pyhton and ruby bindings
(1.10.0)
Posted by Lev Serebryakov <le...@serebryakov.spb.ru>.
On 14.04.2018 19:42, Daniel Shahaf wrote:
>> Commands (cc) are missed in both cases. perl and Java bindings don't
>> have this problem.
>
> Not an answer to your question, but it would have been nice to catch
> this problem during the release candidate phase. Did you try to build
> packages of the 1.10.0-rc* releases?
Mea culpa. I had total fcuk up at my paid work exactly in RC phase,
unfortunately.
Workaround for this problems with bindings exists: to have swig3.0
installed at configure & build phase.
--
// Black Lion AKA Lev Serebryakov
Re: Strange libtool errors when try to build pyhton and ruby bindings
(1.10.0)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Lev Serebryakov wrote on Fri, 13 Apr 2018 19:39 +0300:
> On 13.04.2018 19:20, Lev Serebryakov wrote:
> > I'm preparing FreeBSD of subversion-1.10.0 and have very strange errors
> > when try to build bindings.
> Commands (cc) are missed in both cases. perl and Java bindings don't
> have this problem.
Not an answer to your question, but it would have been nice to catch
this problem during the release candidate phase. Did you try to build
packages of the 1.10.0-rc* releases?
Cheers,
Daniel
Re: Strange libtool errors when try to build pyhton and ruby bindings
(1.10.0)
Posted by Lev Serebryakov <le...@serebryakov.spb.ru>.
On 13.04.2018 19:20, Lev Serebryakov wrote:
> I'm preparing FreeBSD of subversion-1.10.0 and have very strange errors
> when try to build bindings.
>
> subversion itself builds without problems.
>
> python one:
>
> ruby one:
>
Commands (cc) are missed in both cases. perl and Java bindings don't
have this problem.
--
// Black Lion AKA Lev Serebryakov
Re: Strange libtool errors when try to build pyhton and ruby bindings
(1.10.0)
Posted by Lev Serebryakov <le...@serebryakov.spb.ru>.
On 16.04.2018 11:36, Branko Čibej wrote:
> The problem is that Swig has become a build-time dependency now. We
> don't configure the Swig bindings unless Swig is installed, even if the
> binding sources are already generated — as they are in the release tarballs.
>
> The solution is to install Swig and tell configure about it:
>
> $ sudo pkg install swig30
> $ ./configure --with-swig=/usr/local/bin/swig30 ...
>
>
> This will not cause the Swig sources to be regenerated, but will perform
> the proper configuration to make them compile correctly.
It works, thanks!
> I consider this to be a bug in our build scripts, FWIW.
Great :)
--
// Black Lion AKA Lev Serebryakov
Re: Strange libtool errors when try to build pyhton and ruby
bindings (1.10.0)
Posted by James McCoy <ja...@jamessan.com>.
On Mon, Apr 16, 2018 at 03:30:24PM +0200, Branko Čibej wrote:
> On 16.04.2018 14:29, James McCoy wrote:
> > On Mon, Apr 16, 2018 at 10:42:31AM +0200, Branko Čibej wrote:
> >> [Moved from users@]
> >>
> >> On 16.04.2018 10:36, Branko Čibej wrote:
> >>> The problem is that Swig has become a build-time dependency now. We
> >>> don't configure the Swig bindings unless Swig is installed, even if the
> >>> binding sources are already generated — as they are in the release tarballs.
> >>>
> >>> The solution is to install Swig and tell configure about it:
> >>>
> >>> $ sudo pkg install swig30
> >>> $ ./configure --with-swig=/usr/local/bin/swig30 ...
> >>>
> >>>
> >>> This will not cause the Swig sources to be regenerated, but will perform
> >>> the proper configuration to make them compile correctly.
> >>>
> >>> I consider this to be a bug in our build scripts, FWIW.
> >> I tracked this down to r1751167, which is only on trunk and 1.10.x.
> >>
> >> Long story short: it is wrong to require swig in order to configure the
> >> swig bindings. The whole point of putting generated swig wrappers into
> >> the release tarballs is so that users can build them without having to
> >> install swig.
> >>
> >> Defining the symbols SWIG_PY_COMPILE, SWIG_RB_COMPILE, and so on, should
> >> depend on the various scripting languages being installed, not on the
> >> presence of Swig.
> >>
> >> Can anyone explain the reasoning behind this change?
> > I did some searching to see if I could find any discussion that led me
> > to making this change and didn't turn up anything. I assume I was
> > missing the context of the Swig bindings being pre-generated.
> >
> > Maybe we should have some automated testing for the peculiarities of
> > release tarballs to avoid mistakes like this in the future?
>
> We do, it's called release testing,
That's not automated. :) Especially since this is a known peculiarity,
it might be useful to have one bot generate a release tree (assuming our
tooling for that is independent from tagging), uninstall swig, and then
build.
> > Reverted in r1829260.
>
> Ok ... please make a backport proposal for 1.10.x.
Done.
Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: Strange libtool errors when try to build pyhton and ruby bindings
(1.10.0)
Posted by Branko Čibej <br...@apache.org>.
On 16.04.2018 14:29, James McCoy wrote:
> On Mon, Apr 16, 2018 at 10:42:31AM +0200, Branko Čibej wrote:
>> [Moved from users@]
>>
>> On 16.04.2018 10:36, Branko Čibej wrote:
>>> The problem is that Swig has become a build-time dependency now. We
>>> don't configure the Swig bindings unless Swig is installed, even if the
>>> binding sources are already generated — as they are in the release tarballs.
>>>
>>> The solution is to install Swig and tell configure about it:
>>>
>>> $ sudo pkg install swig30
>>> $ ./configure --with-swig=/usr/local/bin/swig30 ...
>>>
>>>
>>> This will not cause the Swig sources to be regenerated, but will perform
>>> the proper configuration to make them compile correctly.
>>>
>>> I consider this to be a bug in our build scripts, FWIW.
>> I tracked this down to r1751167, which is only on trunk and 1.10.x.
>>
>> Long story short: it is wrong to require swig in order to configure the
>> swig bindings. The whole point of putting generated swig wrappers into
>> the release tarballs is so that users can build them without having to
>> install swig.
>>
>> Defining the symbols SWIG_PY_COMPILE, SWIG_RB_COMPILE, and so on, should
>> depend on the various scripting languages being installed, not on the
>> presence of Swig.
>>
>> Can anyone explain the reasoning behind this change?
> I did some searching to see if I could find any discussion that led me
> to making this change and didn't turn up anything. I assume I was
> missing the context of the Swig bindings being pre-generated.
>
> Maybe we should have some automated testing for the peculiarities of
> release tarballs to avoid mistakes like this in the future?
We do, it's called release testing, but in my case, for example, I
always have "--with-swig" there ... and swig installed ... because I
test on my development machine. So the upshot is that at least I could
possibly test this better by using --without-swig for the release
tarballs (I'll have to check what that actually does).
> Reverted in r1829260.
Ok ... please make a backport proposal for 1.10.x.
-- Brane
Re: Strange libtool errors when try to build pyhton and ruby
bindings (1.10.0)
Posted by James McCoy <ja...@jamessan.com>.
On Mon, Apr 16, 2018 at 10:42:31AM +0200, Branko Čibej wrote:
> [Moved from users@]
>
> On 16.04.2018 10:36, Branko Čibej wrote:
> > The problem is that Swig has become a build-time dependency now. We
> > don't configure the Swig bindings unless Swig is installed, even if the
> > binding sources are already generated — as they are in the release tarballs.
> >
> > The solution is to install Swig and tell configure about it:
> >
> > $ sudo pkg install swig30
> > $ ./configure --with-swig=/usr/local/bin/swig30 ...
> >
> >
> > This will not cause the Swig sources to be regenerated, but will perform
> > the proper configuration to make them compile correctly.
> >
> > I consider this to be a bug in our build scripts, FWIW.
>
> I tracked this down to r1751167, which is only on trunk and 1.10.x.
>
> Long story short: it is wrong to require swig in order to configure the
> swig bindings. The whole point of putting generated swig wrappers into
> the release tarballs is so that users can build them without having to
> install swig.
>
> Defining the symbols SWIG_PY_COMPILE, SWIG_RB_COMPILE, and so on, should
> depend on the various scripting languages being installed, not on the
> presence of Swig.
>
> Can anyone explain the reasoning behind this change?
I did some searching to see if I could find any discussion that led me
to making this change and didn't turn up anything. I assume I was
missing the context of the Swig bindings being pre-generated.
Maybe we should have some automated testing for the peculiarities of
release tarballs to avoid mistakes like this in the future?
Reverted in r1829260.
Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: Strange libtool errors when try to build pyhton and ruby bindings
(1.10.0)
Posted by Branko Čibej <br...@apache.org>.
[Moved from users@]
On 16.04.2018 10:36, Branko Čibej wrote:
> On 15.04.2018 21:30, Branko Čibej wrote:
>> On 13.04.2018 18:20, Lev Serebryakov wrote:
>>> I'm preparing FreeBSD of subversion-1.10.0 and have very strange errors
>>> when try to build bindings.
>>>
>>> subversion itself builds without problems.
>> I just created a FreeBSD 11 virtual machine tried building the 1.10.0
>> source tarball and ... well, I can confirm this report. I couldn't build
>> the Perl bindings either, due to a missing header.
>>
>> However, when I installed autoconf, libtool and swig30, and started with
>> a clean tree (make extraclean; ./autogen.sh; ./configure ...), I could
>> build JavaHL and all the Swig bindings — with the standard deluge of
>> missing typemap warnings. I could run the Perl, Python and JavaHL tests,
>> but not the Ruby tests, the latter apparently due to a missing dependency.
>>
>> It makes me wonder what went wrong with the build scripts generation in
>> the release package, because the builds worked fine on Linux, macOS and
>> OpenBSD. The other possibility is that FreeBSD is simply weird ...
> The problem is that Swig has become a build-time dependency now. We
> don't configure the Swig bindings unless Swig is installed, even if the
> binding sources are already generated — as they are in the release tarballs.
>
> The solution is to install Swig and tell configure about it:
>
> $ sudo pkg install swig30
> $ ./configure --with-swig=/usr/local/bin/swig30 ...
>
>
> This will not cause the Swig sources to be regenerated, but will perform
> the proper configuration to make them compile correctly.
>
> I consider this to be a bug in our build scripts, FWIW.
I tracked this down to r1751167, which is only on trunk and 1.10.x.
Long story short: it is wrong to require swig in order to configure the
swig bindings. The whole point of putting generated swig wrappers into
the release tarballs is so that users can build them without having to
install swig.
Defining the symbols SWIG_PY_COMPILE, SWIG_RB_COMPILE, and so on, should
depend on the various scripting languages being installed, not on the
presence of Swig.
Can anyone explain the reasoning behind this change?
-- Brane
Re: Strange libtool errors when try to build pyhton and ruby bindings
(1.10.0)
Posted by Branko Čibej <br...@apache.org>.
On 15.04.2018 21:30, Branko Čibej wrote:
> On 13.04.2018 18:20, Lev Serebryakov wrote:
>> I'm preparing FreeBSD of subversion-1.10.0 and have very strange errors
>> when try to build bindings.
>>
>> subversion itself builds without problems.
> I just created a FreeBSD 11 virtual machine tried building the 1.10.0
> source tarball and ... well, I can confirm this report. I couldn't build
> the Perl bindings either, due to a missing header.
>
> However, when I installed autoconf, libtool and swig30, and started with
> a clean tree (make extraclean; ./autogen.sh; ./configure ...), I could
> build JavaHL and all the Swig bindings — with the standard deluge of
> missing typemap warnings. I could run the Perl, Python and JavaHL tests,
> but not the Ruby tests, the latter apparently due to a missing dependency.
>
> It makes me wonder what went wrong with the build scripts generation in
> the release package, because the builds worked fine on Linux, macOS and
> OpenBSD. The other possibility is that FreeBSD is simply weird ...
The problem is that Swig has become a build-time dependency now. We
don't configure the Swig bindings unless Swig is installed, even if the
binding sources are already generated — as they are in the release tarballs.
The solution is to install Swig and tell configure about it:
$ sudo pkg install swig30
$ ./configure --with-swig=/usr/local/bin/swig30 ...
This will not cause the Swig sources to be regenerated, but will perform
the proper configuration to make them compile correctly.
I consider this to be a bug in our build scripts, FWIW.
-- Brane
Re: Strange libtool errors when try to build pyhton and ruby bindings
(1.10.0)
Posted by Branko Čibej <br...@apache.org>.
On 13.04.2018 18:20, Lev Serebryakov wrote:
> I'm preparing FreeBSD of subversion-1.10.0 and have very strange errors
> when try to build bindings.
>
> subversion itself builds without problems.
I just created a FreeBSD 11 virtual machine tried building the 1.10.0
source tarball and ... well, I can confirm this report. I couldn't build
the Perl bindings either, due to a missing header.
However, when I installed autoconf, libtool and swig30, and started with
a clean tree (make extraclean; ./autogen.sh; ./configure ...), I could
build JavaHL and all the Swig bindings — with the standard deluge of
missing typemap warnings. I could run the Perl, Python and JavaHL tests,
but not the Ruby tests, the latter apparently due to a missing dependency.
It makes me wonder what went wrong with the build scripts generation in
the release package, because the builds worked fine on Linux, macOS and
OpenBSD. The other possibility is that FreeBSD is simply weird ...
-- Brane