subversion 1.14.1: could not build python bindings (1.41.0 is Ok)

[Lev Serebryakov]

Update to 1.14.1 break out-of-tree build of python bindings (with python 3.7).
1.14.0 works with same options, makefiles, etc. 1.14.1 fails to build bindings when libraries are installed and swig is not installed (bindings are built as separate ntity, not together with subversion libraries themselves):

--- check-swig-py ---
if [ "LD_LIBRARY_PATH" = "DYLD_LIBRARY_PATH" ]; then for d in /wrkdirs/usr/ports/devel/py-subversion/work-py37/subversion-1.14.1/subversion/bindings/swig/python/libsvn_swig_py /wrkdirs/usr/ports/devel/py-subversion/work-py37/subversion-1.14.1/subversion/bindings/swig/python/../../../libsvn_*; do if [ -n "$DYLD_LIBRARY_PATH" ]; then LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$d/.libs"; else LD_LIBRARY_PATH="$d/.libs"; fi; done; export LD_LIBRARY_PATH; fi; cd /wrkdirs/usr/ports/devel/py-subversion/work-py37/subversion-1.14.1/subversion/bindings/swig/python; /usr/local/bin/python3.7 /wrkdirs/usr/ports/devel/py-subversion/work-py37/subversion-1.14.1/subversion/bindings/swig/python/tests/run_all.py
Traceback (most recent call last):
File "/wrkdirs/usr/ports/devel/py-subversion/work-py37/subversion-1.14.1/subversion/bindings/swig/python/tests/run_all.py", line 23, in <module>
import mergeinfo, core, client, delta, checksum, pool, fs, ra, wc, repository, \
File "/wrkdirs/usr/ports/devel/py-subversion/work-py37/subversion-1.14.1/subversion/bindings/swig/python/tests/mergeinfo.py", line 22, in <module>
from svn import core, repos, fs
File "/wrkdirs/usr/ports/devel/py-subversion/work-py37/subversion-1.14.1/subversion/bindings/swig/python/svn/core.py", line 26, in <module>
from libsvn.core import *
File "/wrkdirs/usr/ports/devel/py-subversion/work-py37/subversion-1.14.1/subversion/bindings/swig/python/libsvn/core.py", line 26, in <module>
from . import _core
ImportError: cannot import name '_core' from 'libsvn' (/wrkdirs/usr/ports/devel/py-subversion/work-py37/subversion-1.14.1/subversion/bindings/swig/python/libsvn/__init__.py)
*** [check-swig-py] Error code 1



--
// Black Lion AKA Lev Serebryakov

[Yasuhito FUTATSUKI]

Hi,

On 2021/02/17 0:04, Lev Serebryakov wrote:
>
>   Update to 1.14.1 break out-of-tree build of python bindings (with python 3.7).
>   1.14.0 works with same options, makefiles, etc. 1.14.1 fails to build bindings when libraries are installed and swig is not installed (bindings are built as separate ntity, not together with subversion libraries themselves):
>

Even subversion libraries are installed, 'make check-swig-py' needs
subversion libraries in build tree. Those will be built before
building bindings if they were not built yet.

> --- check-swig-py ---
> if [ "LD_LIBRARY_PATH" = "DYLD_LIBRARY_PATH" ]; then  for d in /wrkdirs/usr/ports/devel/py-subversion/work-py37/subversion-1.14.1/subversion/bindings/swig/python/libsvn_swig_py /wrkdirs/usr/ports/devel/py-subversion/work-py37/subversion-1.14.1/subversion/bindings/swig/python/../../../libsvn_*; do  if [ -n "$DYLD_LIBRARY_PATH" ]; then  LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$d/.libs";  else  LD_LIBRARY_PATH="$d/.libs";  fi;  done;  export LD_LIBRARY_PATH;  fi;  cd /wrkdirs/usr/ports/devel/py-subversion/work-py37/subversion-1.14.1/subversion/bindings/swig/python;  /usr/local/bin/python3.7 /wrkdirs/usr/ports/devel/py-subversion/work-py37/subversion-1.14.1/subversion/bindings/swig/python/tests/run_all.py
> Traceback (most recent call last):
>   File "/wrkdirs/usr/ports/devel/py-subversion/work-py37/subversion-1.14.1/subversion/bindings/swig/python/tests/run_all.py", line 23, in <module>
>     import mergeinfo, core, client, delta, checksum, pool, fs, ra, wc, repository, \
>   File "/wrkdirs/usr/ports/devel/py-subversion/work-py37/subversion-1.14.1/subversion/bindings/swig/python/tests/mergeinfo.py", line 22, in <module>
>     from svn import core, repos, fs
>   File "/wrkdirs/usr/ports/devel/py-subversion/work-py37/subversion-1.14.1/subversion/bindings/swig/python/svn/core.py", line 26, in <module>
>     from libsvn.core import *
>   File "/wrkdirs/usr/ports/devel/py-subversion/work-py37/subversion-1.14.1/subversion/bindings/swig/python/libsvn/core.py", line 26, in <module>
>     from . import _core
> ImportError: cannot import name '_core' from 'libsvn' (/wrkdirs/usr/ports/devel/py-subversion/work-py37/subversion-1.14.1/subversion/bindings/swig/python/libsvn/__init__.py)
> *** [check-swig-py] Error code 1
>

I tried to reproduce, but I couldn't reproduce the issue.

Did there exist subversion/bindings/swig/python/.libs/_core.so?
How about subversion/libsvn_client/.libs/libsvn_client-1.so.0, etc?

I did below on FreeBSD 12.2:
[[[
tar xpf /usr/ports/distfiles/subversion-1.14.1.tar.bz2
mkdir out-of-tree-svn-1.14.1
cd out-of-tree-svn-1.14.1
env PYTHON=/usr/local/bin/python3.7 sh ../subversion-1.14.1/configure \
--with-sqlite=/usr/local \
--with-expat=/usr/local/include:/usr/local/lib:expat --without-swig \
--with-apr=/usr/local/bin/apr-1-config \
--with-apr-util=/usr/local/bin/apu-1-config \
--without-gnome-keyring --without-kwallet \
--with-apxs=/usr/local/sbin/apxs \
--prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man \
--infodir=/usr/local/info --with-py3c=/usr/local
make check-swig-py
]]]
and it passed the test.

(Note: if source tree subversion-1.14.1 is not clean, "make swig-py"
stopped with error before building Python bindings.)

Result of ldd _core.so:
[[[
$ ldd subversion/bindings/swig/python/.libs/_core.so
subversion/bindings/swig/python/.libs/_core.so:
libsvn_swig_py-1.so.0 => /home/staff7/work/out-of-tree-svn-1.14.1/subversion/bindings/swig/python/libsvn_swig_py/.libs/libsvn_swig_py-1.so.0 (0x80071d000)
libsvn_client-1.so.0 => /home/staff7/work/out-of-tree-svn-1.14.1/subversion/libsvn_client/.libs/libsvn_client-1.so.0 (0x800734000)
libsvn_wc-1.so.0 => /home/staff7/work/out-of-tree-svn-1.14.1/subversion/libsvn_wc/.libs/libsvn_wc-1.so.0 (0x800e00000)
libsvn_diff-1.so.0 => /home/staff7/work/out-of-tree-svn-1.14.1/subversion/libsvn_diff/.libs/libsvn_diff-1.so.0 (0x8007c0000)
libsvn_ra-1.so.0 => /home/staff7/work/out-of-tree-svn-1.14.1/subversion/libsvn_ra/.libs/libsvn_ra-1.so.0 (0x8007da000)
libsvn_ra_local-1.so.0 => /home/staff7/work/out-of-tree-svn-1.14.1/subversion/libsvn_ra_local/.libs/libsvn_ra_local-1.so.0 (0x8007ea000)
libsvn_repos-1.so.0 => /home/staff7/work/out-of-tree-svn-1.14.1/subversion/libsvn_repos/.libs/libsvn_repos-1.so.0 (0x800ea9000)
libsvn_fs-1.so.0 => /home/staff7/work/out-of-tree-svn-1.14.1/subversion/libsvn_fs/.libs/libsvn_fs-1.so.0 (0x800ee8000)
libsvn_fs_fs-1.so.0 => /home/staff7/work/out-of-tree-svn-1.14.1/subversion/libsvn_fs_fs/.libs/libsvn_fs_fs-1.so.0 (0x800ef8000)
libsvn_fs_x-1.so.0 => /home/staff7/work/out-of-tree-svn-1.14.1/subversion/libsvn_fs_x/.libs/libsvn_fs_x-1.so.0 (0x800f4b000)
libsvn_fs_base-1.so.0 => /home/staff7/work/out-of-tree-svn-1.14.1/subversion/libsvn_fs_base/.libs/libsvn_fs_base-1.so.0 (0x800fbf000)
libdb-5.3.so.0 => /usr/local/lib/libdb-5.3.so.0 (0x800fef000)
libsvn_fs_util-1.so.0 => /home/staff7/work/out-of-tree-svn-1.14.1/subversion/libsvn_fs_util/.libs/libsvn_fs_util-1.so.0 (0x8007f6000)
libsvn_ra_svn-1.so.0 => /home/staff7/work/out-of-tree-svn-1.14.1/subversion/libsvn_ra_svn/.libs/libsvn_ra_svn-1.so.0 (0x801197000)
libsvn_ra_serf-1.so.0 => /home/staff7/work/out-of-tree-svn-1.14.1/subversion/libsvn_ra_serf/.libs/libsvn_ra_serf-1.so.0 (0x8011bf000)
libserf-1.so.1 => /usr/local/lib/libserf-1.so.1 (0x8011f3000)
libsvn_delta-1.so.0 => /home/staff7/work/out-of-tree-svn-1.14.1/subversion/libsvn_delta/.libs/libsvn_delta-1.so.0 (0x801211000)
libsvn_subr-1.so.0 => /home/staff7/work/out-of-tree-svn-1.14.1/subversion/libsvn_subr/.libs/libsvn_subr-1.so.0 (0x801232000)
libaprutil-1.so.0 => /usr/local/lib/libaprutil-1.so.0 (0x8012c7000)
libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x8012f8000)
libz.so.6 => /lib/libz.so.6 (0x801325000)
libsqlite3.so.0 => /usr/local/lib/libsqlite3.so.0 (0x801341000)
libmagic.so.4 => /usr/lib/libmagic.so.4 (0x8014e5000)
liblz4.so.1 => /usr/local/lib/liblz4.so.1 (0x80150f000)
libutf8proc.so.2 => /usr/local/lib/libutf8proc.so.2 (0x80153d000)
libapr-1.so.0 => /usr/local/lib/libapr-1.so.0 (0x801592000)
libintl.so.8 => /usr/local/lib/libintl.so.8 (0x8015d3000)
libthr.so.3 => /lib/libthr.so.3 (0x8015e1000)
libc.so.7 => /lib/libc.so.7 (0x80024e000)
libssl.so.111 => /usr/lib/libssl.so.111 (0x80160e000)
libcrypto.so.111 => /lib/libcrypto.so.111 (0x8016a6000)
libcrypt.so.5 => /lib/libcrypt.so.5 (0x801998000)
libgdbm.so.6 => /usr/local/lib/libgdbm.so.6 (0x8019b9000)
libm.so.5 => /lib/libm.so.5 (0x8019ca000)
]]]

