For some reasons I wish to create alias to function
pthread_mutex_trylock(pthread_mutex_t *mutex);
from the glibc to alias named
lab_pthread_mutex_trylock(pthread_mutex_t *mutex);
I try add
weak_alias (__pthread_mutex_trylock, lab_pthread_mutex_trylock)
in the file pthread_mutex_trylock.c (editing source code of the library) and then
./configure --prefix=/home/user/glibc
make
make install
After that I compile my program like
gcc \
-L "/home/user/glibc/lib" \
-I "/home/user/glibc/include" \
-Wl,--rpath="/home/user/glibc/lib" \
-Wl,--dynamic-linker="/home/user/glibc/lib/ld-linux-x86-64.so.2" \
-std=c11 \
-o main.out \
-v \
main.c \
-pthread \
;
ldd ./main.out
./main.out
The ldd script show me that some functions (from default libc) are really from my build of glibc, but use lab_pthread_mutex_trylock(pthread_mutex_t *mutex) causes error.
glibc has very complicated structure and I have quite weak knowledge about build management so I feel that lot of things I should to do was missed by me. Please, help me, it's very important for me...
Error by gcc:
gcc -L "/ home / anahel / glibc-test / lib" -I "/ home / anahel / glibc-test / include" -Wl, - rpath = "/ home / anahel / glibc-test / lib" -Wl , - dynamic-linker = "/ home / anahel / glibc-test / lib / ld-linux-x86-64.so.2" -std = c11 -o main.out main.c -pthread
/ usr / bin / ld: /tmp/ccivqLEz.o: in the "main" function:
main.c :(. text + 0x1b): undefined reference to "lab_pthread_mutex_trylock"
collect2: error: ld returned 1 exit status
The steps I did in glibc sources:
1) If file glibc-2.31/nptl/pthread_mutex_trylock.c I added
weak_alias (__pthread_mutex_trylock, lab_pthread_mutex_trylock)
2) In file glibc-2.31/sysdeps/nptl/pthread.h I added
extern int lab_pthread_mutex_trylock (pthread_mutex_t *__mutex)
__THROWNL __nonnull ((1));
right after
/* Try locking a mutex. */
extern int pthread_mutex_trylock (pthread_mutex_t *__mutex)
__THROWNL __nonnull ((1));
This error:
undefined reference to "lab_pthread_mutex_trylock"
means that the lab_pthread_mutex_trylock is not exported from /home/user/glibc/lib/libpthread.so.0. You can confirm this with:
nm -D /home/user/glibc/lib/libpthread.so.0 | grep lab_pthread_mutex_trylock
(expect no output if my guess is correct).
The likely reason it's not exported: GLIBC build process tightly controls which functions are exported, and what version they have, via a linker script (which is generated by combining several Version files).
In particular, you very likely need to add lab_pthread_mutex_trylock to the glibc-2.31/nptl/Versions file.
Related
I am currently working on building Glib version 2.45.8 on CentOS 7 running on x86-64 targeting a custom distro based off Linux from Scratch running on x86-64. There is a problem linking with libffi which is version 3.2.1.
path/to/build/directory/bin/ld: warning: libc.so.6, needed by //lib/../libffi.so, not found (try using -rpath or -rpath-link)
path/to/build/directory/lib64/libffi.so: undefined reference to `free#GLIBC_2.2.5'
path/to/build/directory/lib64/libffi.so: undefined reference to `mkostemp#GLIBC_2.7'
(etc ... there are about 15 undefined references total)
path/to/build/directory/lib64/libffi.so: undefined reference to `__getdelim#GLIBC_2.2.5'
path/to/build/directory/lib64/libffi.so: undefined reference to `getenv#GLIBC_2.2.5'
Using -rpath or -rpath-link will not work because the libc.so.6 file does not exist anywhere in the file system for my build.
However I do have libc.so and libc.so.0 in path/to/build/directory/lib64/ the directory in which libc.so.6 cannot be found.
Here are my ./configure and make commmands.
glib_cv_stack_grows=no \
glib_cv_uscore=no \
ac_cv_func_posix_getpwuid_r=yes \
ac_cv_func_posix_getgrgid_r=yes \
LIBFFI_CFLAGS=-lffi \
LIBFFI_LIBS=-lffi \
ZLIB_CFLAGS=-lz \
ZLIB_LIBS=-lz \
PKG_CONFIG_LIBDIR=$TARG/lib/pkgconfig \
./configure --prefix=/ --host=x86_64-linux --with-libiconv
make -j32 LDFLAGS=-liconv
How do I get the correct libc.so to be built?
There we several things that had to be done to solve this problem.
The first thing I found out was that if software has a dependancy on libc.so.6 it was built against glibc.
However our toolchain for this build is using uClibc instead, which does not produce libc.so.6 when it is built.
The solution was to write the LIBFFI and ZLIB clags and libs to link to the libffi and zlib built with uClibc.
glib_cv_stack_grows=no \
glib_cv_uscore=no \
ac_cv_func_posix_getpwuid_r=yes \
ac_cv_func_posix_getgrgid_r=yes \
ZLIB_CFLAGS=-I$TARG/include \
ZLIB_LIBS="-L$TARG/lib -lz" \
LIBFFI_CFLAGS=-I$TARG/include \
LIBFFI_LIBS="$TARG/lib/libffi.a" \
PKG_CONFIG_LIBDIR=$TARG/lib/pkgconfig \
./configure --prefix=/ --host=x86_64-linux --with-libiconv
make -j32 LDFLAGS=-liconv
Hi There
I am trying to cross compile the net-snmp agent (snmpd) for an ARM platform (my STB). I can successful compile the "--mini-agent" version, which isn't very useful (only knows about itself, not the system it runs on). I am a bit along the way (I guess), but I am stumbling over this error to do with libpcre, perhaps somebody can help me out. Here is what I do:
I am using the toolchain "arm-linux-gnueabihf" (I am not even sure, this is the right terminology).
I am downloading net-snmp and running configure like so:
./configure \
--host=arm-linux-gnueabihf \
--target=arm-linux-gnueabihf \
--build=i686 \
--disable-manuals \
--disable-ipv6 \
--with-cc=arm-linux-gnueabihf-gcc \
--with-ar=arm-linux-gnueabihf-ar \
--without-rpm \
--disable-applications \
--disable-embedded-perl \
--disable-deprecated \
--disable-shared \
--enable-static LDFLAGS="-L/home/crayfish/openvuplus_3.0/build/vusolo4k/tmp/sysroots/vusolo4k/usr/lib/libpcre" \
--with-sysroot=/home/crayfish/openvuplus_3.0/build/vusolo4k/tmp/sysroots/vusolo4k/
/home/crayfish/openvuplus_3.0 is where the source code from the STB sits, and there is also the libpcre:
file /home/crayfish/openvuplus_3.0/build/vusolo4k/tmp/sysroots/vusolo4k/usr/lib/libpcre.so.1.2.4
/home/crayfish/openvuplus_3.0/build/vusolo4k/tmp/sysroots/vusolo4k/usr/lib/libpcre.so.1.2.4: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=335b7191beb073ea9f6567442c6269855f4053bc, not stripped
Now, most of this is guess work or trial and error by me, but the configure script runs fine (as far as I can see), but it throws me this error at make:
libtool: link: arm-linux-gnueabihf-gcc -fno-strict-aliasing -g -O2 -Ulinux -Dlinux=linux -Wall -Wstrict-prototypes -Wwrite-strings -Wcast-qual -o snmpd snmpd.o -L/home/crayfish/openvuplus_3.0/build/vusolo4k/tmp/sysroots/vusolo4k/usr/lib/libpcre ./.libs/libnetsnmpagent.a ./.libs/libnetsnmpmibs.a /home/crayfish/code/agent/.libs/libnetsnmpagent.a /home/crayfish/code/snmplib/.libs/libnetsnmp.a -ldl ../snmplib/.libs/libnetsnmp.a -lm
./.libs/libnetsnmpmibs.a(proc.o): In function `proc_parse_config':
/home/crayfish/code/agent/mibgroup/ucd-snmp/proc.c:232: undefined reference to `pcre_compile'
./.libs/libnetsnmpmibs.a(swrun.o): In function `swrun_count_processes_by_regex':
/home/crayfish/code/agent/mibgroup/host/data_access/swrun.c:134: undefined reference to `pcre_exec'
collect2: error: ld returned 1 exit status
make[1]: *** [snmpd] Fehler 1
make[1]: Verzeichnis »/home/crayfish/code/agent« wird verlassen
make: *** [subdirs] Fehler 1
As you might be able to see, I am trying to let the system know, where the libpcre sits, but - for the life of me - I cannot figure out what syntax to use.
So, any and every help would be highly appreciated!!!
Thomas
I'm a dummy regarding C build tools, so I have a forked project to which I want to add a dynamically linked library:
https://github.com/iem-projects/ncview/tree/26c3549d165dc6047dc37db252062fd73eb9282c
Basically, what I need is to include liblo. There is all kinds of voodoo going on for the existing libraries of the project (netcdf for example).
I am trying to follow this manual which basically says, I should add stuff to configure.in and Makefile.am, then run autoreconf, autoconf, and automake, then ./configure and finally make.
This I added to configure.in:
# OSC support
PKG_CHECK_MODULES(LIBLO, liblo >= 0.26)
And this I added to Makefile.am:
bin_PROGRAMS = ncview
ncview_LDADD = $(LIBLO_LIBS)
Now configure is at least successfully checking for that library:
checking for LIBLO... yes
But make doesn't include the library with the linker it seems:
$ make
make all-recursive
Making all in src
/usr/bin/gcc-4.2 -I/usr/X11/include -g -O2 -L/opt/local/lib -lnetcdf -lSM -lICE \
-L/usr/X11/lib -R/usr/X11/lib -lX11 -L/usr/X11/lib -R/usr/X11/lib -Wl,-rpath, -o \
ncview ncview.o file.o util.o do_buttons.o file_netcdf.o view.o do_print.o \
epic_time.o interface.o x_interface.o dataedit.o display_info.o plot_xy.o utils.o \
range.o printer_options.o overlay.o filesel.o set_options.o plot_range.o udu.o \
SciPlot.o RadioWidget.o cbar.o utCalendar2_cal.o calcalcs.o colormap_funcs.o \
make_tc_data.o stringlist.o handle_rc_file.o -lm -L/opt/local/lib -lnetcdf -lXaw \
-lXt -L/usr/X11/lib -R/usr/X11/lib -lSM -lICE -L/usr/X11/lib -R/usr/X11/lib -lX11 \
-L/usr/X11/lib -R/usr/X11/lib -lpng
Undefined symbols:
"_lo_address_new", referenced from:
_main in ncview.o
"_lo_send_internal", referenced from:
_main in ncview.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
So it links the old libraries (netcdf, X11), but doesn't pick up the one I added (liblo)
This whole makefile business is black magic to me, so any clues as to why the library doesn't get linked is welcome.
Solution:
The the hint of AC_SUBST, and looking again closer at the way the other libraries were integrated, I managed to get it working. Nothing had to be added to Makefile.am. In configure.in (aka configure.ac), the following was added:
# OSC support
PKG_CHECK_MODULES(LIBLO, liblo >= 0.26)
LIBSsave=$LIBS
CFLAGSsave=$CFLAGS
CFLAGS=$LIBLO_CFLAGS
LIBS=$LIBLO_LIBS
# AC_MSG_CHECKING([for liblo OSC library])
# AC_MSG_RESULT()
# AC_CHECK_LIB(LIBLO,lo_address_new,[],[libloWorks=no])
echo "liblo OSC library: $LIBLO_LIBS"
AC_SUBST(LIBLO_CFLAGS) # si?
AC_SUBST(LIBLO_LIBS)
LIBS+=$LIBSsave
CFLAGS+=$CFLAGSsave
After PKG_CHECK_MODULES, the variables LIBIO_CFLAGS and LIBIO_LIBS should be defined. At this point, you should add:
AC_SUBST(LIBIO_CFLAGS)
AC_SUBST(LIBIO_LIBS)
to the configure.ac file. The Makefile.am then needs to make use of these substitutions:
ncview_CPPFLAGS = $(LIBIO_CFLAGS)
ncview_LDADD = $(LIBIO_LIBS)
you can also directly substitute the value of LIBLO-flags with a syntax like:
configure.ac:
PKG_CHECK_MODULES(LIBLO, liblo >= 0.26)
Makefile.am:
ncview_LDADD += #LIBLO_LIBS#
you should also take care not to overwrite previous values of LDADD (or the other way round, so your values get overwritten)
ncview_LDADD = #LIBLO_LIBS#
ncview_LDADD = -lm
should give you a warning and #LIBLO_LIBS# will have no effect.
What's the best way to tell CMake to use the LLVM linker llvm-link instead of GNU ld as linker? When configuring a project with
CXX=clang++ cmake <args>
the default linker appears to be untouched, remaining usr/bin/ld (on Linux).
Is this possible without using a separate toolchain file?
This turns out to be unrelated to CMake: clang++ uses the system linker by default. For example,
echo "#include <atomic>\n int main() { return 0; }" \
| clang++ -x c++ -std=c++11 -stdlib=libc++ -
uses /usr/bin/ld to link the application. To change the linker to llvm-link, one needs to first emit LLVM byte code, and then call the linker, e.g.:
echo "#include <atomic>\n int main() { return 0; }" \
| clang++ -x c++ -std=c++11 -stdlib=libc++ -S -emit-llvm -o - - \
| llvm-link -o binary -
This bypasses /usr/bin/ld.
As of 3.4, clang looks for the linker (ld) at GCCInstallation.getParentLibPath() + "/../" + GCCInstallation.getTriple().str() + "/bin" before it looks for ld on the path. You should be able to put your linker in /usr/lib/gcc/<arch><sub>-<vendor>-<sys>-<abi>/<version>/ld and have it called by clang in 1 step. To specify this location manually, use the undocumented -B flag. Unfortunately, I don't believe there is a way to alter the name of the linker that is searched for so using ld.gold or lld is going to require a symlink at the aforementioned location.
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...