Skip to content

cmake: Emulate Libtool's behavior on FreeBSD #1685

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

hebasto
Copy link
Member

@hebasto hebasto commented Jun 11, 2025

Building the master branch @ f24b838 on FreeBSD 14.3:

  • with Autotools:
$ ./autogen.sh
$ ./configure --disable-static --prefix /tmp/AUTOTOOLS
$ gmake
$ gmake install
$ tree /tmp/AUTOTOOLS/lib
/tmp/AUTOTOOLS/lib
├── libsecp256k1.la
├── libsecp256k1.so -> libsecp256k1.so.5.0.1
├── libsecp256k1.so.5 -> libsecp256k1.so.5.0.1
├── libsecp256k1.so.5.0.1
└── pkgconfig
    └── libsecp256k1.pc

2 directories, 5 files
  • with CMake:
$ cmake -B build -DCMAKE_INSTALL_PREFIX=/tmp/CMAKE
$ cmake --build build
$ cmake --install build
$ tree /tmp/CMAKE/lib
/tmp/CMAKE/lib
├── cmake
│   └── libsecp256k1
│       ├── libsecp256k1-config-version.cmake
│       ├── libsecp256k1-config.cmake
│       ├── libsecp256k1-targets-relwithdebinfo.cmake
│       └── libsecp256k1-targets.cmake
├── libsecp256k1.so -> libsecp256k1.so.5
├── libsecp256k1.so.5
└── pkgconfig
    └── libsecp256k1.pc

4 directories, 7 files

With this PR:

$ cmake -B build -DCMAKE_INSTALL_PREFIX=/tmp/CMAKE+PR
$ cmake --build build
$ cmake --install build
$ tree /tmp/CMAKE+PR/lib
/tmp/CMAKE+PR/lib
├── cmake
│   └── libsecp256k1
│       ├── libsecp256k1-config-version.cmake
│       ├── libsecp256k1-config.cmake
│       ├── libsecp256k1-targets-relwithdebinfo.cmake
│       └── libsecp256k1-targets.cmake
├── libsecp256k1.so -> libsecp256k1.so.5
├── libsecp256k1.so.5 -> libsecp256k1.so.5.0.1
├── libsecp256k1.so.5.0.1
└── pkgconfig
    └── libsecp256k1.pc

4 directories, 8 files

From FreeBSD Developers' Handbook:

If you are adding shared library support to a port or other piece of software that does not have one, the version numbers should follow these rules. Generally, the resulting numbers will have nothing to do with the release version of the software.

For ports:

  • Prefer using the number already selected by upstream

  • If upstream provides symbol versioning, ensure that we use their script

Copy link
Contributor

@real-or-random real-or-random left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK 37dd422

@real-or-random
Copy link
Contributor

What do you think about the alternative version of making this the else branch if neither on Windows nor on macOS?

@hebasto
Copy link
Member Author

hebasto commented Jun 11, 2025

What do you think about the alternative version of making this the else branch if neither on Windows nor on macOS?

That was my initial thought too. However, shared library naming conventions differ on other systems, such as OpenBSD and NetBSD. So I chose the current approach to self‑document which systems are tested.

@hebasto
Copy link
Member Author

hebasto commented Jun 11, 2025

What do you think about the alternative version of making this the else branch if neither on Windows nor on macOS?

That was my initial thought too. However, shared library naming conventions differ on other systems, such as OpenBSD and NetBSD. So I chose the current approach to self‑document which systems are tested.

I've included a reference to the FreeBSD docs in the PR description.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants