cannot find -load: No such file or directory when linking shared libraries
hey3e opened this issue · 7 comments
Use export CFLAGS="-Xclang -load -Xclang /path/to/llvm.so" to instrument a llvm patch to LibreSSL.
During make, error occurs:
` CCLD libcrypto.la
/usr/bin/ld: cannot find -load: No such file or directory`
Can you link to some documentation on what you're trying to do? What is '-load'? It's not an easy thing to search for.
You can see more about what's happening here if you also run 'make V=1' to show the underlying command that gets invoked during this step.
I mean I'm trying to compile libressl with my custom llvm pass by setting CFLAGS to Xclang -load -Xclang /path/to/pass.so.
But during the make process, when it comes to
CCLD libcrypto.la
error occurs:
/usr/bin/ld: cannot find -load: No such file or directory
The underlying command of CCLD libcrypto.la is:
-Wl,--no-whole-archive -load -lresolv -fstack-protector-strong -Wl,-soname -Wl,libcrypto.so.51 -Wl,-version-script -Wl,.libs/libcrypto.ver -o .libs/libcrypto.so.51.0.0
which includes a -load while no pulgin after it. So it may cause the error.
In Makefile, there are only two variables contain -load: CFLAGS and CCASFLAGS, which are both -Xclang -load -Xclang /path/to/pass.so.
What I'm asking for is a link to documentation on what -Xclang -load -Xclang /path/to/llvm.so does, and why you think it would work in the first place. We're not clang internals experts here, so understanding what that is even expected to do is helpful.
Hope this documentation can help.
I think it would work because I tried it on OpenSSL successfully.
I tried the flags from your blog post, but couldn't get them to work on any version of clang I had around. The blog from 2014 says this is a legacy technique for adding compiler passes; I'd probably suggest you determine how to do this correctly with modern llvm as an easier path. You also appear to be poking other SSL projects such as this one: wolfSSL/wolfssl#6588, but I don't think it has anything to do with either of these projects build systems specifically.
To avoid having everyone have to look at this independently, let me suggest it's not a issue with LibreSSL or WolfSSL, but the common build tools, autoconf/autoconf/libtool, generally known as 'autotools' and how they use CFLAGS. OpenSSL is probably an exception these days in that it still uses its own bespoke build system, so you might have lucked out there if it worked. You'll likely run into this issue with any tool that uses './configure' as its first build step.
With autotools, as you found out, CFLAGS is passed to more than just the C compiler, since your error is coming from the linker. If libtool understands the flag, it can actually add or adjust flags for different tools automatically based on what they expect. I suspect since you're using what appear to be obsolete / undocumented flags, the build tools are not going to understand them either.
You probably have a few options to work around this. You might hack these into 'CPPFLAGS', which is intended for the C preprocessor, but might work to bypass the flag being sent to the linker. You might change the CFLAGS on specific files you want my modifying Makefile.am in the right place so it doesn't get run during the linking phases for other programs. You might check out https://www.gnu.org/software/automake/manual/html_node/Flag-Variables-Ordering.html and related documentation for other flags and possibilities.
Personally, I'd probably write a shell script that wraps the C compiler, and inject the flags there, then specific it with CC. Then you get full control of how the flags are managed and can inject them wherever you want. Good luck!
Thanks for your reply!