Fossil Forum

Question on with-openssl and with-tcl order in auto.def
Login

Question on with-openssl and with-tcl order in auto.def

Chronological

Question on with-openssl and with-tcl order in auto.def

(1) By Preben Guldberg (preben) on 2023-11-25 18:27:32 [link] [source]

Would it be safe to move the code handling the --with-tcl up before the ssl tests for --with-openssl?

This is relevant to my macOs (13.5.2) system when I compile in Tcl support. The system comes with Tcl 8.5, so I use home-brew to get Tcl 8.6.

By default, either of configure commands these fail:

    ./configure --with-tcl=/opt/homebrew/Cellar/tcl-tk/8.6.13_5
    ./configure --with-tcl=/opt/homebrew/Cellar/tcl-tk/8.6.13_5 --with-tcl-stubs=1

Both fail as a test compilation with -lssl fails:

    Failed: cc -g -O2 -I/opt/homebrew/Cellar/tcl-tk/8.6.13_5/include/tcl-tk -g0 conftest__.c -o conftest__ -L/opt/homebrew/Cellar/tcl-tk/8.6.13_5/lib -ltclstub8.6 -lpthread -liconv -lssl -lcrypto -lz
    ld: library 'ssl' not found
    clang: error: linker command failed with exit code 1 (use -v to see invocation)
    child process exited abnormally

If I use --with-tcl-private-stubs=1, configure works:

    ./configure --with-tcl=/opt/homebrew/Cellar/tcl-tk/8.6.13_5 --with-tcl-private-stubs=1

However, the compiled fossil command loads Tcl 8.5:

    % ./fossil version -v
    This is fossil version 2.24 [232cda61df] 2023-11-25 13:00:40 UTC
    Compiled on Nov 25 2023 19:20:20 using clang-15.0.0 (clang-1500.0.40.1) (64-bit)
    SQLite 3.44.0 2023-11-01 11:23:50 17129ba1ff
    SSL (OpenSSL 3.1.4 24 Oct 2023)
    zlib 1.2.12, loaded 1.2.11
    TCL (Tcl 8.6.13, loaded TH_OK: 8.5.9)

If I move move the order of tests in auto.def so that tcl is tested before openssl, it works:

    % ./configure --with-tcl=/opt/homebrew/Cellar/tcl-tk/8.6.13_5
    % make clean
    [...]
    % make fossil
    [...]
    % ./fossil version -v
    This is fossil version 2.24 [232cda61df] 2023-11-25 13:00:40 UTC
    Compiled on Nov 25 2023 19:24:10 using clang-15.0.0 (clang-1500.0.40.1) (64-bit)
    SQLite 3.44.0 2023-11-01 11:23:50 17129ba1ff
    SSL (OpenSSL 3.1.4 24 Oct 2023)
    zlib 1.2.12, loaded 1.2.11
    TCL (Tcl 8.6.13, loaded TH_OK: 8.6.13)

I am not sure if such a change would break anything across various systems, though.

(2) By Warren Young (wyoung) on 2023-11-28 04:45:53 in reply to 1 [source]

Since this has gone unremarked on, I'll offer some generalities.

Most of those lines (558+) haven't changed in a decade, and the newest change is from 7 years ago. Whether that means they're really stable and shouldn't change or that it means they will be equally stable in a new location is a question open to experimentation.

Sometimes there are ordering dependencies, both directions: the old way is important and shouldn't change, or the old way breaks new platforms and needs to change in a way that doesn't break other things.

I suggest you put the change on a branch and call for testers. If we get enough successful builds on enough different VMs, I'll vote for merging it down to trunk.

(3) By Preben Guldberg (preben) on 2023-12-03 14:14:19 in reply to 2 [link] [source]

Thanks for the advice.

Looking further, I realised that other tests failed in a similar fashion.

Problem is that the CFLAGS and LDFLAGS found for openssl using pkg-config were not used in further tests compiled with -lssl. They were used for the generated Makefile, though, so compiling fossil with -lssl would work.

I have updated auto.def in the auto-def-compilation-flags branch.

This works well on my macOS now as well as linux and BSD hosts.

(4) By Warren Young (wyoung) on 2023-12-05 17:00:33 in reply to 3 [link] [source]

I've successfully tested "make reconfig && make all" on:

  • CentOS 9, 8, 7, and 61
  • FreeBSD 12 and 14
  • Ubuntu 22.04 LTS
  • Debian 12
  • macOS 14
  1. ^ RHEL 5 type OSes stopped building Fossil somewhere in the 2.21 to 2.22 transition due to a change in SQLite to start using LLONG_MAX, which doesn't exist in this old GCC/glibc.

(5) By Preben Guldberg (preben) on 2024-01-02 17:00:34 in reply to 4 [link] [source]

Thanks Warren.

I have been using this in a number of tests across various BSDs, Linux, macOS, SunOS and Cygwin systems since without issues.

I did a comparison test where I

  1. Used fossil trunk as of early today
  2. On the mix of hosts above, used configure --json --with-th1-docs --with-th1-hooks plus suitable configure options to include TCL on the system
  3. Saved all resulting Makefile and autoconfig.h files
  4. Merged in the auto-def-compilation-flags branch
  5. Repeated the test

The results:

  • macOS failed to configure on trunk, but succeeded after the merge
  • All other hosts succeeded before and after merging
  • No change in autoconfig.h for all non-macOS hosts
  • After the merge, the Makefile added a suitable -IPATH for TCL to CFLAGS on all non-macOS hosts
  • On Dragonfly BSD, an extra (duplicate) -LPATH was added to LIB in the Makefile (again for TCL)

Any objections to merging/integrating the auto-def-compilation-flags branch to trunk?

(6) By Warren Young (wyoung) on 2024-01-02 18:18:28 in reply to 5 [link] [source]

Any objections

I believe we can take a month of silence as an implicit "no." :)

(7) By Preben Guldberg (preben) on 2024-01-02 22:03:05 in reply to 6 [link] [source]

I'll take that :-)

Thank you.