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

No static library in MacOS builds #648

Open
fontanf opened this issue Apr 17, 2024 · 11 comments
Open

No static library in MacOS builds #648

fontanf opened this issue Apr 17, 2024 · 11 comments

Comments

@fontanf
Copy link

fontanf commented Apr 17, 2024

Hi,

Is there a reason why the MacOS builds don't include static libraries (only .dylib files) while the Linux and Windows libraries both include shared and static libraries?

@jhmgoossens
Copy link
Contributor

No real reason, just not the full set of all possible combinations of OS versions, compilers, static yes/no, etc. Is there a need to include also the static variants for MacOS 13 and 14 builds?

@fontanf
Copy link
Author

fontanf commented Apr 17, 2024

I don't know. For now, I would mainly need a version that works with Github's pipelines. So the ones versions available in the release pages should be good

@jhmgoossens
Copy link
Contributor

Great!

@fontanf
Copy link
Author

fontanf commented Sep 5, 2024

I realize that I may have misunderstood your previous message, since I see that the recently published builds don't include static builds for Mac OS. Having static builds for Mac OS would be helpful to distribute binaries without additional .dylib files and the need to tweak the DYLD_LIBRARY_PATH environment variable.

@jhmgoossens jhmgoossens reopened this Sep 5, 2024
@jhmgoossens
Copy link
Contributor

I don’t see a problem to add a macOS-14 run that builds static libraries. I can simply add an entry to the build matrix for Linux-ci. @tkralphs Do you foresee any issues?

@jhmgoossens
Copy link
Contributor

Apparently it’s not trivial, since the #669 build failed for exactly the static macOS-14 build.

@tkralphs
Copy link
Member

tkralphs commented Sep 5, 2024

MacOS does not support producing what people usually call static binaries for the reasons explained here:

https://nelsonslog.wordpress.com/2013/04/24/macos-doesnt-support-static-binaries/

Getting static binaries on any Unix is not easy when you have a lot of library dependencies. It took some effort to get the Linux ones working. I tried with MacOS for a while and gave up after I realized the situation. Probably, you can get a binary that is pretty portable and has only a few library dependencies if you work at it, but coinbrew's recipe only works with Linux at the moment and that's what was enabled in #669 . If anyone is interested in trying to get things working, that would be great.

@svigerske
Copy link
Member

Tweaking libraries and binaries to find their dependencies in relative paths via the install_name_tool and @loader_path/@rpath/etc usually works fine. So the choices are not only between static libs or setting DYLD_LIBRARY_PATH.

@fontanf
Copy link
Author

fontanf commented Sep 10, 2024

We tried to set up our own mac builds here https://github.com/fontanf/coinor-builds

At first glance, it seems to work

@tkralphs
Copy link
Member

This looks promising, thanks! Unfortunately, I don't currently have access to my Mac (and won't anytime soon) to check the binaries, but I assume you did? Disabling lapack is a bit of a performance hit and since lapack is linked from the accelerate framework, which should always be available, maybe allowing that is OK.

By the way, you don't need to build each project separately. Building Cbc automatically builds all the dependencies. For some reason, it looks like Cbc is built three times, along with all its dependencies, but if I just integrate this into the coinbrew static build, then that's moot anyway. I'll try to play around with it when I get the chance.

@fontanf
Copy link
Author

fontanf commented Sep 13, 2024

These packages are used by my packing library and the Mac Intel and ARM pipelines work as well as before with these.

I didn't notice performance degradations. But here CLP is used to solve LP subproblems in a column generation algorithm where the bottleneck is clearly not the resolution of the LPs.

Each project is built separately because I may want to include additional packages later such as IpOpt, which has common dependencies.

Thank you for the hints. I'll see if we can improve the build

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

4 participants