This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [64 bit] relocation truncated to fit: R_X86_64_PC32


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]