Hi, Bryan.
Post by Bryan HundvenShaun,
Post by Shaun JackmanHi, Bryan.
Post by Bryan HundvenShaun,
Post by Shaun JackmanI'm attempting to compile a native GCC compiler that uses a newly
downloaded set of Linux headers and a newly compiled glibc. These two
packages are installed in different directories. I'd like to specify
--with-native-system-header-dir twice, once for each set of headers. I
didn't in fact try that, but I'm guessing that it's not supported. I
tried using --with-headers, but it's supported only for cross
compiles. Is there a set of configuration parameters that I can use to
../configure --with-sysroot=/home/sjackman/.linuxbrew
--prefix=/Cellar/xgcc/4.9.1
--with-native-system-header-dir=/opt/glibc/include
The glibc headers are installed in $sysroot/opt/glibc/include.
The linux headers are installed in $sysroot/opt/linux-headers/include
and also symlinked into $sysroot/include.
Thanks,
Shaun
http://sjackman.ca
The simple work around to this problem is to symlink both the glibc
and Linux headers into the single directory specified with
--with-native-system-header-dir. It would still be nice to be able to
specify multiple header directories. gettext (libintl.h) seems to be a
third dependency of building GCC --with-sysroot.
I understand what you are trying to do. My question is to find out
your intentions; Why do you feel it is necessary to separate headers
that belong in one $sysroot/$prefix/include directory?
-Bryan
Homebrew is a package manager for Mac OS. I maintain the port of
Homebrew for Linux, named Linuxbrew. The file arrangement in Homebrew
is that each package is installed in $prefix/Cellar/$package/$version
and then {bin,include,lib} of that package are optionally symlinked
into $prefix/{bin,include,lib}. The most recent version of each
package is also symlinked into $prefix/opt/$package. $prefix is the
installation directory of Homebrew, typically ~/.linuxbrew
I'd like to be able to compile GCC --with-sysroot without requiring
that glibc be symlinked into $prefix. Within Linuxbrew, executables
are compiled with their rpath set to $prefix/lib so that they can find
libraries installed by Linuxbrew. Additionally executables compiled
against a Homebrew-compiled-and-installed glibc have the
dynamic-linker set to that of the new GLIBC using
-Wl,--dynamic-linker.
If a particular executable is compiled against the system glibc, and
the new glibc is symlinked into $prefix/lib, it can cause the error
"ELF file OS ABI invalid". I'd like to support compiling executables
either with the system GCC and glibc or the Homebrew-managed GCC and
glibc, which precludes linking libc.so.6 into $prefix/lib due to
setting rpath to $prefix/lib.
For now I'm making progress by symlinking Linux headers, glibc and
libintl.h into $sysroot.
Cheers,
Shaun
Glibc, and pretty much any other libc I know of, is built against the
Operating System's headers to enable or disable features in the libc.
Upgrading the Operating System headers without rebuilding the libc may
produce UB (Undefined Behavior). In otherwords, Glibc has a hard
dependency on the Operating System headers. I say Operating System
headers, instead of Linux headers, because Glibc can also work with
*BSD, Solaris, and other Operating Systems besides just Linux.
For instance, what would happen if a system call the was previously
disabled in the Linux headers, and hence disabled in glibc, then the
system call was enabled in the linux headers (via the .config), and
glibc was not rebuilt? UB.
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/kernel-features.h
and there are more per architecture.)
-Bryan
A fresh copy of the Linux headers are installed using `make
headers_install` to avoid this dependency on the operating system's
headers. If it's possible to compile a cross-compiler on Mac OS that
targets Linux, then it should be possible to compile a compiler on
Linux that targets a different version of Linux, although the
mechanics of this appear trickier. The glibc configuration provides
the --with-headers and --enable-kernel options for this purpose.
http://www.gnu.org/software/libc/manual/html_node/Configuring-and-compiling.html
‘--with-headers=directory’Look for kernel header files in directory,
not /usr/include. The GNU C Library needs information from the
kernel's header files describing the interface to the kernel. The GNU
C Library will normally look in /usr/include for them, but if you
specify this option, it will look in DIRECTORY instead.
This option is primarily of use on a system where the headers in
/usr/include come from an older version of the GNU C Library.
Conflicts can occasionally happen in this case. You can also use this
option if you want to compile the GNU C Library with a newer set of
kernel headers than the ones found in /usr/include.
‘--enable-kernel=version’This option is currently only useful on
GNU/Linux systems. The version parameter should have the form X.Y.Z
and describes the smallest version of the Linux kernel the generated
library is expected to support. The higher the version number is, the
less compatibility code is added, and the faster the code gets.
Cheers,
Shaun