You should not need to mess with the CFLAGS. Signed-off-by: Andi Kleen <ak [at] suse> Index: linux/arch/x86_64/Makefile =================================================================== --- linux.orig/arch/x86_64/Makefile +++ linux/arch/x86_64/Makefile @@ -31,6 +31,7 @@ cflags-$(CONFIG_MK8) += $(call cc-option cflags-$(CONFIG_MPSC) += $(call cc-option,-march=nocona) CFLAGS += $(cflags-y) +CFLAGS += -m64 Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu11' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix BTW: if there's a better way, please let me know. ...After I got this to work I kinda quit looking ;-) -- Jeffrey Hundstad Attachments: lin64.tar.gz (0.35 KB) rlrevell at joe-job Dec9,2005,5:28PM Post his comment is here
Uros. Lu 2011-07-27 12:56:01 UTC (In reply to comment #3) > (In reply to comment #2) > > > > Assembler should accept R_X86_64_64 and zero-extend it to 8 bytes. Lu July 27, 2011, 4:31 a.m. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo [at] vger More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49860
PR target/49860 * gcc.dg/pr49860.c: New. It ends up with -m64 -m32 for the 32bit vsyscall files, but that seems to DTRT at least in gcc 4. This is no doubt a different issue and I will verify that this is not just from something I missed before I squawk. It is the same issue as .  http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01825.html Comment 2 H.J.
So it's normally better to use a separate cross compiler for 64bit to keep the 32bit compilations running faster. rkiddy commented Dec 29, 2013 VirtualBox is telling me: Operating System: Debian (64 bit) Let me know how best to do it and I can get a more verbose description of Then I got quite a bit on from doing a "make external all". So the assembler must think that it is creating a 64-bit binary.
It is the > > same issue as . > > > >  http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01825.html > > X32 is 32bit environment. The Debian FAQ explains the different versions, but who reads it? ;-) To contrast, in both Fedora and Ubuntu, the default download is the image for 64-bit PCs. … -- Nadav In addition to the requirements that are listed near the top of the ReadMe, I also had to install openjdk-6-jdk. I added -m64 to the CFLAGS as per the gcc docs.
For the kernel, we may accept adjustment of -0x10000000, since we know that it will just convert patchwork patch tracking system | about patchwork Search:ListSubjectsAuthorsBodies (mustpickalistfirst) Set Page Width: [ 80 fi __MY_MAKE_RUNNING__=1 export __MY_MAKE_RUNNING__ pwd=`pwd | sed -ne '/\/home\/rostedt\/work\/kernels\//p'` if [ -z $pwd ]; then m="intmake" else m="amdmake" fi # prove to me that I'm running the right one echo $m Under debian 32bits with 64bits kernel, I just add -m64 somewhere in the main Makefile to rebuild my modules. Also it would be useful to [email protected]:~/ssd log/code$ gcc -v Using built-in specs.
Already have an account? http://sourceware-org.1504.n7.nabble.com/Fwd-Error-cannot-represent-relocation-type-BFD-RELOC-64-td139365.html I am having another problem building, quite a bit farther along. For the testcase from PR, > expand generates SImode symbol that is later extended to DImode and handled > through movabs. On Wed, Jul 27, 2011 at 6:09 AM, Uros Bizjak
In > another word, if a memory operand is OK for ia32, it must be OK > for x32. this content Please fix the assembler to >> zero-extend this relocation. >> > > It is about address range. The offsetted memory references are for x32 > since they are OK for TARGET_32BIT. Or is the plan to run an osv machine inside a debian machine inside a Mac just too weird to deal with? No, since Pmode is still in > > > DImode and DImode addresses are *valid* addresses.
And how can I force the build process to use /usr/x86_64/bin/x86_64-linux-as rather than /usr/bin/as? On Wed, Jul 27, 2011 at 3:28 PM, Uros Bizjak
In > > another word, if a memory operand is OK for ia32, it must be OK > > for x32. > > Can you prevent x32 to generate DImode symbols? In addition they don't seem to be very fond of contributing changes back - normally one would expect the distribution maintainer to submit a patch like this if they set up Is so, could you, please, rewrite it in order to do the same thing on my 32 bit system (32 bit Intel Celeron M) ?
i got this error..... >> >> >> atomic_32.h:28: Error: cannot represent relocation type BFD_RELOC_64 >> atomic_32.h:34: Error: cannot represent relocation type BFD_RELOC_64 >> atomic_32.h:40: Error: cannot represent relocation type BFD_RELOC_64 >> Your patch just papers over this fact. Building binutils for target x86_64-pc-linux-gnu should help. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo [at] vger More majordomo info Signed-off-by: Pekka Enberg
X32 != LP64. > > I guess the code above speaks for itself. > > > Assembler is done on purpose to catch problems like this. > > This is artificial So, do you have some sort of religious objection to using CROSS_COMPILE= when building for a processor that doesn't match the userspace ? Take a look at the gas command line being issued by gcc when you are compiling application.c. check over here I disabled CONFIG_IA32_EMULATION and it works perfectly. > > So all that's needed to build an x86_64 kernel with the i386 Ubuntu 5.10 > toolchain: > > - edit Makefile: add
Same error. > > > > Ah.