This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: [64 bit] relocation truncated to fit: R_X86_64_PC32
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-apps at cygwin dot com
- Date: Mon, 27 May 2013 11:34:51 +0200
- Subject: Re: [64 bit] relocation truncated to fit: R_X86_64_PC32
- References: <51A1AE43 dot 3070506 at gmail dot com>
- Reply-to: cygwin-apps at cygwin dot com
On May 26 08:40, marco atzeri wrote:
> trying to build octave I hit:
>
> libtool: link: g++ -shared -nostdlib
> /usr/lib/gcc/x86_64-pc-cygwin/4.8.0/crtbegin.o
> .libs/liboctinterp.la.lnkscript
> -L/pub/devel/octave/octave-3.6.4-1/build/libcruft/.libs
> -L/usr/local/lib ../liboctave/.libs/liboctave.dll.a
> /pub/devel/octave/octave-3.6.4-1/build/libcruft/.libs/libcruft.dll.a
> -lcholmod -lumfpack -lamd -lcamd -lcolamd -lccolamd -lcxsparse
> -larpack -lqrupdate -lfftw3 -lfftw3f -l readline
> -lncurses -lpcre ../libcruft/.libs/libcruft.dll.a -llapack -lblas
> -lgfortran -lquadmath -lhdf5 -lz -lX11
> -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.0
> -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../..
> /../x86_64-pc-cygwin/lib/../lib
> -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../lib -L/lib/../lib
> -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/lib
> -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../.. -lstdc++ -lgcc_s
> -lgcc -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32 -lgcc_s
> -lgcc /usr/lib/gcc/x86_64-pc-cygwin/4.8.0/crtend.o -O2 -O2 -O2
> -Wl,-no-undefined -o .libs/cygoctinterp-1.dll
> -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker
> .libs/liboctinterp.dll.a
> mv DLD-FUNCTIONS/PKG_ADD-t DLD-FUNCTIONS/PKG_ADD
>
> .libs/liboctinterp_la-ov-int16.o:ov-int16.cc:(.rdata+0x24):
> relocation truncated to fit: R_X86_64_PC32 against `.text$_ZNK19octave_int16_scalar3mapEN17octave_base_value14unary_mapper_tE'
This is the same problem as Yaakov reported in
http://cygwin.com/ml/cygwin-developers/2013-04/msg00055.html
> looking at gcc "3.17.16 Intel 386 and AMD x86-64 Options"
>
> ----------------------------------------------------------------
> `-mcmodel=small'
> Generate code for the small code model: the program and its
> symbols must be linked in the lower 2 GB of the address space.
> Pointers are 64 bits. Programs can be statically or dynamically
> linked. This is the default code model.
>
> `-mcmodel=kernel'
> Generate code for the kernel code model. The kernel runs in the
> negative 2 GB of the address space. This model has to be used for
> Linux kernel code.
>
> `-mcmodel=medium'
> Generate code for the medium model: the program is linked in the
> lower 2 GB of the address space. Small symbols are also placed
> there. Symbols with sizes larger than `-mlarge-data-threshold'
> are put into large data or BSS sections and can be located above
> 2GB. Programs can be statically or dynamically linked.
>
> `-mcmodel=large'
> Generate code for the large model. This model makes no assumptions
> about addresses and sizes of sections.
>
> ---------------------------------------------------------------------
> should I force the `-mcmodel=large' ?
You can try. The general idea was that this isn't necessary.
-mcmodel=medium is default and despite the text you're quoting, the idea
was that the base address of the result shouldn't matter on PE/COFF.
Unfortunately the linker is making a fuss about that yet and maybe
there's still another problem as well.
So you have two choices:
- Try -mcmodel=large, but there's a good chance it crashes (harfbuzz
apparently does).
- Link with -Wl,--image-base-address -Wl,0x10000000 and rebase the
DLLs afterwards to some arbitrary address between 0x4:00000000 and
0x6:00000000. This should work as expected.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat