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
Setting DYLD_LIBRARY_PATH causes configure to fail #8229
Comments
That doesn't fix it. You're still setting What problem was ba0657c trying to solve? It mentions a "non-standard installation of openssl" but does not elaborate what that means. Could it perhaps be a broken installation of openssl that curl needn't concern itself with supporting? Any installed library that requires you to set |
When you tell configure to look for a library at a custom location and it finds it to be there - it uses the linker to verify that the library is there and works to link with. Later in the configure script, it will run an executable for some tests. When configure runs an executable the previously detected libraries need to be found at run-time as opposed to build-time. That's what it sets the variable for. Why does it find the library in the non-standard directory |
If I install a build of a library in |
Your problem is probably that you're using one library in that directory but then you also have other libs in that directory that are using the same names as ones you have in another path, and you only want that one lib used from that directory. I might be naive but that sounds like a recipe just waiting for problems like this. I don't have a short term fix for a setup like that, other than perhaps avoid having configure detect that directory specifically. |
My problem is that the curl build system is setting
Yes, MacPorts installs libs primarily in /opt/local/lib, just as most other package managers I expect primarily install their libs in their own prefix or like a user might install several libraries in /usr/local. MacPorts has done so since 2002. It is not a problem.
It is the decision of the developers of libiconv that a "third party" build (such as the one in MacPorts) shall have symbols beginning with
I do not understand why setting Again, I'd like to understand what specific issue the commit that introduced the problem was meant to correct.
The install_name of the library should be set to its absolute install path. Then setting |
#8028 is why |
I saw #8028 but it does not explain what is meant by "non-standard installation of openssl". |
I presume that means you build openssl with something like:
|
I can't see how setting |
It sounds (after casually reading this thread and without any particular
knowledge of Mac OS builds) that the argument here is that Mac OS automatically
uses the equivalent of GNU's -rpath on binaries so setting an environment
variable shouldn't be necessary to find a library. But, if that's the case,
what happened in #8028 to cause that mechanism to fail?
|
I failed to configure 7.81.0 on macOS, with libjpeg in my case. I remembered that |
Does it help if we change it to use |
Sure, that would avoid the problem, but it's still unclear why setting any variable would be needed. |
Setting [*] Well, fine, you can use it for debugging purposes if you want to highjack the libraries an executable intends to link against. The use of the term "highjack" here is intentional -- there is a reason why binaries that live in SIPed directories (e.g. |
@jay Thanks for mentioning me. Sorry for breaking your build. I will verify why the |
Ok, was able to reproduce the old problem now. We call
The compilation of
which results in
The contents of the openssl installation directory is
What are we doing wrong here? Of course I can set |
Ok, so your build of openssl was created using If you want to use your |
Setting But indeed, the openssl build system is patched by us:
That explains why the problem happens only here. Unfortunately, setting |
I'm told you can set multiple rpaths, e.g.
|
Passing To use
The latter |
Thanks for all that useful information. I'm not a Mac expert, my home is Linux
That's true, but the shell executing the configure script is from Apple and cleans However, adding
Any ideas? |
Googling this error, I found the suggestion to use |
Right, there shouldn't be any reason why anyone would need to set a |
This works indeed. I think that's the best solution for me. Thanks for all the hints and explanations. |
Thanks for your extensive help here. @ryandesign @bwncp I presume you are then fine with #8247 ? |
Yes, you can close the issue from my point of view, reverting my commit is ok. |
Yes that works for me, thanks! |
I'm the maintainer of curl in MacPorts. I tried updating curl in MacPorts from 7.80.0 to 7.81.0 which failed for me on macOS 10.15.7. The error is:
config.log shows us this is because:
This means that something that's being used here links with /usr/lib/libarchive.2.dylib, and /usr/lib/libarchive.2.dylib links with /usr/lib/libiconv.2.dylib:
But the build system has set
DYLD_LIBRARY_PATH=/opt/local/lib
thereby telling the operating system that any libraries that exist in /opt/local/lib should be used instead of the ones that would normally be used (e.g. in /usr/lib). But /usr/lib/libiconv.2.dylib and /opt/local/lib/libiconv.2.dylib are not interchangeable. /usr/lib/libiconv.2.dylib is a "vendor build" and /opt/local/lib/libiconv.2.dylib is a "third party" build. They deliberately have different symbol names so that they do not collide.I don't know what your build system is trying to do with
DYLD_LIBRARY_PATH
but this failure demonstrates why you must never setDYLD_LIBRARY_PATH
to a directory that contains libraries that are outside your control. The only valid thing to do withDYLD_LIBRARY_PATH
is to set it to a directory where you have just built your libraries that you have not installed yet but that you wish to use to run a program that you just built.curl 7.80.0 didn't have this problem. The problem was introduced in ba0657c. Reverting that fixes the problem for me.
The text was updated successfully, but these errors were encountered: