Hi, Bryan. On 2 September 2014 13:52, Bryan Hundven <bryanhundven@xxxxxxxxx> wrote: > Shaun, > > On Tue, Sep 2, 2014 at 1:18 PM, Shaun Jackman <sjackman@xxxxxxxxx> wrote: >> Hi, Bryan. >> >> On 2 September 2014 12:04, Bryan Hundven <bryanhundven@xxxxxxxxx> wrote: >>> Shaun, >>> >>>> >>>> On 28 August 2014 11:30, Shaun Jackman <sjackman@xxxxxxxxx> wrote: >>>>> I'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 >>>>> accomplish this? My configure line is: >>>>> >>>>> ../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 >>> On Tue, Sep 2, 2014 at 10:25 AM, Shaun Jackman <sjackman@xxxxxxxxx> wrote: >>>> 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. > > (example glibc kernel-features checks: > 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
