Leopard PPC: webkit-gtk: ld: scattered reloc r_address too large

[ryandesign (Ryan Carsten Schmidt)]

After patching it to remove the assertion that triggered #35989, webkit-gtk fails to build on PowerPC G4 on Leopard with this message:

ld: scattered reloc r_address too large

I see that GHCi had this problem, and fixed it by using the .a files: ​http://hackage.haskell.org/trac/ghc/ticket/3260

In case it matters, ld64 @97.17_2+llvm31 is installed and active.

It builds fine on Leopard i386.

[jeremyhu (Jeremy Huddleston Sequoia)]

Yeah, that's a valid error emitted because the codebase is just so large.

Essentially, it's complaining that some address it needs to relocate exceeds 24bits (ie it is larger than 16MiB) and thus cannot be placed in a 24bit scattered relocation entry.

Can you try using -Os instead of -O2? You may get lucky and squeeze it down just enough.

Short of that, maybe:

platform powerpc {
    configure.args-append --disable-shared
}

[ryandesign (Ryan Carsten Schmidt)]

Thanks, I'll give those two suggestions a try. It took over 7 hours of compilation to reach this error, so it'll take me awhile to report back.

It compiles on Intel... Do you think it's large because of the larger-than-expected struct on PowerPC (#35989) or some other difference between PowerPC and Intel code?

[jeremyhu (Jeremy Huddleston Sequoia)]

From the upstream bug report related to #35989, it sounds like that assertion is just "nice to have if you care about performance" ... and it shouldn't really be related. This is just because the individual dylibs likely contain >16M in a single segment.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jeremyhu@…:

Can you try using -Os instead of -O2? You may get lucky and squeeze it down just enough.

I used:

platform powerpc {
    # https://trac.macports.org/ticket/37839
    configure.optflags -Os
}

Unfortunately although -Os ended up on the compile lines, so did -O2 after it, rendering it useless. This appears to be because the configure.ac helpfully does:

# Add the appropriate 'O' level for optimized builds
if test "$enable_optimizations" = "yes"; then
   CXXFLAGS="$CXXFLAGS -O2"
   CFLAGS="$CFLAGS -O2"
else
   CXXFLAGS="$CXXFLAGS -O0"
   CFLAGS="$CFLAGS -O0"
fi

I'll try again after removing that.

[ryandesign (Ryan Carsten Schmidt)]

Successful build on Leopard ppc using the attached patch!

[jeremyhu (Jeremy Huddleston Sequoia)]

r102318, thanks.

[potmj (Michael Pot)]

Leopard i386 failure log

[potmj (Michael Pot)]

Replying to jeremyhu@…:

r102318, thanks.

I seem to still have this problem on Leopard i386 10.5.8 - perhaps I am missing something?

"Applying optflags.patch" looks like it works...
But is see " -O2 -arch ppc " in the log for the PPC bit of the universal build.

[ryandesign (Ryan Carsten Schmidt)]

optflags.patch just makes the build system respect the optimization flags MacPorts sets. MacPorts by default sets optimization flags to -O2, and in r102318 we changed them to -Os only for PowerPC build systems, since building for Intel didn't need it. But based on your report it seems it's needed even when building the ppc part on an Intel build system. Jeremy, should we just set optflags to -Os on all systems? We could also restrict it to when ppc is in universal_archs, but it might be simpler and reduce differences between platforms if we used -Os always.

[potmj (Michael Pot)]

I guess it doesn't matter what CPU you are compiling on, the target PPC code is always going to need -Os because it is a machine code relative jump distance causing the problem. But -O2 should be fine for the i386 part of the universal build. I just don't know how to tweek things so the PPC compile part alone gets -Os.

[ryandesign (Ryan Carsten Schmidt)]

Right, -O2 should cotinue to work for i386 and x86_64. But using -Os everywhere would be more consistent. And my question for Jeremy is whether such consistency is desirable.

Using -Os only on the PowerPC part of a universal build would mean enhancing the muniversal portgroup with a merger_configure_optflags option. Or going back to having the optflags hardcoded in the configure script but based on the arch somehow.

[jeremyhu (Jeremy Huddleston Sequoia)]

In general -Os is probably the desired optimization level because it usually results in better use of the instruction cache. We should probably make -Os the default in base at some point (perhaps 2.2 is a good time... ?).

[ryandesign (Ryan Carsten Schmidt)]

So no objection to changing optflags to -Os globally in webkit-gtk?

Let's have a separate ticket for changing base.

[potmj (Michael Pot)]

Replying to ryandesign@…:

So no objection to changing optflags to -Os globally in webkit-gtk?

Let's have a separate ticket for changing base.

This is good for me :-)

Is there an easy way for me to test this with the current port release, like tweek a .patch file or something, or do I wait for the port to be updated? I have had a look at configure, configure.ac, and optfiles.patch, but can't see an easy way yet to test it - like which one to change & where. Many thanks

[jeremyhu (Jeremy Huddleston Sequoia)]

Ticket for base: #38218

[cooljeanius (Eric Gallager)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Replying to fmw@…:

Is there an easy way for me to test this with the current port release

It should just be:

sudo port clean webkit-gtk
sudo port install webkit-gtk +universal configure.optflags=-Os

I'm not committing this change yet because I can get the current version of webkit-gtk to build on Leopard i386 (#38682) which is the only platform which this issue affects which I have access to at the moment.

[dershow]

Cc Me!

[jeremyhu (Jeremy Huddleston Sequoia)]

This should be fixed now that base is using -Os. Please reopen if you still have issues.

[ryandesign (Ryan Carsten Schmidt)]

It can't be tested. I haven't ever been able to build any version of webkit-gtk 2 on PowerPC because it depends on clang-3.3 which does not build on Tiger (#38857) or Leopard (I don't remember why; I'll check).