Strange libtool errors when try to build pyhton and ruby bindings (1.10.0)

[Lev Serebryakov]

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

[Lev Serebryakov]

Post by Lev Serebryakov
I'm preparing FreeBSD of subversion-1.10.0 and have very strange errors
when try to build bindings.
subversion itself builds without problems.

Commands (cc) are missed in both cases. perl and Java bindings don't
have this problem.

[Daniel Shahaf]

Post by Lev Serebryakov

Post by Lev Serebryakov
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

[Lev Serebryakov]

Post by Daniel Shahaf

Post by Lev Serebryakov
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.

[Branko Čibej]

Post by Lev Serebryakov
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

[Branko Čibej]

Post by Branko Čibej

Post by Lev Serebryakov
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

[Lev Serebryakov]

Post by Branko Čibej
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.
$ 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!

Post by Branko Čibej
I consider this to be a bug in our build scripts, FWIW.

Great :)