Skip to content
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

Static libraries is hard coded #18

Open
kpu opened this issue May 1, 2021 · 7 comments
Open

Static libraries is hard coded #18

kpu opened this issue May 1, 2021 · 7 comments

Comments

@kpu
Copy link
Contributor

kpu commented May 1, 2021

I understand static libraries can be a useful option, but hard coding only static libraries is bad practice.

set(CMAKE_FIND_LIBRARY_SUFFIXES .a)

For example, this won't compile on Gentoo by default with the error

CMake Error at CMakeLists.txt:70 (message):
  Cannot find pcre2 libraries.  Terminating.

even though libpcre2 is installed, just the dynamic version.

While it currently blames on @XapaJIaMnu, the history shows this is simply an indentation of code that started with @ugermann

@XapaJIaMnu
Copy link
Contributor

Ugh... So. Archlinux and Gentoo by default ship dynamic libs and if those are not found, static. You can change this behaviour in your ebuild.conf (or however it's called) and in makepkg.conf.

Most distros ship both, so I wouldn't blame @ugermann for not knowing arch and gentoo's behaviour, but you're right we should try to find .a and if not fallback to .so. We certainly want to package linux packages linked against .so

@kpu
Copy link
Contributor Author

kpu commented May 1, 2021

I'm aware that I can add USE="static-libs" for libpcre2 to get a static lib in gentoo. But I shouldn't have to.

@ugermann
Copy link
Owner

ugermann commented May 5, 2021

The cmake setup is now checking for both static and dynamic pcre2 libraries on *nix setups. Looking for volunteers to provide a gentoo / arch linux workflow.

@kpu
Copy link
Contributor Author

kpu commented May 5, 2021

And now you've broken OS X dynamic linking because that is .dylib. If you're going to do something sketchy, make it optional not the default.

@XapaJIaMnu
Copy link
Contributor

brew normally installs both so it's not an issue, but we can just add the dylib extension?

@kpu
Copy link
Contributor Author

kpu commented May 5, 2021

https://stackoverflow.com/questions/3762057/cmake-how-to-produce-binaries-as-static-as-possible

IF(WIN32)
    SET(CMAKE_FIND_LIBRARY_SUFFIXES .lib .a ${CMAKE_FIND_LIBRARY_SUFFIXES})
ELSE(WIN32)
    SET(CMAKE_FIND_LIBRARY_SUFFIXES .a ${CMAKE_FIND_LIBRARY_SUFFIXES})
ENDIF(WIN32)

I would also add that non-standard behavior should be an option and only sparingly the default.

IF(PREFER_STATIC)
  IF(WIN32)
      SET(CMAKE_FIND_LIBRARY_SUFFIXES .lib .a ${CMAKE_FIND_LIBRARY_SUFFIXES})
  ELSE(WIN32)
      SET(CMAKE_FIND_LIBRARY_SUFFIXES .a ${CMAKE_FIND_LIBRARY_SUFFIXES})
  ENDIF(WIN32)
ENDIF(PREFER_STATIC)

@XapaJIaMnu
Copy link
Contributor

I think we want prefer static 100% of the time for win32. It's preferable to have static build on mac just because we'd be distributing a. .app and not a brew package (or both). For linux it doesn't matter most of the time, I am not sure if wasm has any preferences.

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

No branches or pull requests

3 participants