Cheers,
--
Yasuhito FUTATSUKI <futa...@yf.bsclub.org>

[Nathan Hartman]

On Tue, Feb 16, 2021 at 10:05 AM Lev Serebryakov <l...@serebryakov.spb.ru> wrote:
>
>
> Update to 1.14.1 break out-of-tree build of python bindings (with python 3.7).

Are you building from a distribution tarball? (As opposed to a
checkout or export of the 1.14.1 tag in our repository...) If so, did
you run autogen.sh? I noticed some changes in
subversion/bindings/swig/INSTALL on trunk that haven't been backported
to 1.14.x. It's possible they (or some of them) should be backported.
You can generate a diff to view the changes with:

$ svn diff \
https://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/swig/INSTALL
\
https://svn.apache.org/repos/asf/subversion/tags/1.14.1/subversion/bindings/swig/INSTALL

Since your system shows the issue and Yasuhito couldn't reproduce it,
would you be able to run a bisect on the 1.14.x branch, between
r1877950 and r1886195 to identify which backport commit introduces the
problem? That would be an immense help.

Thanks,
Nathan

[Lev Serebryakov]

On 16.02.2021 19:51, Yasuhito FUTATSUKI wrote:

>>   Update to 1.14.1 break out-of-tree build of python bindings (with python 3.7).
>>   1.14.0 works with same options, makefiles, etc. 1.14.1 fails to build bindings when libraries are installed and swig is not installed (bindings are built as separate ntity, not together with subversion libraries themselves):
>>
>
> Even subversion libraries are installed, 'make check-swig-py' needs
> subversion libraries in build tree. Those will be built before
> building bindings if they were not built yet.

