Static library -lzita-resampler installed in /usr/local/lib unable to be found when using gcc - c

I'm trying to install a binary called audiowmark (link) from source on my Mac. The instructions say to run ./configure but when I do that, I run in to an error that claims:
checking for _Z28zita_resampler_major_versionv in -lzita-resampler... no
configure: error: You need to install libzita-resampler to build this package.
As a result, I need to install the libzita-resampler library. As a novice in C/CMake/Make, this is where things got a bit confusing for me. I think I'm installing this package correctly (I see the libzita-resampler.a in my usr/local/lib), but I still receive the above error. Can someone help guide me in the right direction to ensure I installed correctly? From my understanding, /usr/local/lib is a default path that is checked for libraries when running gcc.
To install libzita-resampler, I found the GitHub repo (link) and loaded the source to my computer.
I first created a build directory in this library and cd-ed in to it:
mkdir build && cd build
With cmake installed, I was able to run
cmake ..
Which created the Makefile for my computer, I then ran the following commands with Make
make
Which output the following
jordan#Jordans-MBP-3 build % make
[ 20%] Building CXX object CMakeFiles/zita-resampler.dir/source/resampler.cc.o
[ 40%] Building CXX object CMakeFiles/zita-resampler.dir/source/vresampler.cc.o
[ 60%] Building CXX object CMakeFiles/zita-resampler.dir/source/resampler-table.cc.o
[ 80%] Building CXX object CMakeFiles/zita-resampler.dir/source/cresampler.cc.o
[100%] Linking CXX static library libzita-resampler.a
[100%] Built target zita-resampler
And therefore ran the install step
make install
Which output
jordan#Jordans-MBP-3 build % make install
[100%] Built target zita-resampler
Install the project...
-- Install configuration: ""
-- Installing: /usr/local/lib/libzita-resampler.a
-- Installing: /usr/local/lib/cmake/zita-resampler/zita-resamplerConfig.cmake
-- Installing: /usr/local/lib/cmake/zita-resampler/zita-resamplerConfigVersion.cmake
-- Installing: /usr/local/lib/cmake/zita-resampler/zita-resamplerTargets.cmake
-- Installing: /usr/local/lib/cmake/zita-resampler/zita-resamplerTargets-noconfig.cmake
Which successfully added the static library .a to my lib directory.
So with this set up, I'd assume I would be able to then run the audiowmark's ./configure command again but I still receive the same error indicating that I didn't install this library correctly. Is there a final step to get the ./configure step to "find" this new library that I installed that I missed?
Here's the relevant code that looks for the library in the ./configure script. I see that it's adding LIBS= -lzita-resampler so it should find it in my directory path now...right?
{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking for _Z28zita_resampler_major_versionv in -lzita-resampler" >&5
printf %s "checking for _Z28zita_resampler_major_versionv in -lzita-resampler... " >&6; }
if test ${ac_cv_lib_zita_resampler__Z28zita_resampler_major_versionv+y}
then :
printf %s "(cached) " >&6
else $as_nop
ac_check_lib_save_LIBS=$LIBS
LIBS="-lzita-resampler $LIBS"
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
/* Override any GCC internal prototype to avoid an error.
Use char because int might match the return type of a GCC
builtin and then its argument prototype would still apply. */
char _Z28zita_resampler_major_versionv ();
int
main (void)
{
return _Z28zita_resampler_major_versionv ();
;
return 0;
}
_ACEOF
if ac_fn_c_try_link "$LINENO"
then :
ac_cv_lib_zita_resampler__Z28zita_resampler_major_versionv=yes
else $as_nop
ac_cv_lib_zita_resampler__Z28zita_resampler_major_versionv=no
fi
rm -f core conftest.err conftest.$ac_objext conftest.beam \
conftest$ac_exeext conftest.$ac_ext
LIBS=$ac_check_lib_save_LIBS
fi
{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_zita_resampler__Z28zita_resampler_major_versionv" >&5
printf "%s\n" "$ac_cv_lib_zita_resampler__Z28zita_resampler_major_versionv" >&6; }
if test "x$ac_cv_lib_zita_resampler__Z28zita_resampler_major_versionv" = xyes
then :
printf "%s\n" "#define HAVE_LIBZITA_RESAMPLER 1" >>confdefs.h
LIBS="-lzita-resampler $LIBS"
else $as_nop
as_fn_error $? "You need to install libzita-resampler to build this package." "$LINENO" 5
fi
Thanks for any guidance, learning as I go here.

