Bug #1449
open
aspectator build issue on x86-64: multilib building
Added by Alexey Khoroshilov over 13 years ago.
Updated almost 9 years ago.
Description
We should investigate if we want to use --disable-multilib gcc config option. Otherwise we have to add 32-bit glibc headers as a build requirements for aspectator.
Without them you get the following error:
make[8]: Entering directory `/home/tester/ldv/ldv-tools/rule-instrumentor/aspectator/gcc-4.6/__install/aspectator-core-build/x86_64-unknown-linux-gnu/32/libgcc'
# If this is the top-level multilib, build all the other
# multilibs.
/home/tester/ldv/ldv-tools/rule-instrumentor/aspectator/gcc-4.6/__install/aspectator-core-build/./gcc/xgcc -B/home/tester/ldv/ldv-tools/rule-instrumentor/aspectator/gcc-4.6/__install/aspectator-core-build/./gcc/ -B/home/tester/ldv/ldv-tools/rule-instrumentor/aspectator/gcc-4.6/__install/aspectator-core-bin/x86_64-unknown-linux-gnu/bin/ -B/home/tester/ldv/ldv-tools/rule-instrumentor/aspectator/gcc-4.6/__install/aspectator-core-bin/x86_64-unknown-linux-gnu/lib/ -isystem /home/tester/ldv/ldv-tools/rule-instrumentor/aspectator/gcc-4.6/__install/aspectator-core-bin/x86_64-unknown-linux-gnu/include -isystem /home/tester/ldv/ldv-tools/rule-instrumentor/aspectator/gcc-4.6/__install/aspectator-core-bin/x86_64-unknown-linux-gnu/sys-include -g -O2 -m32 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector -I. -I. -I../../.././gcc -I/home/tester/ldv/ldv-tools/rule-instrumentor/aspectator/gcc-4.6/__install/aspectator-core-src/libgcc -I/home/tester/ldv/ldv-tools/rule-instrumentor/aspectator/gcc-4.6/__install/aspectator-core-src/libgcc/. -I/home/tester/ldv/ldv-tools/rule-instrumentor/aspectator/gcc-4.6/__install/aspectator-core-src/libgcc/../gcc -I/home/tester/ldv/ldv-tools/rule-instrumentor/aspectator/gcc-4.6/__install/aspectator-core-src/libgcc/../include -I/home/tester/ldv/ldv-tools/rule-instrumentor/aspectator/gcc-4.6/__install/aspectator-core-src/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /home/tester/ldv/ldv-tools/rule-instrumentor/aspectator/gcc-4.6/__install/aspectator-core-src/libgcc/../gcc/libgcc2.c \
-fvisibility=hidden -DHIDE_EXPORTS
In file included from /usr/include/features.h:387:0,
from /usr/include/stdio.h:28,
from /home/tester/ldv/ldv-tools/rule-instrumentor/aspectator/gcc-4.6/__install/aspectator-core-src/libgcc/../gcc/tsystem.h:87,
from /home/tester/ldv/ldv-tools/rule-instrumentor/aspectator/gcc-4.6/__install/aspectator-core-src/libgcc/../gcc/libgcc2.c:29:
/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
compilation terminated.
Related issues
1 (1 open — 0 closed)
- Status changed from New to Feedback
Alexey Khoroshilov wrote:
We should investigate if we want to use --disable-multilib gcc config option. Otherwise we have to add 32-bit glibc headers as a build requirements for aspectator.
Here source:INSTALL it is already mentioned that we should have 32-bit glibc headers for installation
20 o glibc-devel-32bit
But nevertheless may be we should use --disable-multilib gcc configuration option (at least to remove this dependency). Any thoughts?
If it's just a matter of configuring away the stuff we don't need that includes external dependencies, we should do it!
- Status changed from Feedback to New
If we lose nothing we should remove the dependency.
Does it affect ability to be a 32-bit aspectator on 64-bit system?
- Status changed from New to Open
We should investigate what will happen in case if we turn off multiple libraries support. I suggest that it will not affect instrumentation since there is not many external library dependencies for Linux kernel.
- Project changed from Linux Driver Verification to C Instrumentation Framework
- Category deleted (
15)
- Priority changed from Normal to High
I'm going to investigate the given issue while dealing with #3627 to avoid unnecessary dependencies both for CIF and LDV tools.
Using --disable-multilib option in GCC configuring does allow to avoid 32-bit stuff dependencies... but not for Ubuntu. For openSUSE it works and I guess that for your system it also will work since without this option I got the same error as the your one.
For Ubuntu I got errors like this and this. For the first error people advices to create symlinks, for the second - to install 32-bit libc development package (that implies gcc multilib stuff). Now I'm trying to solve both problems with help of symlinks, since installing additional packages isn't very well.
To install CIF on 64-bit Ubuntu without 32-bit stuff one has to do following:
ln -s /usr/lib/x86_64-linux-gnu/crt*.o /usr/lib
ln -s /usr/include/x86_64-linux-gnu/asm /usr/include/x86_64-linux-gnu/bits/ /usr/include/x86_64-linux-gnu/gnu/ /usr/include/x86_64-linux-gnu/sys /usr/include
So, I will add --disable-multilib to default Aspectator configuration and describe installation tricks of CIF for 64-bit Ubuntu in
#3627, if there isn't any objections.
Evgeny Novikov wrote:
So, I will add --disable-multilib to default Aspectator configuration and describe installation tricks of CIF for 64-bit Ubuntu in #3627, if there isn't any objections.
That is ok, if all will work seamless when 32-bit libc already installed.
I tested this workaround after installation of 32-bit stuff on 64-bit Ubuntu. It works good. The only thing is that after installation of 32-bit stuff directory /usr/include/sys already exists. So one will see following message if he or she will try to apply this workaround after 32-bit stuff installation:
ln: failed to create symbolic link `/usr/include/sys': File exists
So, any case everything is okay:
- Without workaround and installation of 32-bit stuff 64-bit Ubuntu users can not install CIF (and they will see messages that will be described in INSTALL file).
- With workaround and without installation of 32-bit stuff 64-bit Ubuntu users can install CIF.
- Without workaround and with installation of 32-bit stuff 64-bit Ubuntu users can install CIF.
- With workaround and following installation of 32-bit stuff 64-bit Ubuntu users can install CIF.
- With installation of 32-bit stuff and following workaround 64-bit Ubuntu users can install CIF.
It turns out that 32-bit stuff installation also creates other symlinks in /usr/include directory:
asm -> x86_64-linux-gnu/asm
bits -> x86_64-linux-gnu/bits
gnu -> x86_64-linux-gnu/gnu
as well as
sys directory.
Evgeny Novikov wrote:
- Without workaround and with installation of 32-bit stuff 64-bit Ubuntu users can install CIF.
This isn't the case indeed. Installation of 32-bit stuff helps 64-bit Ubuntu users just to omit creating symlynks for headers, but not for libraries. As for libraries another workaround can be used to avoid modifications of important system directories. It is to export LIBRARY_PATH=/usr/lib/x86_64-linux-gnu before CIF installation. I will try to find something like that for header files as well.
Evgeny Novikov wrote:
... As for libraries another workaround can be used to avoid modifications of important system directories. It is to export LIBRARY_PATH=/usr/lib/x86_64-linux-gnu before CIF installation. I will try to find something like that for header files as well.
Also one needs to export LIBRARY_PATH=/usr/lib/x86_64-linux-gnu before CIF invocation, because of it is also run-time dependency. For headers it is enough to export C_INCLUDE_PATH=/usr/include/x86_64-linux-gnu before CIF installation.
So after all we can add following advices for 64-bit Ubuntu users:
- You need either to export C_INCLUDE_PATH=/usr/include/x86_64-linux-gnu before CIF installation or to install libc6-dev-i386 package (and all related 32-bit stuff as well) (I guess that creating symlinks for headers is a worse solution in comparison with these ones).
- You need either to export LIBRARY_PATH=/usr/lib/x86_64-linux-gnu before installation and each invocation of CIF or to create symlinks "ln -s /usr/lib/x86_64-linux-gnu/crt*.o /usr/lib".
Medium term solution can be backporting multiarch support from gcc or updating to newer version of gcc.
See also '[patch v2] support for multiarch systems' discussion in gcc mailing list.
- Category set to Deployment
Also available in: Atom
PDF