| Summary: | modified glibc for building a cross compiler tool chain | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | James Boddington (RETIRED) <aiken> |
| Component: | [OLD] Core system | Assignee: | SpanKY <vapier> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | carpaski, lisa, toolchain, Uwe_Reimann |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 17858, 18034, 18936 | ||
| Attachments: |
patch for glibc-2.3.1-r3
Patch which makes the cris port of glibc-2.3.1 export register_frame_info and the like correctly Fixes alignment issues of the stat struct Fixes syscall with more than 4 arguments for the cris architecture |
||
Created attachment 9716 [details, diff]
patch for glibc-2.3.1-r3
This looks pretty good at first and second glance, but it needs some play before I am ready to check it in. One issue from quick peeking. 'RESTRICT="nostrip"' only do not help, you need to set DEBUGBUILD as well. Would you be able to clarify about DEBUGBUILD in preference to RESTRICT please?
My preference is to have prepallstrip smart enough that the correct strip is used but
this is not the case yet. I find RESTRICT=nostip gives me a functional cross glibc. I
have tried ${CCHOST}-stip at the end of src_install() and this also works.
I am just unsure on what DEBUGBUILD would give me over RESTRICT.
You can check to verify, but prepstrip and prepallstrip only do not strip:
if [ -n "${DEBUGBUILD}" ]
I think RESTRICT=nostrip should set DEBUGBUILD, but it does not currently.
Nick ?
Created attachment 12709 [details, diff]
Patch which makes the cris port of glibc-2.3.1 export register_frame_info and the like correctly
This patch makes the cris port of glibc export symbols like
__register_frame_info correctly. Without this patch you won't be able to
cross-compile glibc for cris with the cris-axis-linux-gnu toolchain.
Note: with this patch I managed to compile glibc-2.3.1 with gcc-3.2.3 for cris.
The library still didn't work correctly on the target. AFAIK this is because of
another bug. I am in contact with glibc-maintainers to catch this one, too.
Best regards, Shagoon
Created attachment 12774 [details, diff] Fixes alignment issues of the stat struct With this patch I was able to cross compile a chrootable environment for cris. Bash still seems to have some problems, I am investigating further. Visit http://sources.redhat.com/ml/libc-alpha/2003-06/msg00006.html for additional information. Aiken, please include this patch into glibc-2.3.1-r6.ebuild. Cheers, Shagoon Created attachment 12918 [details, diff]
Fixes syscall with more than 4 arguments for the cris architecture
This patch makes glibc-2.3.1 for cris actually usable. It seems to have the
same quality as the official cris-dist-glibc-1.25, which is derived from
~glibc-2.2.3.
Aiken, please include the patch in glibc's ebuild.
Cheers, Shagoon
I'm actually working on a cross-compiler script that should...alliviate this corss-compiling stuff. It more or less invalidates this bug, but with regards to the cris architecture, I had a question for Shagoon. Shagoon: with glibc-2.3.2, know of a patch for sysdeps/cris/sysdep.h that adds INTERNAL_SYSCALL_DECL()? Seems to be a missing feature for 2.3.2 versions of glibc. I came across this while testing out my cross-compiling script to build a cris cross-toolchain. Came across some of the Zynot stuff you had, but didn't find much else that looked to resolve the problem, and I doubt hacking up another arch's sysdep.h in glibc to add it to cris' sysdep.h is a very wise thing. Joshua, if you need a glibc that compiles for cris I'd suggest that you take glibc-2.3.1-r4.ebuild from Zynot's cris-branch that I maintain. This is the only glibc > ~2.2.5 that compiles for cris that I know of. Depending on your version of binutils and gcc, you might also need to use some of the cris specific patches that are part of the respective ebuilds. If you need glibc-2.3.2 I guess you're pretty much on your own. The maintainer of cris' port of glibc currently is not actively working on it. Btw., you probably want to patch sysdeps/unix/sysv/linux/cris/sysdep.h rather than sysdeps/cris/sysdep.h. I might have a look at glibc-2.3.2 in the near future ;-) Cheers, Shagoon Shagoon: It's not overly important. I simply ran across the issue while trying to test a cross-compiling script I've been bashing out, and thought to give it a spin on a relatively unknown and rare architecture (at least to me). The issue from the offstart seems like a simple fix, but considering I don't own any cris-related equipment and that it's not even an official Gentoo port, I likely won't attempt any patching. I'll just leave a note in my script that cris will not build fully using glibc-2.3.2. I also hear it's bad to add code from other arch-specific sections of glibc if you don't know what you're doing :) now supported in glibc-2.3.4.20040808-r1 or glibc-2.3.4.20041102 |
This patch allows the glibc ebuild to be used to build the normal glibc or glibc as part of a cross compiler tool chain. Reproducible: Always Steps to Reproduce: 1. something like emerge glibc Install the system glibc 2. CCHOST=sparc-unknown-linux-gnu USE="build sparc" ARCH=sparc glibc Install glibc as part of a cross tool chain in /usr/$CCHOST/