Related

Check for working C compiler: /usr/bin/cc -- broken

I am having a problem with the installation of a ROS packages on my raspberry pi 3. I really hope you can help me.
<== Finished processing package [10 of 53]: 'fzi_icl_core'
==> Processing plain cmake package: 'fzi_icl_can'
==> Building with env: '/opt/ros/kinetic/env.sh'
==> cmake /home/pi/ros_catkin_ws/src/fzi_icl_can -DCMAKE_INSTALL_PREFIX=/opt/ros/kinetic -DCMAKE_BUILD_TYPE=Release -G Unix Makefiles in '/home/pi/ros_catkin_ws/build_isolated/fzi_icl_can/install'
The C compiler identification is unknown
-- The CXX compiler identification is GNU 4.9.2
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- broken
CMake Error at /usr/share/cmake-3.6/Modules/CMakeTestCCompiler.cmake:61 (message):
** The C compiler "/usr/bin/cc" is not able to compile a simple test program.**
It fails with the following output:
Change Dir: /home/pi/ros_catkin_ws/build_isolated/fzi_icl_can/install/CMakeFiles/CMakeTmp
Run Build Command:"/usr/bin/make" "cmTC_cd4f1/fast"
/usr/bin/make -f CMakeFiles/cmTC_cd4f1.dir/build.make
CMakeFiles/cmTC_cd4f1.dir/build
make[1]: Entering directory
'/home/pi/ros_catkin_ws/build_isolated/fzi_icl_can/install/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_cd4f1.dir/testCCompiler.c.o
/usr/bin/cc -o CMakeFiles/cmTC_cd4f1.dir/testCCompiler.c.o -c
/home/pi/ros_catkin_ws/build_isolated/fzi_icl_can/install/CMakeFiles/CMakeTmp/testCCompiler.c
cc1: internal compiler error: in next_pass_1, at passes.c:1258
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
CMakeFiles/cmTC_cd4f1.dir/build.make:65: recipe for target
'CMakeFiles/cmTC_cd4f1.dir/testCCompiler.c.o' failed
make[1]: *** [CMakeFiles/cmTC_cd4f1.dir/testCCompiler.c.o] Error 1
make[1]: Leaving directory
'/home/pi/ros_catkin_ws/build_isolated/fzi_icl_can/install/CMakeFiles/CMakeTmp'
Makefile:126: recipe for target 'cmTC_cd4f1/fast' failed
make: *** [cmTC_cd4f1/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:2 (project)
-- Configuring incomplete, errors occurred!
See also "/home/pi/ros_catkin_ws/build_isolated/fzi_icl_can/install/CMakeFiles/CMakeOutput.log".
See also "/home/pi/ros_catkin_ws/build_isolated/fzi_icl_can/install/CMakeFiles/CMakeError.log".
<== Failed to process package 'fzi_icl_can':
Command '['/opt/ros/kinetic/env.sh', 'cmake', '/home/pi/ros_catkin_ws/src/fzi_icl_can', '-DCMAKE_INSTALL_PREFIX=/opt/ros/kinetic', '-DCMAKE_BUILD_TYPE=Release', '-G', 'Unix Makefiles']' returned non-zero exit status 1
Reproduce this error by running:
==> cd /home/pi/ros_catkin_ws/build_isolated/fzi_icl_can && /opt/ros/kinetic/env.sh cmake /home/pi/ros_catkin_ws/src/fzi_icl_can -DCMAKE_INSTALL_PREFIX=/opt/ros/kinetic -DCMAKE_BUILD_TYPE=Release -G 'Unix Makefiles'
Command failed, exiting.
The output was:
1
cc1: internal compiler error: in next_pass_1, at passes.c:1258
Please submit a full bug report,
If you haven't already, I would try sudo apt-get install build-essential to make sure that all the necessary build components are installed.
Search installed gcc libs:
dpkg -l | grep libgcc | cut -d' ' -f 3 | tr '\n' ' '
My result:
libgcc-5-dev:amd64 libgcc1:amd64
Reinstall it:
apt install --reinstall libgcc1:armhf libgcc-5-dev:armhf

MOTIF compiling error / X11/intrinsic.h missing

i have MOTIF installed X11
a easy program is saved as hello.c
there is the following message
where can i get the X11/intrinsic.h , file ???
need help to compile
my system : MX-16 Linux Debian Jessie / i386
Code:
hans#mx1:~/Documents
$ cc push.c -o push -lXm -lXt -lX11
In file included from push.c:2:0:
/usr/include/Xm/Xm.h:59:27: fatal error: X11/Intrinsic.h: No such file or directory
#include <X11/Intrinsic.h>
^
compilation terminated.
hans#mx1:~/Documents
I installed the libxt-dev package on my Debian box:
apt-get install libxt-dev
Then the proper header will be installed:
# find /usr -name "Intrinsic.h" -print
/usr/include/X11/Intrinsic.h
Been using xv for several decades now -- I always find myself trying to rebuild it.
The copy on my system came from libxt-dev
$ locate Intrinsic
/usr/include/X11/Intrinsic.h
/usr/include/X11/IntrinsicI.h
/usr/include/X11/IntrinsicP.h
$ dpkg-query -S /usr/include/X11/Intrinsic.h
libxt-dev:amd64: /usr/include/X11/Intrinsic.h
You may want to install and use apt-file - you can ask it for a filename and it will tell you which packages (that you don't even have to have installed - just from the repos in your sources.lists) contain a file with that name

ERROR: Failed to spawn fakeroot worker to run /PATH_TO_THIS/example_0.1.bb:do_install: [Errno 2] No such file or directory

I am trying to compile a c code and install it using yocto. it is successfully compiled using do_compile.
I tried to install using do_install, it is giving bellow error.
ERROR: Failed to spawn fakeroot worker to run /PATH_TO_THIS/example_0.1.bb:do_install: [Errno 2] No such file or directory
Please find my bb file below
SUMMARY = "Simple helloworld application"
SECTION = "examples"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR} /MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
SRC_URI = "file://sample.c"
S = "${WORKDIR}"
do_compile() {
x86_64-linux-gnu-gcc sample.c -o test_example
}
do_install() {
install -d ${D}${bindir}
install -m 0755 test_example ${D}${bindir}
}
Based on your comment above that you are using -b - that is almost certainly the cause of this issue. When you use -b bitbake will print this warning:
WARNING: Buildfile specified, dependencies will not be handled. If this is not what you want, do not use -b / --buildfile.
One of the dependencies that you may be missing is the fakeroot program (pseudo). Using -b is likely preventing that from being built.
Instead of using -b, you should put the recipe into a place bitbake can find it (to test, could be meta/recipes-extended/example, but when you do it properly you should create your own layer and put it there). Then you can just build it like any other recipe:
bitbake example

Pkg-config file is on the pkg-config path but can not be found by configure script

I am trying to install libvirt from source. The version I am trying to install is 1.2.7. I want libssh2 enabled. Here is how I call the configure script:
./configure --prefix=/home/administrator/dev/workspaces/libvirt/built/libvirt-1.2.7/ --with-sasl --with-qemu --with-lxc --with-gnutls --with-remote --with-ssh2 --with-polkit
I got the following error:
configure: error: You must install the libssh2 >= 1.3 pkg-config module to compile libvirt
I downloaded the libssh2 lib version 1.4.3 and installed it using the default options:
$ ./configure
$ make
$ sudo make install
Here is some useful info:
$ sudo ldconfig
$ sudo updatedb
$ locate libssh2.so
/usr/local/lib/libssh2.so
/usr/local/lib/libssh2.so.1
/usr/local/lib/libssh2.so.1.0.1
$ locate libssh2.pc
/usr/local/lib/pkgconfig/libssh2.pc
$ pkg-config --variable pc_path pkg-config
/usr/local/lib/x86_64-linux-gnu/pkgconfig:/usr/local/lib/pkgconfig:/usr/local/share/pkgconfig:/usr/lib/x86_64-linux-gnu/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig
Obviously the libssh2.pc file is on the pkg-config path. However, when I tried executing the configure script for libvirt, the same error occurred. Any ideas what I am doing wrong ? Thank you.
EDIT: Fragment of the config.log file:
34475 configure:59141: checking for SSH2
34476 configure:59148: $PKG_CONFIG --exists --print-errors "libssh2 >= 1.3"
34477 configure:59151: $? = 0
34478 configure:59165: $PKG_CONFIG --exists --print-errors "libssh2 >= 1.3"
34479 configure:59168: $? = 0
34480 configure:59182: result: no
34481 Package libssl was not found in the pkg-config search path.
34482 Perhaps you should add the directory containing `libssl.pc'
34483 to the PKG_CONFIG_PATH environment variable
34484 Package 'libssl', required by 'libssh2', not found
34485 configure:59225: error: You must install the libssh2 >= 1.3 pkg-config module to compile libvirt
...
34576 ac_cv_env_PKG_CONFIG_LIBDIR_set=
34577 ac_cv_env_PKG_CONFIG_LIBDIR_value=
34578 ac_cv_env_PKG_CONFIG_PATH_set=
34579 ac_cv_env_PKG_CONFIG_PATH_value=
34580 ac_cv_env_PKG_CONFIG_set=
34581 ac_cv_env_PKG_CONFIG_value=
...
34874 ac_cv_path_ac_pt_PKG_CONFIG=/usr/bin/pkg-config
36432 PKG_CONFIG='/usr/bin/pkg-config'
36433 PKG_CONFIG_LIBDIR=''
36434 PKG_CONFIG_PATH=''

How to build a C program using a custom version of glibc and static linking?

I have built glibc 2.14 and installed it in directory ~/GLIBC/glibc_install. Now I want to build and run programs using this C library instead of my system's default C library.
To be sure that I was using my custom glibc, I added a call to puts into glibc/stdio-common/printf.c:__printf to print a message.
Then I rebuilt and reinstalled glibc.
Then I wrote a "Hello, World" program and tried to compile and link it as follows:
gcc -nodefaultlibs -static -lgcc -L~/GLIBC/glibc_install/lib -o myprog myprog.c
But I get the following linker error report:
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crt1.o: In function `_start':
(.text+0x19): undefined reference to `__libc_csu_init'
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crt1.o: In function `_start':
(.text+0x25): undefined reference to `__libc_start_main'
/tmp/ccACTQEp.o: In function `main':
c1.c:(.text+0xa): undefined reference to `puts'
collect2: ld returned 1 exit status
What am I doing wrong?
Following a couple of suggestions from the glibc help mailing list (libc-help#sourceware.org), I have a solution. It turns out that this task is a bit tricky because you have to tell the linker to omit everything it would normally include automatically (and silently), and then include back everything that it needs, including a bunch of start and end files. Some of the start and end files come from libc and some come from gcc, so the make rule is a bit complicated. Below is a general sample makefile to illustrate the approach. I will assume that you are building a program called prog from a source file called prog.c and that you have installed your custom glibc in directory /home/my_acct/glibc_install.
TARGET = prog
OBJ = $(TARGET).o
SRC = $(TARGET).c
CC = gcc
CFLAGS = -g
LDFLAGS = -nostdlib -nostartfiles -static
GLIBCDIR = /home/my_acct/glibc_install/lib
STARTFILES = $(GLIBCDIR)/crt1.o $(GLIBCDIR)/crti.o `gcc --print-file-name=crtbegin.o`
ENDFILES = `gcc --print-file-name=crtend.o` $(GLIBCDIR)/crtn.o
LIBGROUP = -Wl,--start-group $(GLIBCDIR)/libc.a -lgcc -lgcc_eh -Wl,--end-group
$(TARGET): $(OBJ)
$(CC) $(LDFLAGS) -o $# $(STARTFILES) $^ $(LIBGROUP) $(ENDFILES)
$(OBJ): $(SRC)
$(CC) $(CFLAGS) -c $^
clean:
rm -f *.o *.~ $(TARGET)
Setup 1: compile your own glibc without dedicated GCC and use it
Without static also working at: Multiple glibc libraries on a single host
This setup might work and is quick as it does not recompile the whole GCC toolchain, just glibc.
But it is not reliable as it uses host C runtime objects such as crt1.o, crti.o, and crtn.o provided by glibc. This is mentioned at: https://sourceware.org/glibc/wiki/Testing/Builds?action=recall&rev=21#Compile_against_glibc_in_an_installed_location Those objects do early setup that glibc relies on, so I wouldn't be surprised if things crashed in wonderful and awesomely subtle ways.
For a more reliable setup, see Setup 2 below.
Build glibc and install locally:
export glibc_install="$(pwd)/glibc/build/install"
git clone git://sourceware.org/git/glibc.git
cd glibc
git checkout glibc-2.28
mkdir build
cd build
../configure --prefix "$glibc_install"
make -j `nproc`
make install -j `nproc`
Setup 1: verify the build
test_glibc.c
#define _GNU_SOURCE
#include <assert.h>
#include <gnu/libc-version.h>
#include <stdatomic.h>
#include <stdio.h>
#include <threads.h>
atomic_int acnt;
int cnt;
int f(void* thr_data) {
for(int n = 0; n < 1000; ++n) {
++cnt;
++acnt;
}
return 0;
}
int main(int argc, char **argv) {
/* Basic library version check. */
printf("gnu_get_libc_version() = %s\n", gnu_get_libc_version());
/* Exercise thrd_create from -pthread,
* which is not present in glibc 2.27 in Ubuntu 18.04.
* https://stackoverflow.com/questions/56810/how-do-i-start-threads-in-plain-c/52453291#52453291 */
thrd_t thr[10];
for(int n = 0; n < 10; ++n)
thrd_create(&thr[n], f, NULL);
for(int n = 0; n < 10; ++n)
thrd_join(thr[n], NULL);
printf("The atomic counter is %u\n", acnt);
printf("The non-atomic counter is %u\n", cnt);
}
Compile and run with test_glibc.sh:
#!/usr/bin/env bash
set -eux
rm -rf tmp
mkdir tmp
gcc \
-L "${glibc_install}/lib" \
-I "${glibc_install}/include" \
-Wl,--rpath="${glibc_install}/lib" \
-Wl,--dynamic-linker="${glibc_install}/lib/ld-linux-x86-64.so.2" \
-static \
-std=c11 \
-o tmp/test_glibc.out \
-v \
test_glibc.c \
-pthread \
;
sudo chroot tmp /test_glibc.out
The program outputs the expected:
gnu_get_libc_version() = 2.28
The atomic counter is 10000
The non-atomic counter is 8674
even though we ran it on a clean chroot, so the -static must have worked.
Command adapted from https://sourceware.org/glibc/wiki/Testing/Builds?action=recall&rev=21#Compile_against_glibc_in_an_installed_location but --sysroot made it fail with:
cannot find /home/ciro/glibc/build/install/lib/libc.so.6 inside /home/ciro/glibc/build/install
so I removed it.
ldd output confirms that the ldd and libraries that we've just built are actually being used as expected:
+ ldd test_glibc.out
linux-vdso.so.1 (0x00007ffe4bfd3000)
libpthread.so.0 => /home/ciro/glibc/build/install/lib/libpthread.so.0 (0x00007fc12ed92000)
libc.so.6 => /home/ciro/glibc/build/install/lib/libc.so.6 (0x00007fc12e9dc000)
/home/ciro/glibc/build/install/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fc12f1b3000)
The gcc compilation debug output shows that my host runtime objects were used, which is bad as mentioned previously, but I don't know how to work around it, e.g. it contains:
COLLECT_GCC_OPTIONS=/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crt1.o
Setup 1: modify glibc
Now let's modify glibc with:
diff --git a/nptl/thrd_create.c b/nptl/thrd_create.c
index 113ba0d93e..b00f088abb 100644
--- a/nptl/thrd_create.c
+++ b/nptl/thrd_create.c
## -16,11 +16,14 ##
License along with the GNU C Library; if not, see
<http://www.gnu.org/licenses/>. */
+#include <stdio.h>
+
#include "thrd_priv.h"
int
thrd_create (thrd_t *thr, thrd_start_t func, void *arg)
{
+ puts("hacked");
_Static_assert (sizeof (thr) == sizeof (pthread_t),
"sizeof (thr) != sizeof (pthread_t)");
Then recompile and re-install glibc, and recompile and re-run our program:
cd glibc/build
make -j `nproc`
make -j `nproc` install
./test_glibc.sh
and we see hacked printed a few times as expected.
This further confirms that we actually used the glibc that we compiled and not the host one.
Tested on Ubuntu 18.04.
Setup 2: crosstool-NG pristine setup
This is an alternative to setup 1, and it is the most correct setup I've achieved far: everything is correct as far as I can observe, including the C runtime objects such as crt1.o, crti.o, and crtn.o.
In this setup, we will compile a full dedicated GCC toolchain that uses the glibc that we want.
The only downside to this method is that the build will take longer. But I wouldn't risk a production setup with anything less.
crosstool-NG is a set of scripts that downloads and compiles everything from source for us, including GCC, glibc and binutils.
Yes the GCC build system is so bad that we need a separate project for that.
This setup is only not perfect because crosstool-NG does not support building the executables without extra -Wl flags, which feels weird since we've built GCC itself. But everything seems to work, so this is only an inconvenience.
Get crosstool-NG and configure it:
git clone https://github.com/crosstool-ng/crosstool-ng
cd crosstool-ng
git checkout a6580b8e8b55345a5a342b5bd96e42c83e640ac5
export CT_PREFIX="$(pwd)/.build/install"
export PATH="/usr/lib/ccache:${PATH}"
./bootstrap
./configure --enable-local
make -j `nproc`
./ct-ng x86_64-unknown-linux-gnu
./ct-ng menuconfig
The only mandatory option that I can see, is making it match your host kernel version to use the correct kernel headers. Find your host kernel version with:
uname -a
which shows me:
4.15.0-34-generic
so in menuconfig I do:
Operating System
Version of linux
so I select:
4.14.71
which is the first equal or older version. It has to be older since the kernel is backwards compatible.
Now you can build with:
env -u LD_LIBRARY_PATH time ./ct-ng build CT_JOBS=`nproc`
and now wait for about thirty minutes to two hours for compilation.
Setup 2: optional configurations
The .config that we generated with ./ct-ng x86_64-unknown-linux-gnu has:
CT_GLIBC_V_2_27=y
To change that, in menuconfig do:
C-library
Version of glibc
save the .config, and continue with the build.
Or, if you want to use your own glibc source, e.g. to use glibc from the latest git, proceed like this:
Paths and misc options
Try features marked as EXPERIMENTAL: set to true
C-library
Source of glibc
Custom location: say yes
Custom location
Custom source location: point to a directory containing your glibc source
where glibc was cloned as:
git clone git://sourceware.org/git/glibc.git
cd glibc
git checkout glibc-2.28
Setup 2: test it out
Once you have built he toolchain that you want, test it out with:
#!/usr/bin/env bash
set -eux
install_dir="${CT_PREFIX}/x86_64-unknown-linux-gnu"
rm -rf tmp
mkdir tmp
PATH="${PATH}:${install_dir}/bin" \
x86_64-unknown-linux-gnu-gcc \
-Wl,--dynamic-linker="${install_dir}/x86_64-unknown-linux-gnu/sysroot/lib/ld-linux-x86-64.so.2" \
-Wl,--rpath="${install_dir}/x86_64-unknown-linux-gnu/sysroot/lib" \
-static \
-v \
-o tmp/test_glibc.out \
test_glibc.c \
-pthread \
;
sudo chroot tmp /test_glibc.out
Everything seems to work as in Setup 1, except that now the correct runtime objects were used:
COLLECT_GCC_OPTIONS=/home/ciro/crosstool-ng/.build/install/x86_64-unknown-linux-gnu/bin/../x86_64-unknown-linux-gnu/sysroot/usr/lib/../lib64/crt1.o
Setup 2: failed efficient glibc recompilation attempt
It does not seem possible with crosstool-NG, as explained below.
If you just re-build;
env -u LD_LIBRARY_PATH time ./ct-ng build CT_JOBS=`nproc`
then your changes to the custom glibc source location are taken into account, but it builds everything from scratch, making it unusable for iterative development.
If we do:
./ct-ng list-steps
it gives a nice overview of the build steps:
Available build steps, in order:
- companion_tools_for_build
- companion_libs_for_build
- binutils_for_build
- companion_tools_for_host
- companion_libs_for_host
- binutils_for_host
- cc_core_pass_1
- kernel_headers
- libc_start_files
- cc_core_pass_2
- libc
- cc_for_build
- cc_for_host
- libc_post_cc
- companion_libs_for_target
- binutils_for_target
- debug
- test_suite
- finish
Use "<step>" as action to execute only that step.
Use "+<step>" as action to execute up to that step.
Use "<step>+" as action to execute from that step onward.
therefore, we see that there are glibc steps intertwined with several GCC steps, most notably libc_start_files comes before cc_core_pass_2, which is likely the most expensive step together with cc_core_pass_1.
In order to build just one step, you must first set the "Save intermediate steps" in .config option for the intial build:
Paths and misc options
Debug crosstool-NG
Save intermediate steps
and then you can try:
env -u LD_LIBRARY_PATH time ./ct-ng libc+ -j`nproc`
but unfortunately, the + required as mentioned at: https://github.com/crosstool-ng/crosstool-ng/issues/1033#issuecomment-424877536
Note however that restarting at an intermediate step resets the installation directory to the state it had during that step. I.e., you will have a rebuilt libc - but no final compiler built with this libc (and hence, no compiler libraries like libstdc++ either).
and basically still makes the rebuild too slow to be feasible for development, and I don't see how to overcome this without patching crosstool-NG.
Furthermore, starting from the libc step didn't seem to copy over the source again from Custom source location, further making this method unusable.
Bonus: stdlibc++
A bonus if you're also interested in the C++ standard library: How to edit and re-build the GCC libstdc++ C++ standard library source?
You command line is just bogus. Try:
gcc -nodefaultlibs -static -L~/GLIBC/glibc_install/lib -o myprog myprog.c -lgcc -lc -lgcc -lc
or similar. You omitted -lc, and also erroneously had your libraries before your input files.
And you were searching for a library called libibgcc rather than libgcc...

Resources