| Summary: | gcc-3.3: emerge grub fails | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | FL <flonai> |
| Component: | [OLD] GCC Porting | Assignee: | John Mylchreest (RETIRED) <johnm> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | cretin, hanno, lv, mrickard, nwourms, tester, woodchip |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
diff file to allow configure.in configure correctly for gcc 3.3
diff file to allow configure.in configure correctly for gcc 3.3 diff to fix fsys_jfs compile errors fix fsys_reiserfs.diff an ebuild to use the CVS snapshot, not completely working... |
||
|
Description
FL
2003-05-18 16:45:38 UTC
Need some help here. If I fix the invalid declaration: ------------------------------------------------------------------- --- grub-0.93/stage2/fsys_reiserfs.c.orig 2003-05-19 01:44:07.000000000 +0200 +++ grub-0.93/stage2/fsys_reiserfs.c 2003-05-19 01:44:15.000000000 +0200 @@ -112,7 +112,7 @@ /* offset in the log of where to start replay after a crash */ __u32 j_first_unflushed_offset; /* mount id to detect very old transactions */ - __u32 long j_mount_id; + __u64 j_mount_id; }; /* magic string to find desc blocks in the journal */ ------------------------------------------------------------------- It ends up with this link problem: ------------------------------------------------------------------- gcc -g -o pre_stage2.exec -nostdlib -nostdinc -Wl,-N -Wl,-Ttext -Wl,8200 pre_stage2_exec-asm.o pre_stage2_exec-bios.o pre_stage2_exec-boot.o pre_stage2_exec-builtins.o pre_stage2_exec-char_io.o pre_stage2_exec-cmdline.o pre_stage2_exec-common.o pre_stage2_exec-console.o pre_stage2_exec-disk_io.o pre_stage2_exec-fsys_ext2fs.o pre_stage2_exec-fsys_fat.o pre_stage2_exec-fsys_ffs.o pre_stage2_exec-fsys_jfs.o pre_stage2_exec-fsys_minix.o pre_stage2_exec-fsys_reiserfs.o pre_stage2_exec-fsys_vstafs.o pre_stage2_exec-fsys_xfs.o pre_stage2_exec-gunzip.o pre_stage2_exec-hercules.o pre_stage2_exec-md5.o pre_stage2_exec-serial.o pre_stage2_exec-smp-imps.o pre_stage2_exec-stage2.o pre_stage2_exec-terminfo.o pre_stage2_exec-tparm.o pre_stage2_exec-graphics.o pre_stage2_exec-builtins.o(.text+0x3776): In function `terminfo_func': /space/var/tmp/portage/grub-0.93.20030118/work/grub-0.93/stage2/builtins.c:4347: undefined reference to `memcpy' pre_stage2_exec-terminfo.o(.text+0x206): In function `ti_set_term': /space/var/tmp/portage/grub-0.93.20030118/work/grub-0.93/stage2/terminfo.c:250: undefined reference to `memcpy' pre_stage2_exec-terminfo.o(.text+0x21f): In function `ti_get_term': /space/var/tmp/portage/grub-0.93.20030118/work/grub-0.93/stage2/terminfo.c:257: undefined reference to `memcpy' collect2: ld returned 1 exit status ------------------------------------------------------------------- In stage2/shared.h 'memcpy' is defined as: #define memcpy grub_memcpy which is in char_io.c, and is in above link. I don't think you fixed the declaration correctly. The top of fsys_reiserfs.c has the following definitions: typedef unsigned int __u32; typedef unsigned long long __u64; Therefore, "__u32 long" should be "unsigned int long", not "__u64" or "unsigned long long". Using that definition, I created the following patch that allows grub to build without any problems. It is the one I used when I recompiled my entire system with gcc 3.3. ------------------------------------------------------------------- --- grub-0.92/stage2/fsys_reiserfs.c-original 2003-03-10 01:09:25.000000000 -0500 +++ grub-0.92/stage2/fsys_reiserfs.c 2003-03-10 01:09:47.000000000 -0500 @@ -112,7 +112,7 @@ /* offset in the log of where to start replay after a crash */ __u32 j_first_unflushed_offset; /* mount id to detect very old transactions */ - __u32 long j_mount_id; + unsigned long int j_mount_id; }; /* magic string to find desc blocks in the journal */ ------------------------------------------------------------------- Then __u64 is defined wrong in the first place. What version binutils ? sys-devel/binutils-2.13.90.0.18 Portage 2.0.47-r10 (default-x86-1.4, gcc-3.3, glibc-2.3.1-r4) ================================================================= System uname: 2.4.20-ck6-gcc33 i686 AMD Athlon(TM) XP1800+ GENTOO_MIRRORS="http://gentoo.oregonstate.edu/ http://distro.ibiblio.org/pub/Linux/distributions/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/root/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="/usr/local/portage" USE="x86 oss 3dnow apm avi crypt cups encode gif jpeg libg++ mmx mpeg ncurses nls pdflib png quicktime spell truetype xml2 xmms xv zlib alsa gdbm berkdb slang readline arts tetex svga java mysql X sdl tcpd pam libwww ssl perl python esd imlib oggvorbis qt kde motif opengl mozilla acpi sse tiff -gpm -mikmod -gtkhtml -bonobo -guile -gnome -gtk" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer" CXXFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer" ACCEPT_KEYWORDS="x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" FEATURES="sandbox buildpkg ccache distcc userpriv usersandbox" Excuse my ignorance, but what does binutils have to do with the definition of __u64? I was looking at the code in grub-0.92/stage2/fsys_reiserfs.c for the declaration of __u64. Based on the comments in the code, it matches the definition in linux/include/asm-i386/types.h. From linux/include/asm-i386/types.h: typedef __signed__ char __s8; typedef unsigned char __u8; typedef __signed__ short __s16; typedef unsigned short __u16; typedef __signed__ int __s32; typedef unsigned int __u32; #if defined(__GNUC__) && !defined(__STRICT_ANSI__) typedef __signed__ long long __s64; typedef unsigned long long __u64; #endif Consequently, I interpreted the "__u32 long" as "unsigned int long" by replacing __u32 with its definition. Nothing more complex than that. Because even with your 'fix' it still have the link problems. Call me an idiot, but I didn't notice that you were using grub-0.93.20030118. It works without any problems on grub-0.92-r1. I will try it on the newer version. The linking issues (after fixing the j_mount_id declaration), is caused by the hammer patch. Nicholas is looking into it. Hi, it seems we are having two bugs here 1. trivial to fix bug in fsys_reiserfs.c 2. linking bug with the "undefined reference to memcpy"-error message. To the second one, there was a thread on the grub-ml, but I don't understand what they did and what was wrong: http://mail.gnu.org/archive/html/bug-grub/2003-01/msg00039.html I'll try out most current GRUB cvs to see if that works. Hidden in the depths of the Other Things Gentoo -> GCC 3.3 thread, there's a CFLAGS-based 'fix' (although a very dirty one) for this: http://forums.gentoo.org/viewtopic.php?p=357180#357180 It appears that the fsys_reiserfs.c problem may be fixed using the CVS checkout, although I've not tried that. The memcpy thing appears to be part of a greater problem related to the hammer patch which is somewhat beyond me... Created attachment 13181 [details]
diff file to allow configure.in configure correctly for gcc 3.3
Created attachment 13182 [details]
diff file to allow configure.in configure correctly for gcc 3.3
Created attachment 13183 [details]
diff to fix fsys_jfs compile errors
Created attachment 13184 [details]
fix fsys_reiserfs.diff
the three diff files uploaded fix problems compiling grub 0.93 with gcc 3.3. Modified from previous grub 0.92 patches *** Bug 22447 has been marked as a duplicate of this bug. *** Ok folks, here's the solution for the undefined memcpy references: pass "-minline-all-stringopts" to CFLAGS after unsetting them. I'll upload an updated grub with some patches and this cflag to fix it. I have just built a GRUB CVS snapshot from 2003-July-08 that compiles with GCC 3.3-r1 now in portage -- no messing around with CFLAGS seemed necessary. I have an ebuild, but it's a hack of the current grub ebuild. I would like help to make it better. Also, the grub that's currently in CVS seems broken to me, which is why I'm using a snapshot. --watersb (I am the person who posted to to the Gentoo Forums regarding the -minline-stringops kludge...) Created attachment 15167 [details]
an ebuild to use the CVS snapshot, not completely working...
This ebuild is a tiny modification of the current grub ebuild. It compiles and
installs, I think; grub complains about an error at the install stage. It could
use some help!
But it does compile on GCC 3.3, and against the kernel 2.6 headers.
ebuild with patches, tested and aplly/compile cleanly can be found at: http://dev.gentoo.org/~johnm Azarah, if you want me to take this bug just gimme a shout. GRUB still wont compile with >=sys-devel/gcc-3.3, and still is easily fixed by a patch I submitted "2003-06-08 10:15 EST" in a bug marked as a duplicate of this one. The patches listed in this bug, as far as I can tell, contain the important parts of that patch (but not a few changes that arent really as important). so... 85 days later we've still only recently started (47 days ago) using a compiler that was released 129 days ago (gcc 3.2.3), and this bug hasnt been given all that much attention even though there is a fix readily available. My opinion might not matter much, but everything I use works with gcc 3.3.1 or patches are available. I dont know about much else other than what I use and what I've seen bugs for on bugs.gentoo.org so I could very easily be mistaken... but I think some work should be done towards transitioning to gcc 3.3.1 (especially with it's code speed improvements, at least compared to 3.3 or 3.2.3 for me... and taking into account I use the new gcc 3.3+ -ftracer flag). I think that packages that dont compile using gcc 3.3.1 now can either be patched or accomidated for by giving gcc 3.3* it's own slot for convenience and compiling apps that need to using gcc 3.2.3. I am completely unaware of whether or not all needed patches have been ported to gcc 3.3.1 but I've been using it for everything I can. -damn- have I noticed a difference (on my 1.8Ghz celeron system) in comparison to the latest GRP binaries for pentium4 which are indeed compiled with some pretty aggressive optimisations if the default CFLAGS setting is any indicator, and all I use for CFLAGS is "-pipe -O3 -march=pentium4 -ftracer". bah. and please forgive me for placing the above rant in a bug report... but what's the holdup on this patch set? Are there issues with this I'm completely unaware of here? Would it be possible to get this in the portage tree, even if only as an unstable ebuild with it's arch set to "-x86"? Travis is absolutely right. This bug has scared away at least one new gentoo user. (not me, but my friend). This patch works so ffs please change the portage. With all due respect can i please ask for you to be patient in relation to bugs, many of us are very busy. Anywho, I have taken this bug on board and i will do it after work today. in the meantime i have had this ebuild around for a while now: http://dev.gentoo.org/~johnm/ yo might find it of use. Added to portage. please emerge sync and try again in approx. 15 minutes. Enjoy :) marking fixed |
