On 3. 5. 26 15:16, Branko Čibej wrote:
On 29. 4. 26 09:57, Branko Čibej wrote:
On 28. 4. 26 16:57, Branko Čibej wrote:
On 27. 4. 26 21:39, Evgeny Kotkov via dev wrote:
The 1.15.0-rc2 release artifacts are now available for testing/signing.
Please get the tarballs from
   https://dist.apache.org/repos/dist/dev/subversion
and add your signatures there.

Thanks!

+0 to release (Unix; macOS/arm64)
(+1 for release candidate but −1 for final release)

Note: Could be a configuration problem on macOS, but not too long ago the branch did build and test with DAV and svnserve.


Compiler: Apple clang version 17.0.0 (clang-1700.6.4.2)
Target: arm64-apple-darwin24.6.0 (Mac OS Sequoia 15.7.4)
Built in non-maintainer mode with default flags: -g -O2 -Wall


Tests:

check × FSFS: SUCCESS: All tests successful

svnserveautocheck × FSFS: ERROR: Tests did not run

davautocheck  × FSFS × prefork: ERROR: Python tests did not run


Other issues:

Compilation warning:
subversion/libsvn_subr/mergeinfo.c:820:1: warning: unused function 
'rangelist_to_string_debug' [-Wunused-function]
   820 | rangelist_to_string_debug(const svn_rangelist_t *rl,
       | ^~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.



Building swig-rb with Ruby 4.0.3, I got this compilation error:

subversion/bindings/swig/ruby/libsvn_swig_ruby/swigutil_rb.c:1641:38: error: 
use of undeclared identifier 'ruby_errinfo'; did you mean 'rb_errinfo'?
  1641 |                                      ruby_errinfo,
       |                                      ^~~~~~~~~~~~
       |                                      rb_errinfo


Testing swig-py with Python 3.14:

$ make -s check-swig-py
..................svn: fs-loader: E200029: Couldn't open rep-cache database 
'/var/folders/zv/qq43zzc547zcbm_h9k900hnh0000gn/T/tmpgym3eok7-mergeinfo/db/rep-cache.db'
svn: fs-loader: E200029: Couldn't perform atomic initialization
svn: E235000: In file 
'/Users/brane/src/svn/dist/src/subversion-1.15.0-rc2/subversion/libsvn_fs/fs-loader.c'
 line 465: internal malfunction
/bin/sh: line 1: 43093 Abort trap: 6           /opt/homebrew/bin/python3 
/Users/brane/src/svn/dist/src/subversion-1.15.0-rc2/subversion/bindings/swig/python/tests/run_all.py
make: *** [check-swig-py] Error 134

With some added tracing I tracked this down to:

.../subversion-1.15.0-rc2/subversion/libsvn_subr/sqlite.c:794: 
(apr_err=SVN_ERR_SQLITE_ERROR)
init-once: E200030: SQLite compiled for 3.53.0, but running with 3.43.2

So it's really a local configuration problem and I just have to see what I'm doing differently in the dist build compared to my usual builds. It's "interesting" that libsvn_subr appears to be linked to the correct version of SQLite:

$ otool -L libsvn_subr-1.dylib
libsvn_subr-1.dylib:
        /opt/dist-subversion-1.15.0-rc2/lib/libsvn_subr-1.0.dylib 
(compatibility version 1.0.0, current version 1.0.0)
        /opt/homebrew/opt/apr-util/lib/libaprutil-1.0.dylib (compatibility 
version 7.0.0, current version 7.3.0)
        /opt/homebrew/opt/apr/lib/libapr-1.0.dylib (compatibility version 
8.0.0, current version 8.6.0)
        /usr/lib/libexpat.1.dylib (compatibility version 7.0.0, current version 
8.0.0)
        /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 
1.2.12)
        /opt/homebrew/opt/sqlite/lib/libsqlite3.dylib (compatibility version 
9.0.0, current version 9.6.0)
        /opt/homebrew/opt/lz4/lib/liblz4.1.dylib (compatibility version 1.0.0, 
current version 1.10.0)
        /opt/homebrew/opt/utf8proc/lib/libutf8proc.3.dylib (compatibility 
version 3.0.0, current version 3.2.3)
        
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 
(compatibility version 150.0.0, current version 4201.0.0)
        /System/Library/Frameworks/Security.framework/Versions/A/Security 
(compatibility version 1.0.0, current version 61901.60.40)
        
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices 
(compatibility version 1.0.0, current version 1226.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1356.0.0)


I "fixed" this by rerunning autogen.sh on the extracted tarball, but that's not a good solution. Right now I have no idea what's different, except that the latest libtool works differntly enough from whichever version was used to create the release. Mine is

$ /opt/homebrew/bin/glibtool --version
glibtool (GNU libtool) 2.5.4



-- Brane

Reply via email to