[64 bit] relocation truncated to fit: R_X86_64_PC32

[64 bit] relocation truncated to fit: R_X86_64_PC32

[marco atzeri]

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'


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' ?

Regards
Marco

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

[Corinna Vinschen]

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

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

[marco atzeri]

Il 5/27/2013 11:34 AM, Corinna Vinschen ha scritto:
> On May 26 08:40, marco atzeri wrote:
>> trying to build octave I hit:

>
> 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).

it crashed, but it could be another reason as also the second option
failed with 1.7.18-6
>
> - 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.

this worked. (-Wl,--image-base -Wl,0x10000000")
with latest 1.7.18-8 not with 1.7.18-6

> Corinna
Marco

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

[Corinna Vinschen]

Hi Marco,

On May 29 12:14, marco atzeri wrote:
> Il 5/27/2013 11:34 AM, Corinna Vinschen ha scritto:
> >On May 26 08:40, marco atzeri wrote:
> >>trying to build octave I hit:
> 
> >
> >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).
> 
> it crashed, but it could be another reason as also the second option
> failed with 1.7.18-6
> >
> >- 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.
> 
> this worked. (-Wl,--image-base -Wl,0x10000000")
> with latest 1.7.18-8 not with 1.7.18-6

Sorry to say that, but this is not overly helpful.  For one thing, you
mean 1.7.19, not 18, right?  How exactly did it work with 1.7.19-8?
Only after using --image-base 0x10000000 or also after the rebase?

What exactly did not work with 1.7.19-6?  Building or running?  Did you
only try with --image-base 0x10000000 or also with rebase?  To what
address did you rebase?  If building worked but running didn't, what has
gone wrong?  Was it a fork problem, perhaps?  Any hints from the
stackdump?  GDB?  Did you check for a collision with another DLL?

Also, what about 1.7.19-7?  The difference between -6, -7, and -8 is
exactly one patch per version.  It might be interesting to learn about
the patch which, apparently, fixed the problem.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

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

[marco atzeri]

Il 5/29/2013 12:28 PM, Corinna Vinschen ha scritto:
> Hi Marco,
>
> On May 29 12:14, marco atzeri wrote:
>> Il 5/27/2013 11:34 AM, Corinna Vinschen ha scritto:
>>> On May 26 08:40, marco atzeri wrote:
>>>> trying to build octave I hit:
>>
>>>
>>> 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).
>>
>> it crashed, but it could be another reason as also the second option
>> failed with 1.7.18-6
>>>
>>> - 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.
>>
>> this worked. (-Wl,--image-base -Wl,0x10000000")
>> with latest 1.7.18-8 not with 1.7.18-6
>
> Sorry to say that, but this is not overly helpful.  For one thing, you
> mean 1.7.19, not 18, right?  How exactly did it work with 1.7.19-8?
> Only after using --image-base 0x10000000 or also after the rebase?

1.7.19. no need to rebase for "make check"

> What exactly did not work with 1.7.19-6?  Building or running?

running. it was segfaulting almost on start.
Rebase made no difference; same for CFLAGS="-fwrapv"

  Did you
> only try with --image-base 0x10000000 or also with rebase?  To what
> address did you rebase?  If building worked but running didn't, what has
> gone wrong?  Was it a fork problem, perhaps?  Any hints from the
> stackdump?  GDB?  Did you check for a collision with another DLL?
>
> Also, what about 1.7.19-7?  The difference between -6, -7, and -8 is
> exactly one patch per version.  It might be interesting to learn about
> the patch which, apparently, fixed the problem.

I missed the 1.7.19-7 during my tests, do you need I test it ?

> Corinna

Marco

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

[Corinna Vinschen]

On May 29 12:48, marco atzeri wrote:
> Il 5/29/2013 12:28 PM, Corinna Vinschen ha scritto:
> >Hi Marco,
> >
> >On May 29 12:14, marco atzeri wrote:
> >>Il 5/27/2013 11:34 AM, Corinna Vinschen ha scritto:
> >>>On May 26 08:40, marco atzeri wrote:
> >>>>trying to build octave I hit:
> >>
> >>>
> >>>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).
> >>
> >>it crashed, but it could be another reason as also the second option
> >>failed with 1.7.18-6
> >>>
> >>>- 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.
> >>
> >>this worked. (-Wl,--image-base -Wl,0x10000000")
> >>with latest 1.7.18-8 not with 1.7.18-6
> >
> >Sorry to say that, but this is not overly helpful.  For one thing, you
> >mean 1.7.19, not 18, right?  How exactly did it work with 1.7.19-8?
> >Only after using --image-base 0x10000000 or also after the rebase?
> 
> 1.7.19. no need to rebase for "make check"

And does it still work after rebasing it to a high address?

> >What exactly did not work with 1.7.19-6?  Building or running?
> 
> running. it was segfaulting almost on start.
> Rebase made no difference; same for CFLAGS="-fwrapv"

Do you have a stackdump file?

>  Did you
> >only try with --image-base 0x10000000 or also with rebase?  To what
> >address did you rebase?  If building worked but running didn't, what has
> >gone wrong?  Was it a fork problem, perhaps?  Any hints from the
> >stackdump?  GDB?  Did you check for a collision with another DLL?
> >
> >Also, what about 1.7.19-7?  The difference between -6, -7, and -8 is
> >exactly one patch per version.  It might be interesting to learn about
> >the patch which, apparently, fixed the problem.
> 
> I missed the 1.7.19-7 during my tests, do you need I test it ?

It would be nice.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

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

[marco atzeri]

[-- Attachment #1: Type: text/plain, Size: 521 bytes --]

Il 5/29/2013 2:33 PM, Corinna Vinschen ha scritto:
> On May 29 12:48, marco atzeri wrote:
>> Il 5/29/2013 12:28 PM, Corinna Vinschen ha scritto:

>>> Also, what about 1.7.19-7?  The difference between -6, -7, and -8 is
>>> exactly one patch per version.  It might be interesting to learn about
>>> the patch which, apparently, fixed the problem.
>>
>> I missed the 1.7.19-7 during my tests, do you need I test it ?
>
> It would be nice.
>
>
> Thanks,
> Corinna
>

1.7.19-7 is fine.
1.7.19-6 segfaults. Attached stackdump

[-- Attachment #2: octave.exe.stackdump --]
[-- Type: text/plain, Size: 1363 bytes --]

Stack trace:
Frame        Function    Args
00000000006  0018006F9BB (00000000010, 00000229430, 003D8E10BA0, 00000000007)
00000000006  00180070E6A (000003F8550, 00600000000, 000000000E8, 00000000000)
00000229420  0018011A168 (00000000000, 000003F0230, 00180135D04, 000003F1320)
000000000C1  0018011723E (00000000000, 00600039530, 00000000000, 00000000000)
000011284C0  0018011770B (0000045CC70, 00600221010, 001800434ED, 00000000006)
000011284C0  001801178DC (00000000000, 00600221010, 000002297F8, 006002AA500)
000011284C0  00180117B9F (00000459850, 00000000000, 00600221D90, 00000000000)
000011284C0  00180146CA6 (00600000001, 00600221D90, 00000000041, 003D8E10BA0)
000011284C0  001800C0523 (006002AB770, 0000CE330C0, 006002AB770, 006002B1810)
000011284C0  00180113350 (0000CE330C0, 006002AB770, 006002B1810, 00000229B98)
000011284C0  00077492664 (006002118C8, 0000054DFBD, 006001D7A48, 0060024D050)
000011284C0  006002118C8 (0000054DFBD, 006001D7A48, 0060024D050, 006002118A8)
000011284C0  0060024D020 (006001D7A48, 0060024D050, 006002118A8, 006002118C8)
000011284C0  006002118C8 (0060024D050, 006002118A8, 006002118C8, 00600222310)
000011284C0  0000054DFBD (00010086CA1, 006002118C8, 006002399B0, 00001128460)
000011284C0  000100867AA (001800C0523, 006002AB3F0, 00000000001, 00000000001)
End of stack trace (more stack frames may be present)

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

[Corinna Vinschen]

On May 29 20:50, marco atzeri wrote:
> Il 5/29/2013 2:33 PM, Corinna Vinschen ha scritto:
> >On May 29 12:48, marco atzeri wrote:
> >>Il 5/29/2013 12:28 PM, Corinna Vinschen ha scritto:
> 
> >>>Also, what about 1.7.19-7?  The difference between -6, -7, and -8 is
> >>>exactly one patch per version.  It might be interesting to learn about
> >>>the patch which, apparently, fixed the problem.
> >>
> >>I missed the 1.7.19-7 during my tests, do you need I test it ?
> >
> >It would be nice.
> >
> >
> >Thanks,
> >Corinna
> >
> 
> 1.7.19-7 is fine.
> 1.7.19-6 segfaults. Attached stackdump

> Stack trace:
> Frame        Function    Args
> 00000000006  0018006F9BB (00000000010, 00000229430, 003D8E10BA0, 00000000007)
> 00000000006  00180070E6A (000003F8550, 00600000000, 000000000E8, 00000000000)
> 00000229420  0018011A168 (00000000000, 000003F0230, 00180135D04, 000003F1320)
> 000000000C1  0018011723E (00000000000, 00600039530, 00000000000, 00000000000)
> 000011284C0  0018011770B (0000045CC70, 00600221010, 001800434ED, 00000000006)
> 000011284C0  001801178DC (00000000000, 00600221010, 000002297F8, 006002AA500)
> 000011284C0  00180117B9F (00000459850, 00000000000, 00600221D90, 00000000000)
> 000011284C0  00180146CA6 (00600000001, 00600221D90, 00000000041, 003D8E10BA0)
> 000011284C0  001800C0523 (006002AB770, 0000CE330C0, 006002AB770, 006002B1810)
> 000011284C0  00180113350 (0000CE330C0, 006002AB770, 006002B1810, 00000229B98)
> 000011284C0  00077492664 (006002118C8, 0000054DFBD, 006001D7A48, 0060024D050)
> 000011284C0  006002118C8 (0000054DFBD, 006001D7A48, 0060024D050, 006002118A8)
> 000011284C0  0060024D020 (006001D7A48, 0060024D050, 006002118A8, 006002118C8)
> 000011284C0  006002118C8 (0060024D050, 006002118A8, 006002118C8, 00600222310)
> 000011284C0  0000054DFBD (00010086CA1, 006002118C8, 006002399B0, 00001128460)
> 000011284C0  000100867AA (001800C0523, 006002AB3F0, 00000000001, 00000000001)
> End of stack trace (more stack frames may be present)

Thanks.  Unfortunately I can't make hand nor foot of this stacktrace.
Oh well, maybe we should just skip the problem unless it reappears.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat