search

coin-or / Cbc

COIN-OR Branch-and-Cut solver
Other
813 stars 115 forks source link

No static library in MacOS builds #648

Open fontanf opened 6 months ago

fontanf commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

Great!

fontanf commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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

tkralphs commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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

At first glance, it seems to work

tkralphs commented 1 month ago

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 commented 1 month ago

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