• Immutable PageInfoAttachments

glibc build issues

glibc upstream

glibc upstream don't want people to file reports of build problems in glibc's Bugzilla. See Bug #333.

Build slowness

The glibc build system is very slow even when nothing needs rebuilding. See this post on bug-make.

I have a patch to GNU make which speeds up make's handling of large numbers of rules: rules-speedup branch on Github

Stack protector: Building on Ubuntu feisty

Problem: Fails while linking elf/ld-linux.so.2:

/work/plash/glibc-2.5-objs/elf/librtld.os: In function `print_statistics': rtld.c:(.text+0x7b3): undefined reference to `__stack_chk_fail_local' ...

Cause appears to be passing "CC=gcc-4.1" to configure. The normal feisty build passes CC="gcc-4.1 -fno-stack-protector". (Note that this is passed via the environment and is not included in the argument list in config.log.)

See GccSsp

"Hidden" symbol visibility

The linker allows a ".hidden" flag to be set on symbols in object files. gcc's __attribute((visibility("hidden"))) will set this. When the symbol is linked into a shared object, this flag prevents the symbol from being externally visible. The symbol is excluded even if it is listed in a map file (and no error is given). Note that this flag can be set in an object file where the symbol is undefined, not just in the object file where the symbol is defined. So if a use site thinks the symbol should be hidden, the symbol will disappear from the shared object.

This flag is not displayed by nm. Use objdump -x to find out whether it is set.

Problem building glibc 2.5: __open_nocancel is being set as "hidden". However, we need libc.so to export it because libpthread.so imports it.

Quick solution: Export the symbol under the name __libc_open_nocancel instead of __open_nocancel. Add a wrapper to libpthread-extras.c to map the name back again. (Note that prior to this, libpthread-extras.c was for functions that are exported by libpthread.so and not just imported to be used internally.) See 549.

A better solution would be to stop the "hidden" flag being set in the first place, or to override it.

References:

• • gcc function attributes: covers __attribute__((visibility("hidden")))

  • gcc code generation options: covers -fvisibility

  • The assembler's .hidden directive

  • Visibility on glibc wiki: this only explains it in relation to C++

vm86 problem

make[3]: *** No rule to make target `/work/plash/glibc-2.4-objs/misc/vm86.o', needed by `/work/plash/glibc-2.4-objs/misc/stamp.o'. Stop.

This happened because sysd-syscalls got built when glibc was accidentally configured for an x86_64 build, which is what happens when configure is called without --host and --build options when running on 64-bit kernel, even with a 32-bit userland. The solution is to delete the build directory and start again.

Mixing autoconf versions #1

... running configure fragment for sysdeps/i386/elf checking for i386 TLS support... yes running configure fragment for nptl/sysdeps/pthread checking for forced unwind support... ../glibc-source/nptl/sysdeps/pthread/configure: line 67: conftest: command not found no configure: error: forced unwind support is required make: *** [stamp-configure-glibc] Error 1

See PlashIssues/BuildFailureEdgy

Mixing autoconf versions #2

running configure fragment for sysdeps/x86_64/elf ../glibc-source/sysdeps/x86_64/elf/configure: line 6: configure:6: checking for x86-64 TLS support: command not found ../glibc-source/sysdeps/x86_64/elf/configure: line 7: checking for x86-64 TLS support... : command not found ../glibc-source/sysdeps/x86_64/elf/configure: line 28: configure:28: $? = 0: command not found ../glibc-source/sysdeps/x86_64/elf/configure: line 36: configure:36: result: yes: command not found y y y y ...

This happens if you regenerate the top configure with a version of autoconf that is too old. It doesn't define $as_echo, which the nested configure scripts expect.

libc.so marked as requiring an executable stack

checking whether --noexecstack is desirable for .S files... no

See PlashIssues/LintianExecutableStack

Configure error about crypt add-on

configure: error: *** It seems that you're using an old `crypt' add-on. crypt is now *** part of glibc and using the old add-on will not work with this *** release. Start again with fresh sources and without the old *** `crypt' add-on.

This can happen when you've checked glibc out of CVS without the -P option ("Prune empty directories") that cvs co and cvs up take. It means CVS checks out the empty crypt/sysdeps directory which makes configure think crypt is an add-on. Put this in your~/.cvsrc and do cvs up:

update -dP

dpkg-buildpackage sets LDFLAGS on Ubuntu

On Ubuntu (as of hardy), dpkg-buildpackage sets LDFLAGS to contain -Wl,-Bsymbolic-functions. This does not cause any compile-time errors, but it subtly breaks ld.so so that free() is used on non-malloc()'d pointers, causing free() to abort or segfault. SeePlashIssues/Segfault for details.

cpuid.h error

checking cpuid.h usability... no checking cpuid.h presence... no checking for cpuid.h... no configure: error: gcc must provide the <cpuid.h> header

This indicates that you need to use a newer gcc. See http://bugs.gentoo.org/292174.

Inlining failed

When building on Ubuntu:

In file included from ../sysdeps/unix/sysv/linux/syslog.c:10: ../misc/syslog.c: In function '__vsyslog_chk': ../misc/syslog.c:123: sorry, unimplemented: inlining failed in call to 'syslog': function body not available ../misc/syslog.c:155: sorry, unimplemented: called from here

Need to add -U_FORTIFY_SOURCE to the gcc invocation. I found this in Ubuntu's Debian packaging for glibc. I believe this is an Ubuntuism. Ubuntu enables -D_FORTIFY_SOURCE=2 by default. See Ubuntu's CompilerFlags wiki page.

glibc bug 10375 reports this issue, but it has not been addressed.

Failure linking fallocate

Got this error when building a recent glibc (2.10) on an old Ubuntu (feisty):

/work/plash/plash/glibc-build/libc_pic.os: In function `fallocate': (.text+0xbc664): undefined reference to `__call_fallocate' /work/plash/plash/glibc-build/libc_pic.os: In function `__fallocate64_l64': (.text+0xbc6a0): undefined reference to `__call_fallocate' /usr/bin/ld: /work/plash/plash/glibc-build/libc.so: hidden symbol `__call_fallocate' isn't defined /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status

http://bugs.gentoo.org/274269 suggests that this happens because the kernel headers are too old.

• Immutable PageInfoAttachments

• MoinMoin PoweredPython PoweredValid HTML 4.01