Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
21 years ago

STL compilation error

Anyone ever seen this one?

`__static_initialization_and_destruction_0(int, int)':

locale-inst.o(.text+0xa0): global pointer relative address out of range

Adding an std::string causes this error, it doesn't occur in smaller projects.

7 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hello morten_tor,

    Yep, I tried this and got the exact same error (I don't normally use libstdc++ due to the amount of "baggage" it links in!). It looks like a problem in the libstdc++ port - I think something in locale-inst is trying to access its .text section using global pointer relative addressing; but as the linker scripts usually group all of the .text sections in low memory and all of the gp relative sections (sdata and sbss) higher up, the .text sections are too far away to be accessed by the (signed 16-bit) gp. Sounds like one for the Altera compiler people (I have an idea for a workaround, but it's ugly)...

    Steve.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    I know that some of the Altera guys are monitoring this forum, so hopefully something will be done to fix this error. I guess there's a workaround where I juggle the segments myself, but I'd rather that they fixed the issue.

    The coders in here that use uLinux - are they using the same compiler as we are? If they are, then they should have the same problem (I guess)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    This is fixed in the Nios II 1.01 release. You can get it from you FAE (now), or through the web (soon). Sorry for the late reply.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hmmm ... this is a recurring theme ... on several threads. So, I'll

    ask here too: does the -G0 compiler option resolve the problem?

    The option does indeed work as advertised (no small data) ... but

    I'm not currently using STL ... if it resolves your problem it would be a

    simple work around ... at least temporarily.

    Regards,

    --Scott