It was not so for long time (including 1.14.0) with "patched" (re-generated) build-outputs.mk.

>> --- check-swig-py ---
>> if [ "LD_LIBRARY_PATH" = "DYLD_LIBRARY_PATH" ]; then  for d in /wrkdirs/usr/ports/devel/py-subversion/work-py37/subversion-1.14.1/subversion/bindings/swig/python/libsvn_swig_py /wrkdirs/usr/ports/devel/py-subversion/work-py37/subversion-1.14.1/subversion/bindings/swig/python/../../../libsvn_*; do  if [ -n "$DYLD_LIBRARY_PATH" ]; then  LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$d/.libs";  else  LD_LIBRARY_PATH="$d/.libs";  fi;  done;  export LD_LIBRARY_PATH;  fi;  cd /wrkdirs/usr/ports/devel/py-subversion/work-py37/subversion-1.14.1/subversion/bindings/swig/python;  /usr/local/bin/python3.7 /wrkdirs/usr/ports/devel/py-subversion/work-py37/subversion-1.14.1/subversion/bindings/swig/python/tests/run_all.py
>> Traceback (most recent call last):
>>   File "/wrkdirs/usr/ports/devel/py-subversion/work-py37/subversion-1.14.1/subversion/bindings/swig/python/tests/run_all.py", line 23, in <module>
>>     import mergeinfo, core, client, delta, checksum, pool, fs, ra, wc, repository, \
>>   File "/wrkdirs/usr/ports/devel/py-subversion/work-py37/subversion-1.14.1/subversion/bindings/swig/python/tests/mergeinfo.py", line 22, in <module>
>>     from svn import core, repos, fs
>>   File "/wrkdirs/usr/ports/devel/py-subversion/work-py37/subversion-1.14.1/subversion/bindings/swig/python/svn/core.py", line 26, in <module>
>>     from libsvn.core import *
>>   File "/wrkdirs/usr/ports/devel/py-subversion/work-py37/subversion-1.14.1/subversion/bindings/swig/python/libsvn/core.py", line 26, in <module>
>>     from . import _core
>> ImportError: cannot import name '_core' from 'libsvn' (/wrkdirs/usr/ports/devel/py-subversion/work-py37/subversion-1.14.1/subversion/bindings/swig/python/libsvn/__init__.py)
>> *** [check-swig-py] Error code 1
>>
>
> I tried to reproduce, but I couldn't reproduce the issue.
>
> Did there exist subversion/bindings/swig/python/.libs/_core.so?

Yes.

> How about subversion/libsvn_client/.libs/libsvn_client-1.so.0, etc?
No. But it didn't exist for 1.14.0 too.

> I did below on FreeBSD 12.2:
> [[[
> tar xpf /usr/ports/distfiles/subversion-1.14.1.tar.bz2
> mkdir out-of-tree-svn-1.14.1
> cd out-of-tree-svn-1.14.1
> env PYTHON=/usr/local/bin/python3.7 sh ../subversion-1.14.1/configure \
> --with-sqlite=/usr/local \
> --with-expat=/usr/local/include:/usr/local/lib:expat --without-swig \
> --with-apr=/usr/local/bin/apr-1-config \
> --with-apr-util=/usr/local/bin/apu-1-config \
> --without-gnome-keyring --without-kwallet \
> --with-apxs=/usr/local/sbin/apxs \
> --prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man \
> --infodir=/usr/local/info --with-py3c=/usr/local
> make check-swig-py
> ]]]
> and it passed the test.

