Clang not creating object files when using plugin - file

I'm trying to use clang++ instead of g++ to create object files that will later be linked by the gnu linker.
I'm am able to do this successfully using native clang++, but when I use clang++ with a plugin, I get a link error:
clang: error: linker command failed with exit code 1 (use -v to see invocation)
That's okay! I just need the object files! However, when I specify -S or -c I do not get any object file, even if I use .o to explicitly specify an output file.
I am unable to do this even with clang's example plugins.
How can I get clang to give an object file?
Much Thanks!

I had this same issue. For me, replacing "-plugin" with "-add-plugin" on my command line fixed the problem. I'm not sure what the difference is or why it worked, but it did.
Also, if you are using "-cc1" on the command line, try removing it and prefixing every plugin specific argument with "-Xclang ", i.e. "clang -Xclang -load -Xclang plugin.so -Xclang -add-plugin -Xclang pluginName". Again, I'm not sure why -cc1 wasn't working for me, but it wasn't and this fixed it.

Related

Static library not linking when using -l and -L flags?

So, I have a static library called libtree-sitter.a that I'm trying to use. Here is the compilation command from the documentation:
clang \
-I tree-sitter/lib/include \
test-json-parser.c \
tree-sitter-json/src/parser.c \
tree-sitter/libtree-sitter.a \
-o test-json-parser
The above command successfully compiles and the executable works correctly. I tried changing the loading of the static library into flags so I could make my build system more generic. My changes are below:
clang \
-I tree-sitter/lib/include \
test-json-parser.c \
tree-sitter-json/src/parser.c \
-o test-json-parser \
-Ltree-sitter -ltree-sitter
This compiles, but running the executable gives this error:
dyld: Library not loaded: /usr/local/lib/libtree-sitter.0.dylib
Referenced from: /Users/jason/Downloads/tree sitter test/test-json-parser
Reason: image not found
Can someone please explain the difference between those two examples? From my understanding of -l and -L, it should still find the library in the same place. What is an equivalent combination of flags so I can make loading libraries more generic and easily integrable with Makefile templates (I am using this one)? Thanks for reading.
Your error message says:
dyld: Library not loaded: /usr/local/lib/libtree-sitter.0.dylib
Referenced from: /Users/jason/Downloads/tree sitter test/test-json-parser
Reason: image not found
This gives you several hints about what is happening: It says that it doesn't find libtree-sitter.0.dylib in directory /usr/local/lib which indicates that you have not specified a -L option to search in the subdirectory you say.
First of all, I recommend you to execute clang with option -v to show what command line is it using to call the linker. This will probably don't show the -L option you specified and it's argument.
My guess is that you are using that command line in some script that is deleting some of the \ chars (or you have a space after the \, and you are getting a new line cutting your command line before the linker options. Check this.
The linker you are using will check all directories specified in -L options before any of the system directories, for a file called libyourLibraryName.number.dylib, if it doesn't find, will try libyourLibraryName.a, and then it will try the next directory in the list. If you call the compiler with the -v option you will get the set of options it is using to call the linker. Please, it would be nice if you include that in your question.

libtiff build undefined reference to `_imp__TIFFOpen' error

probably this is a trivial newbie question, however, I can't figure out how to solve it.
I'm trying to build a test program using libtiff (test program copied from here). I've downloaded the static library libtiff.lib as well as the required header file tiffio.h. When I compile the main c function with no problem I have a main.o file. When I try to link main.o with libtiff using this command
gcc -g -Wall -o test.exe ./libtiff.lib ./test.o
I have this error:
undefined reference to `_imp__TIFFOpen'
I've looked into the lib file with nm -A libtiff.lib command and I can find this line
libtiff.lib:libtiff3.dll:00000000 I __imp__TIFFOpen
but it has 2 leading underscores instead of 1 as required by the linker. I'm using mingw on Windows 7 and all the required files are in the same directory.
No clue how to link with no errors.
Thanks in advance.
As suggested in the the comments, it was sufficient to invert the order of objects passed as arguments:
gcc -g -Wall -o test.exe ./test.o ./libtiff.lib

whats the reason for the xml2-config not found while compiling libxml2?

The program is to run a c program to parse a xml file in windows Gcc mingw.
but on compilation i get xml2-config not found ,--libs unrecognized commands, --cflags unrecognized commands.
gcc
i have added libxml files "libxml libxslt iconv" to the environmental path.
When you write a program that uses a third-party library like libxml, typically you have two problems:
You need to tell the compiler where the library's header files are installed, so that when your code says things like #include <xml.h> the compiler will be able to find them.
You need to tell the linker where the library itself is installed.
If you don't manage to do step 1 correctly, you typically get an error like "error: 'xml.h' file not found".
If you don't manage to do step 2 correctly, you typically get errors like "Undefined symbol: _xmlparse" or "library not found for -llibxml". ("Undefined symbol" means the compiler didn't even know to look for the library, so it complains that there are no definitions for the functions that would have been found in it. "library not found for -llibxml" means you told the compiler which library to look for, but it couldn't find it.)
On C compilers under Unix, anyway, you tell the compiler where to look for header files using the -I flag, like this:
cc -Idirectory_where_extra_header_files_are -c test.c
You tell the compiler/linker to load an additional library using the -l flag:
cc test.o -llibxml
You tell the compiler/linker where to find that additional library using the -L flag:
cc test.o -Ldirectory_where_extra_library_files_are -llibxml
But this can be a nuisance. Many third-party libraries come with "config" programs which are supposed to help you with this. An invocation like
xml-config --cflags
prints the string
-Idirectory_where_the_libxml_header_files_are
so you know what to add to the cc line to fix problem 1. And the an invocation like
xml-config --libs
prints the string
-Ldirectory_where_the_libxml_libraries_are -llibxml
so you know what to add to the cc line to fix problem 2.
And then, finally, this tool is intended to be used a special mechanism of the Unix shell, the backquote, which lets you take the output of one command and insert it into another command line:
cc `xml-config --cflags --libs` test.c
This literally runs the xml-config command, collects its output (that is, whatever xml-config prints out), and inserts that input into the command line, just as if you'd typed it, and then finally runs the cc command with those additional arguments. It's a handy mechanism, but if you're using Windows you may not be able to use it.
So if you're on a Unix-like system and if the xml-config program is installed where the shell can find it and if the header files and libraries are installed where xml-config thinks they are, then using xml-config can be very convenient. But if any of these things is not true, the whole mechanism breaks down, and you may have to do things "by hand".
Doing things "by hand" isn't impossible, and it isn't even particularly difficult. It's how we always did things back before this kind of "config" tool helper mechanism was invented. As discussed above, just use -I to tell the compiler where the header files are when you compile:
cc -Idirectory_where_the_libxml_header_files_are -c test.c
Use -L and -l to tell it where the library is:
cc test.o -Ldirectory_where_the_libxml_libraries_are -llibxml

How to install latest glibc (version 2.29) beside system installed one & compile a program?

Based on This Stackoverflow link I downloaded & installed glibc v2.29 in "/usr/local/glibc" path of Linux OS. Then based on this Stackoverflow link I tried to compile This Example, But I got following errors.
First Try Command:
gcc -Wall -g -o main main.c -Wl,--rpath=/usr/local/glibc/lib -Wl,--dynamic-linker=/usr/local/glibc/lib/ld-linux-x86-64.so.2
First Try Error Log:
main.c:1:10: fatal error: threads.h: No such file or directory
#include <threads.h>
^~~~~~~~~~~
compilation terminated.
Second Try Command:
In second try, I am using "-I" & "-L" GCC command options.
gcc -Wall -g -I/usr/local/glibc/include -o main main.c -L/usr/local/glibc/lib -Wl,--rpath=/usr/local/glibc/lib -Wl,--dynamic-linker=/usr/local/glibc/lib/ld-linux-x86-64.so.2
Second Try Error Log:
/tmp/ccCNYemW.o: In function `main':
/home/.../main.c:14: undefined reference to `thrd_create'
/home/.../main.c:16: undefined reference to `thrd_join'
collect2: error: ld returned 1 exit status
So I don't know where is the problem. Please Help me.
First of all, don't put an alternate libc (or alternate version of your libc) in a path searched by the normal include and library search (both link-time and runtime library search) for your main system one. This is a recipe for disaster. Installing a different glibc in /usr/local/ does avoid clobbering your system one, but now you just have two installed in places where the same tools can see and use them.
To do this right, you really need a full separate toolchain (gcc, binutils) in some completely separate path (like ~/my_glibc_root/... or /opt/alt_glibc_root/...). I'm not sure if there's a recommended way to do this. The glibc build procedures in Linux From Scratch might be a good place to look for ideas. In theory it can be done in a single stage; I do that with musl libc in musl-cross-make by careful use of intermediate make rules in the gcc build system. But applying the same idea to glibc probably requires some extra care.
Second Try Command: In second try, I am using "-I" & "-L" GCC command options.
gcc -Wall -g -I/usr/local/glibc/include -o main main.c -L/usr/local/glibc/lib -Wl,--rpath=/usr/local/glibc/lib -Wl,--dynamic-linker=/usr/local/glibc/lib/ld-linux-x86-64.so.2
This command is almost correct. The thrd_create and thrd_join functions are defined in libpthread, which you didn't link against.
Add -pthread to your compile command, and the link should succeed.
P.S. R's advice of not installing alternate GLIBC into /usr/local is also a good one.

How do I patch libxml2 so it will compile with ICU support when using a prefix?

I'm trying to fix a bug in libxml2. I cannot get it to compile with --with-icu when using --prefix=/Server/software. I have submitted a bug report here, but I need to get it to compile for resolving a conflict when compiling PHP with intl support. I suspect it's a problem with the Makefile. My experience with Makefile's is limited. The desired result is coming up with a patch that can be submitted to the linked bug report.
The --with-icu flag causes LIBXML_ICU_ENABLED to be defined. The included code is supposed to resolve a conflict when including headers from both icu and libxml2 (specifically, both use UChar). The PHP plugin intl, activated with --enable-intl, requires icu. libxml2 is needed by PHP for DOM/XML functions.
There are two problems.
First, this config:
./configure --prefix=/Server/software --enable-shared --enable-static --with-icu
Results in:
configure: error: libicu config program icu-config not found
This happens because of this code in configure.in:
WITH_ICU=0
if test "$with_icu" != "yes" ; then
echo Disabling ICU support
else
ICU_CONFIG=icu-config
if ${ICU_CONFIG} --cflags >/dev/null 2>&1
then
ICU_LIBS=`icu-config --ldflags`
LDFLAGS="$LDFLAGS $ICU_LIBS"
WITH_ICU=1
echo Enabling ICU support
else
AC_MSG_ERROR([libicu config program icu-config not found])
fi
fi
Specifically ICUCONFIG=icu-config isn't respecting --prefix=/Server/software. I can work around this by doing export PATH=/Server/software/bin:$PATH.
This "fixes" the ./configure problem.
Second, when I run make I get errors, the most relavent being:
./include/libxml/encoding.h:31:26: error: unicode/ucnv.h: No such file or
directory
The unicode/uncv.h file is in /Server/software/include/unicode/uncv.h. I suspect the compiler is looking for this file in the local directory and in my /usr directory.
This is what the error is referring to:
#ifdef LIBXML_ICU_ENABLED
#include <unicode/ucnv.h>
#endif
Clearly this is a path issue when using --with-icu and --prefix=/Server/software. Without --with-icu it compiles fine, but this is needed to resolve a define UChar conflict when compiling PHP with both icu and libxml2.
The result of icu-config --cflags is:
-O2 -Wall -ansi -pedantic -Wshadow -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -Wno-long-long
This is being piped into /dev/null.
The result of icu-config --ldflags is:
-lpthread -lm -L/Server/software/lib -licui18n -licuuc -licudata -lpthread -lm
What needs to be changed to resolve these issues?
So, take a look at where it's using icu-config. It should be doing something like icu-config --cppflags which should set -I/Server/Software/include or similar. You could work around it by setting CPPFLAGS to include such a parameter yourself.
Can you include the actual compile command line immediately before the error?
Sounds like a bug in libxml - it ought to search ${PREFIX}/bin for icu-config.
Also, ICU now exports pkg-config files, which are more of a standard way to find such items.
Try this before WITH_ICU :
ICU_CPPFLAGS=`icu-config --cppflags`
CPPFLAGS="$CPPFLAGS $ICU_CPPFLAGS"
update I'm going to quote Luke's last response. Glad it's working.
I solved the linker problems, so now it all works. For this question
using libxml 2.7.7 was the solution. It seems OX X 10.6 ships with
2.7.8. So for it to work you have to compile libxml2 yourself with 2.7.7. The linker problems are solved by adding LIBS="-lresolv -lstdc++" just before PHP's ./configure. If installing to a non-standard location you also need to compile ICU with
--enable-rpath. I've accepted your answer. Feel free to update it with this information :). – Luke 17 hours ago

Resources