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

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

Related

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.

LLVM Clang underscore linking issue

I know there are several related posts on this topic but after going though it for the better part of all day, I am posting this question.
I am building and compiling a C ELF application (NOT C++) with clang. Everything compiles fine, but linking fails with a ton of undefined symbols starting with a underscore. These symbols are all defined in glibc at /lib/libc-2.27.so without the underscore but LLVM keeps putting the underscore in my object files. I strongly suspect I should be linking against a different libc, however, the stellar documentation has left me with no idea what this isn't working.
libtool: link: clang -I../include -I../libstuff -g -O2 -I/usr/lib64/llvm/6/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -target x86_64-pc-linux-gnu -std=c99 -stdlib=libc -I/usr/include -isystem/mnt/apple-sdk/4.6/4.6.2/SDKs/MacOSX10.7.sdk/usr/include --no-system-header-prefix=/usr/include --no-system-header-prefix=/mnt/apple-sdk/4.6/4.6.2/SDKs/MacOSX10.7.sdk/usr/include -o ar ar-append.o ar-ar.o ar-archive.o ar-contents.o ar-delete.o ar-extract.o ar-misc.o ar-move.o ar-print.o ar-replace.o -L/usr/lib64/llvm/6/lib64 ../libstuff/.libs/libstuff.a -lLLVMSymbolize -lLLVMDemangle -lLLVMSupport -lLLVMMC -lc
ar-append.o: In function `append':
/home/kwhat/NetBeansProjects/binutils-apple_new/ar/append.c:103: undefined reference to `_open'
/home/kwhat/NetBeansProjects/binutils-apple_new/ar/append.c:113: undefined reference to `_close'
Update and Solution
After reading the GCC documentation for -I, -isystem and adjusting the include ordering in my CFLAGS I was able to work around this problem. The issue ended up being that one file from the OS X include folder needed to come before /usr/include and the rest after. Examining the Plo files offered useful insight into where the includes where coming from and which ones were unexpected. In case anyone is wondering what the hell I am doing, I am refactoring an old port of cctools & ld64 for Linux to OS X cross compiling. The project currently works, but includes a lot of header hacks and unneeded patching I am trying to resolve. More info: https://github.com/kwhat/binutils-apple

cc linker gives no error, but the resulting library is not linked to libgstvideo-1.0

I'm using cmake to generate a gstreamer library. In the end cmake uses the following command for linking:
/usr/bin/cc -fPIC -shared -Wl,-soname,libmacq-gstmelpi.so -o libmacq-gstmelpi.so <OBJECT_FILES> -lmacq-melpi -lmacq-icar-tools -lmacq-gstmecimeta -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0 -lgstvideo-1.0
Note the -lgstvideo-1.0 flag at the end. The command runs fine, no error is produced, and the resulting library is created just fine. However when I use the library, I get undefined symbol error. So I use ldd to check; and amongst all the output of ldd; libgstvideo-1.0.so is not to be found.
This problem occurs on Ubuntu 14.04 on a armhf architecture. The problem does not occur on opensuse 13.1 (i586) nor on opensuse 13.1 (armv7hl), since in that case ldd libmacq-gstmelpi.so | grep gstvideo gives:
libgstvideo-1.0.so.0 => /usr/lib/libgstvideo-1.0.so.0 (0xb715f000)
EDIT :
I have another library, very similar where a very similar command works just fine; the resulting library is correctly linked to libgstvideo-1.0.so
/usr/bin/cc -fPIC -shared -Wl,-soname,libmacq-gstplugins.so -o libmacq-gstplugins.so <OBJECT_FILES> -lmacq-icar-tools -lmacq-gstmecimeta -lgstapp-1.0 -lgstbase-1.0 -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0 -lgstvideo-1.0
Some remarks on what I have checked and tried:
/usr/lib/arm-linux-gnueabihf/libgstvideo-1.0.so exists. (the other libraries in /usr/lib/arm-linux-gnueabihf/ are found without problem, libmacq-gstmelpi.so is linked to /usr/lib/arm-linux-gnueabihf/libgstreamer-1.0.so.0 without problem)
I tried changing the order, and putting the -lgstvideo-1.0 flag before all other -l flags; no succes.
replacing cc with c++ or gcc; the commands work, but output is the same
removing -lgstvideo-1.0 on a system where the build worked. The resulting library builds (links) without error; yet upon execution I have the same undefined symbol error as on Ubuntu. This proves that the missing symbol is in libgstvideo-1.0.so, and that I need it.
Are you actually using symbols from that particular library or do you just want to link to it to avoid linking it in the application that uses the library later on?
It could be a default compiler behavior that it skips linking of libraries when no symbol from these are actually used.
Try -Wl,--no-as-needed to your flags. In this case the library should get linked - not checking whether its symbols are actually used or not.
EDIT:
After chatting it turned out that the actual desired symbols are in gstbase-1.0 and not gstvideo-1.0. Since gstvideo-1.0 pulls in gstbase-1.0 as a dependency this worked but would cause problem as the linker may remove this dependency since no symbols from this particular library are being used. Linking directly to gstbase-1.0 seemed to solve all issues.

GCC compiler is unable to find pcre.h

I am trying to compile a C program which uses regexes on FreeBSD. I have checked in /usr/local/include and the file pcre.h is definitely there.
However, no matter what I do, I get the following compiler error:
/usr/home/myname/project/include/pcre_wrap.h:4:18: error: pcre.h: No such file or directory
What could be going wrong? My understanding of C libraries on Unix could be better...
As the comment above says you need to use #include. If this isn't working you may want to export an environment variable C_INCLUDE_PATH that points to the header file.
Failing that why not try adding -I/usr/local/include to your gcc call, something like gcc myfile.c -I/usr/local/include -o myexe

Can I skip cmake compiler tests or avoid "error: unrecognized option '-rdynamic'"

compilation options for cmake (on windows) for ARM target system but when I run configure it's starting compiler tests:
CMake Error at D:/Program Files/CMake 2.8/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE):
The C compiler "D:/Program Files/yagarto/bin/arm-none-eabi-gcc.exe" is not
able to compile a simple test program.
It fails with the following output:
Change Dir: D:/merge/complex/build/CMakeFiles/CMakeTmp
Run Build Command:D:/PROGRA~1/YAGART~1/bin/make.exe "cmTryCompileExec/fast"
D:/PROGRA~1/YAGART~1/bin/make.exe -f
CMakeFiles/cmTryCompileExec.dir/build.make
CMakeFiles/cmTryCompileExec.dir/build
make.exe[1]: Entering directory
`D:/merge/complex/build/CMakeFiles/CMakeTmp'
"D:/Program Files/CMake 2.8/bin/cmake.exe" -E cmake_progress_report
D:/merge/complex/build/CMakeFiles/CMakeTmp/CMakeFiles 1
Building C object CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o
"D:/Program Files/yagarto/bin/arm-none-eabi-gcc.exe" -o
CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o -c
D:/merge/complex/build/CMakeFiles/CMakeTmp/testCCompiler.c
Linking C executable cmTryCompileExec
"D:/Program Files/yagarto/bin/arm-none-eabi-gcc.exe"
"CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o" -o cmTryCompileExec
-rdynamic
arm-none-eabi-gcc.exe: error: unrecognized option '-rdynamic'
make.exe[1]: *** [cmTryCompileExec] Error 1
Using Yagatdo 4.6.* cross-compilation toolchain
How can I skip this tests or fix -rdynamic error that I am getting?
You can set CMAKE_<LANG>_COMPILER_WORKS to true to suppress further compiler checks for that language.
set(CMAKE_C_COMPILER_WORKS 1)
You can skip the compiler checks by adding NONE to your project call:
project(<projectname> NONE)
but this can have pretty far-reaching effects. For full details, run
cmake --help-command project
I'm not familiar with ARM, so this is probably not your best option here. I guess you'd be better to see if there's a way to fix the -rdynamic flag.
EDIT:
It looks like this was identified as a bug which is effectively still unresolved. The comments in the bug report mention adding the following lines as a workaround (presumably before your project call):
set(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS "")
set(CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS "")
It seems you target actually something else than Linux, so you should tell cmake that you are cross-compiling for the generic case:
SET(CMAKE_SYSTEM_NAME Generic)
Followed by (optionally, but nice to specify):
SET(CMAKE_SYSTEM_PROCESSOR arm)
SET(CMAKE_CROSSCOMPILING 1)
However, if you specify (which you likely did because this is stated in a lot of examples online):
SET(CMAKE_SYSTEM_NAME Linux)
Then cmake will load the configuration files from (suppose version 2.8) the file:
/usr/share/cmake-2.8/Modules/Platform/Linux.cmake
from which it is likely to load:
/usr/share/cmake-2.8/Modules/Platform/Linux-GNU.cmake
Here the -rdynamic flag is set for historical reasons:
macro(__linux_compiler_gnu lang)
# We pass this for historical reasons. Projects may have
# executables that use dlopen but do not set ENABLE_EXPORTS.
set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS "-rdynamic")
endmacro()
Rather than disabling the tests as indeed is done by specifying NONE as the PROJECT argument, it seems setting the CMAKE_SYSTEM_NAME (to something else than Linux, for instance Generic) is what you actually want to do.
If you're just compiling a static library and you want to avoid having CMake test that the compiler can generate binaries, you can set the variable CMAKE_TRY_COMPILE_TARGET_TYPE.
set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
When cross compiling for Windows, where there is no -rdynamic option, you can use
-DCMAKE_SYSTEM_NAME="Windows"
with cmake. Then Cmake will skip the test with -rdynamic.

Resources