As you know about FreeBSD, try to build `devel/py-subversion' from fresh port tree. You'll get error. Revert ports tree to before 1.14.1 import and try again. No error.

Really, new "from . import _XXX" causes problem. I've patched all subversion/bindings/swig/python/*.py files and it helps. I'm not python programmer and I don't know what is difference between old "import _XXX" and new "from . import _XXX", but it helps.

> (Note: if source tree subversion-1.14.1 is not clean, "make swig-py"
> stopped with error before building Python bindings.)
>
> Result of ldd _core.so:
> [[[
> $ ldd subversion/bindings/swig/python/.libs/_core.so

[[[
> ldd ./work-py37/subversion-1.14.1/subversion/bindings/swig/python/.libs/_core.so
./work-py37/subversion-1.14.1/subversion/bindings/swig/python/.libs/_core.so:
libsvn_swig_py-1.so.0 => /usr/home/lev/FreeBSD/ports/devel/py-subversion/work-py37/subversion-1.14.1/subversion/bindings/swig/python/libsvn_swig_py/.libs/libsvn_swig_py-1.so.0 (0x800727000)
libsvn_client-1.so.0 => /usr/local/lib/libsvn_client-1.so.0 (0x80073f000)
libsvn_wc-1.so.0 => /usr/local/lib/libsvn_wc-1.so.0 (0x800e00000)
libsvn_ra-1.so.0 => /usr/local/lib/libsvn_ra-1.so.0 (0x8007d1000)
libsvn_delta-1.so.0 => /usr/local/lib/libsvn_delta-1.so.0 (0x800eb1000)
libaprutil-1.so.0 => /usr/local/lib/libaprutil-1.so.0 (0x800ed3000)
libsvn_diff-1.so.0 => /usr/local/lib/libsvn_diff-1.so.0 (0x8007e1000)
libsvn_subr-1.so.0 => /usr/local/lib/libsvn_subr-1.so.0 (0x800f02000)
libapr-1.so.0 => /usr/local/lib/libapr-1.so.0 (0x800f9c000)
libthr.so.3 => /lib/libthr.so.3 (0x800fdd000)
libc.so.7 => /lib/libc.so.7 (0x80024e000)
libsvn_ra_local-1.so.0 => /usr/local/lib/libsvn_ra_local-1.so.0 (0x80100a000)
libsvn_repos-1.so.0 => /usr/local/lib/libsvn_repos-1.so.0 (0x801016000)
libsvn_fs-1.so.0 => /usr/local/lib/libsvn_fs-1.so.0 (0x801057000)
libsvn_fs_fs-1.so.0 => /usr/local/lib/libsvn_fs_fs-1.so.0 (0x801067000)
libsvn_fs_x-1.so.0 => /usr/local/lib/libsvn_fs_x-1.so.0 (0x8010be000)
libsvn_fs_util-1.so.0 => /usr/local/lib/libsvn_fs_util-1.so.0 (0x801115000)
libsvn_ra_svn-1.so.0 => /usr/local/lib/libsvn_ra_svn-1.so.0 (0x80111a000)
libsvn_ra_serf-1.so.0 => /usr/local/lib/libsvn_ra_serf-1.so.0 (0x801143000)
libserf-1.so.1 => /usr/local/lib/libserf-1.so.1 (0x801179000)
libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x8011b8000)
libz.so.6 => /lib/libz.so.6 (0x8011e5000)
libsqlite3.so.0 => /usr/local/lib/libsqlite3.so.0 (0x801201000)
libmagic.so.4 => /usr/lib/libmagic.so.4 (0x8013a5000)
liblz4.so.1 => /usr/local/lib/liblz4.so.1 (0x8013cf000)
libutf8proc.so.2 => /usr/local/lib/libutf8proc.so.2 (0x8013fd000)
libintl.so.8 => /usr/local/lib/libintl.so.8 (0x801452000)
libcrypt.so.5 => /lib/libcrypt.so.5 (0x801461000)
libssl.so.111 => /usr/lib/libssl.so.111 (0x801482000)
libcrypto.so.111 => /lib/libcrypto.so.111 (0x80151a000)
libm.so.5 => /lib/libm.so.5 (0x80180c000)
]]]

[Lev Serebryakov]

On 16.02.2021 20:15, Nathan Hartman wrote:

>>
>>
>> Update to 1.14.1 break out-of-tree build of python bindings (with python 3.7).
>
>
> Are you building from a distribution tarball? (As opposed to a
> checkout or export of the 1.14.1 tag in our repository...) If so, did
> you run autogen.sh? I noticed some changes in

I'm using distribution tarball, `autogen.sh` was not run.

> subversion/bindings/swig/INSTALL on trunk that haven't been backported
> to 1.14.x. It's possible they (or some of them) should be backported.
> You can generate a diff to view the changes with:
>
> $ svn diff \
> https://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/swig/INSTALL
> \
> https://svn.apache.org/repos/asf/subversion/tags/1.14.1/subversion/bindings/swig/INSTALL
>
> Since your system shows the issue and Yasuhito couldn't reproduce it,
> would you be able to run a bisect on the 1.14.x branch, between
> r1877950 and r1886195 to identify which backport commit introduces the
> problem? That would be an immense help.

I found cause, but as I'm not python programmer, I don't understand it.

Old "import _XXX" (like "import _core" in subversion/bindings/swig/python/core.py) works, new "from . import XXX" doesn't.

I've patched these lines in 8 files (all in subversion/bindings/swig/python/) and it helps. But I don't know why :)

Please note, that I've changed only these lines, I didn't revert whole changes (which is much larger) around these lines.

[Nathan Hartman]

On Tue, Feb 16, 2021 at 12:32 PM Lev Serebryakov <l...@serebryakov.spb.ru> wrote:
> I found cause, but as I'm not python programmer, I don't understand it.
>
> Old "import _XXX" (like "import _core" in subversion/bindings/swig/python/core.py) works, new "from . import XXX" doesn't.
>
> I've patched these lines in 8 files (all in subversion/bindings/swig/python/) and it helps. But I don't know why :)
>
> Please note, that I've changed only these lines, I didn't revert whole changes (which is much larger) around these lines.

Thank you! That is immensely helpful. Now we can check when and why
that change was introduced.

Nathan

[Daniel Shahaf]

Nathan Hartman wrote on Tue, 16 Feb 2021 17:15 +00:00:
> You can generate a diff to view the changes with:
>
> $ svn diff \
> https://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/swig/INSTALL\
> https://svn.apache.org/repos/asf/subversion/tags/1.14.1/subversion/bindings/swig/INSTALL

For the archives, here it is again with a peg revision for future-proofing:

$ svn diff \
https://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/swig/INSTALL@r1886601 \
https://svn.apache.org/repos/asf/subversion/tags/1.14.1/subversion/bindings/swig/INSTALL

[Yasuhito FUTATSUKI]

In article <CAJT2EHpwhhwvJuWwS5A506MGTWimtM=hZY9xKA+8...@mail.gmail.com>

However, I don't think it is not an issue of Subversion release tarball
but an issue of FreeBSD ports.

Perhaps symbolic links were missing. "from . import XXX" specifies
relative import from a module.

[[[
$ ls -l subversion/bindings/swig/python/libsvn/*.so
lrwxr-xr-x 1 futatuki staff7 19 Feb 17 01:34 subversion/bindings/swig/python/libsvn/_client.so@ -> ../.libs/_client.so
lrwxr-xr-x 1 futatuki staff7 17 Feb 17 01:34 subversion/bindings/swig/python/libsvn/_core.so@ -> ../.libs/_core.so
lrwxr-xr-x 1 futatuki staff7 18 Feb 17 01:34 subversion/bindings/swig/python/libsvn/_delta.so@ -> ../.libs/_delta.so
lrwxr-xr-x 1 futatuki staff7 17 Feb 17 01:34 subversion/bindings/swig/python/libsvn/_diff.so@ -> ../.libs/_diff.so
lrwxr-xr-x 1 futatuki staff7 15 Feb 17 01:34 subversion/bindings/swig/python/libsvn/_fs.so@ -> ../.libs/_fs.so
lrwxr-xr-x 1 futatuki staff7 15 Feb 17 01:34 subversion/bindings/swig/python/libsvn/_ra.so@ -> ../.libs/_ra.so
lrwxr-xr-x 1 futatuki staff7 18 Feb 17 01:34 subversion/bindings/swig/python/libsvn/_repos.so@ -> ../.libs/_repos.so
lrwxr-xr-x 1 futatuki staff7 15 Feb 17 01:34 subversion/bindings/swig/python/libsvn/_wc.so@ -> ../.libs/_wc.so
]]]

On install, *.so modules will be installed in the same directory in
libsvn/*.py, so I think they works without trouble.

(I'm sorry, but I didn't try fresh ports tree yet because I'm using custom
ports which support both of Python 2 bindings and Python 3 bindings.)

Cheers,
--
Yasuhito FUTATSUKI <futa...@yf.bsdclub.org>

[futa...@yf.bsdclub.org]

In article <CAJT2EHoec7yx=hZfRijC=xoxD=+0duivPb3D9u...@mail.gmail.com>

hartman...@gmail.com writes:

> Are you building from a distribution tarball? (As opposed to a
> checkout or export of the 1.14.1 tag in our repository...) If so, did
> you run autogen.sh? I noticed some changes in
> subversion/bindings/swig/INSTALL on trunk that haven't been backported
> to 1.14.x. It's possible they (or some of them) should be backported.
> You can generate a diff to view the changes with:

Recent changes on subversion/bindings/swig/INSTALL linked with changes
on the configure script. So I'm sure the file in 1.14.1 release tarball
is corresponding to 1.14.1.

If r1878379, r1883719, r1883722, r1884610 group are backported,
then the INSTALL file will also be updated.

[Yasuhito FUTATSUKI]

In article <2102170359...@mkii.yf.bsdclub.org>

futa...@yf.bsdclub.org writes:

> However, I don't think it is not an issue of Subversion release tarball
> but an issue of FreeBSD ports.

This may be incorrect. It seems it is caused by wrong rule of
copy-swig-py: target.

> Perhaps symbolic links were missing. "from . import XXX" specifies
> relative import from a module.
>
> [[[
> $ ls -l subversion/bindings/swig/python/libsvn/*.so
> lrwxr-xr-x 1 futatuki staff7 19 Feb 17 01:34 subversion/bindings/swig/python/libsvn/_client.so@ -> ../.libs/_client.so
> lrwxr-xr-x 1 futatuki staff7 17 Feb 17 01:34 subversion/bindings/swig/python/libsvn/_core.so@ -> ../.libs/_core.so
> lrwxr-xr-x 1 futatuki staff7 18 Feb 17 01:34 subversion/bindings/swig/python/libsvn/_delta.so@ -> ../.libs/_delta.so
> lrwxr-xr-x 1 futatuki staff7 17 Feb 17 01:34 subversion/bindings/swig/python/libsvn/_diff.so@ -> ../.libs/_diff.so
> lrwxr-xr-x 1 futatuki staff7 15 Feb 17 01:34 subversion/bindings/swig/python/libsvn/_fs.so@ -> ../.libs/_fs.so
> lrwxr-xr-x 1 futatuki staff7 15 Feb 17 01:34 subversion/bindings/swig/python/libsvn/_ra.so@ -> ../.libs/_ra.so
> lrwxr-xr-x 1 futatuki staff7 18 Feb 17 01:34 subversion/bindings/swig/python/libsvn/_repos.so@ -> ../.libs/_repos.so
> lrwxr-xr-x 1 futatuki staff7 15 Feb 17 01:34 subversion/bindings/swig/python/libsvn/_wc.so@ -> ../.libs/_wc.so
> ]]]
>
> On install, *.so modules will be installed in the same directory in
> libsvn/*.py, so I think they works without trouble.
>
> (I'm sorry, but I didn't try fresh ports tree yet because I'm using custom
> ports which support both of Python 2 bindings and Python 3 bindings.)

I tried it and found:
[[[
$ ls -l subversion/bindings/swig/python/libsvn/*.so
lrwxr-xr-x 1 futatuki staff7 13 Feb 17 05:12 subversion/bindings/swig/python/libsvn/*.so@ -> ../.libs/*.so
]]]

If copy-swig-py target executed before building
subversion/bindings/swig/python/.lib/*.so, this can be occured.

[Lev Serebryakov]

On 16.02.2021 21:59, Yasuhito FUTATSUKI wrote:

>> Thank you! That is immensely helpful. Now we can check when and why
>> that change was introduced.
>
> However, I don't think it is not an issue of Subversion release tarball
> but an issue of FreeBSD ports.

This issue is result to update to 1.14.1. I didn't change anything but version bump, new checksum and removal of patch to configure script which was added after 1.14.0 release, and is completely incorporated into 1.14.1 release tarball now.

> Perhaps symbolic links were missing. "from . import XXX" specifies
> relative import from a module.
>
> [[[
> $ ls -l subversion/bindings/swig/python/libsvn/*.so
> lrwxr-xr-x 1 futatuki staff7 19 Feb 17 01:34 subversion/bindings/swig/python/libsvn/_client.so@ -> ../.libs/_client.so
> lrwxr-xr-x 1 futatuki staff7 17 Feb 17 01:34 subversion/bindings/swig/python/libsvn/_core.so@ -> ../.libs/_core.so
> lrwxr-xr-x 1 futatuki staff7 18 Feb 17 01:34 subversion/bindings/swig/python/libsvn/_delta.so@ -> ../.libs/_delta.so
> lrwxr-xr-x 1 futatuki staff7 17 Feb 17 01:34 subversion/bindings/swig/python/libsvn/_diff.so@ -> ../.libs/_diff.so
> lrwxr-xr-x 1 futatuki staff7 15 Feb 17 01:34 subversion/bindings/swig/python/libsvn/_fs.so@ -> ../.libs/_fs.so
> lrwxr-xr-x 1 futatuki staff7 15 Feb 17 01:34 subversion/bindings/swig/python/libsvn/_ra.so@ -> ../.libs/_ra.so
> lrwxr-xr-x 1 futatuki staff7 18 Feb 17 01:34 subversion/bindings/swig/python/libsvn/_repos.so@ -> ../.libs/_repos.so
> lrwxr-xr-x 1 futatuki staff7 15 Feb 17 01:34 subversion/bindings/swig/python/libsvn/_wc.so@ -> ../.libs/_wc.so
> ]]]

Yep, there is this *one* "funny" link:

[[[
> ls -l work-py37/subversion-1.14.1/subversion/bindings/swig/python/libsvn/*.so
lrwxr-xr-x 1 lev lev 13 16 Feb 20:26 work-py37/subversion-1.14.1/subversion/bindings/swig/python/libsvn/*.so -> ../.libs/*.so
]]]

But it means, that it was created by subversion build system (not port!), and it means here is some subtle bug in this system. Looks like, target `copy-swig-py` is called BEFORE build of libraries. But Makefile / build-outputs.mk is complex enough and I could not trace why. Maybe, it is parallel job problem?

YESSSS! I catch it. When I build port jobs disabled ordering is right:

[[[
> ls -l work-py37/subversion-1.14.1/subversion/bindings/swig/python/libsvn/*.so
lrwxr-xr-x 1 lev lev 19 17 Feb 00:13 work-py37/subversion-1.14.1/subversion/bindings/swig/python/libsvn/_client.so -> ../.libs/_client.so
lrwxr-xr-x 1 lev lev 17 17 Feb 00:13 work-py37/subversion-1.14.1/subversion/bindings/swig/python/libsvn/_core.so -> ../.libs/_core.so
lrwxr-xr-x 1 lev lev 18 17 Feb 00:13 work-py37/subversion-1.14.1/subversion/bindings/swig/python/libsvn/_delta.so -> ../.libs/_delta.so
lrwxr-xr-x 1 lev lev 17 17 Feb 00:13 work-py37/subversion-1.14.1/subversion/bindings/swig/python/libsvn/_diff.so -> ../.libs/_diff.so
lrwxr-xr-x 1 lev lev 15 17 Feb 00:13 work-py37/subversion-1.14.1/subversion/bindings/swig/python/libsvn/_fs.so -> ../.libs/_fs.so
lrwxr-xr-x 1 lev lev 15 17 Feb 00:13 work-py37/subversion-1.14.1/subversion/bindings/swig/python/libsvn/_ra.so -> ../.libs/_ra.so
lrwxr-xr-x 1 lev lev 18 17 Feb 00:13 work-py37/subversion-1.14.1/subversion/bindings/swig/python/libsvn/_repos.so -> ../.libs/_repos.so
lrwxr-xr-x 1 lev lev 15 17 Feb 00:13 work-py37/subversion-1.14.1/subversion/bindings/swig/python/libsvn/_wc.so -> ../.libs/_wc.so
]]]

So, there IS bug in subversion Makefiles: building of python bindings (at least, maybe more!) with `make -j ${NCPU}` is not serialized right.

[Lev Serebryakov]

On 16.02.2021 23:52, Yasuhito FUTATSUKI wrote:
>

>> However, I don't think it is not an issue of Subversion release tarball
>> but an issue of FreeBSD ports.
>
> This may be incorrect. It seems it is caused by wrong rule of
> copy-swig-py: target.

Yep, it is wrong in case of multi-job build. It works for single-job non-parallel build on FreeBSD.

Quick fix for FreeBSD ports will be to disable parallel build of bindings.

[Yasuhito FUTATSUKI]

Thank you for the confirmation. I've commited the fix of dependency rule
on trunk[1]. Then I'll nominate it to backport for 1.14.x branch.

Also I attached a patch against 1.14.x branch which is expected to
be applied to 1.14.1 clearly.

[1] https://svn.apache.org/viewvc?view=revision&revision=1886708