-
Notifications
You must be signed in to change notification settings - Fork 60
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
Trying to be smarter than autotools #1
Comments
If you can find the flag to make autotools build libraries with RPATH linkage, then please go ahead and fix it. |
It should be automatically added on systems where it's supported. I'm guessing this wasn't the case for you? |
It has been the case at one point or another, though I haven't tried recently (and perhaps it depends on whether you pass I suggest changing the default of the |
okay, that seems like a reasonable compromise :) I think we may also need to move the rpath function somewhere else, since On Tue, Oct 8, 2013 at 12:21 PM, Dag Sverre Seljebotn <
|
Yes, that was the intention, just never got around to it. There's support to specify |
I don't think I ever managed to get rpath working with autotools without forcing it. |
Update to latest hashstack master, add Jasper host package on Cygwin
add verify functionality to matplotlib build
set MAX_JBUFS=24 in parmetis on OS X
Looking at the code in
autotools_package.py
, I see explicit hardcoding with a hook function for rpath support on Linux.In general, I would be more comfortable if our default behavior was to trust the build system (in this case, modern autotools should do a pretty good job of building the right thing on both Linux and OS X), instead of trying to be smarter than it. I'm really not interested in reinventing all the work that goes into autotools, CMake, etc...
Thoughts from others?
The text was updated successfully, but these errors were encountered: