Opened 7 years ago

Closed 6 years ago

#37839 closed defect (fixed)

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

Reported by: ryandesign (Ryan Schmidt) Owned by: jeremyhu (Jeremy Huddleston Sequoia)
Priority: Normal Milestone:
Component: ports Version: 2.1.2
Keywords: powerpc leopard haspatch Cc: dbevans (David B. Evans), potmj, cooljeanius (Eric Gallager), dershow
Port: webkit-gtk

Description

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.

Attachments (4)

main.log.bz2 (462.1 KB) - added by ryandesign (Ryan Schmidt) 7 years ago.
optflags.patch (523 bytes) - added by ryandesign (Ryan Schmidt) 7 years ago.
Portfile.diff (590 bytes) - added by ryandesign (Ryan Schmidt) 7 years ago.
main.log.zip (734.2 KB) - added by potmj 7 years ago.
Leopard i386 failure log

Download all attachments as: .zip

Change History (26)

Changed 7 years ago by ryandesign (Ryan Schmidt)

Attachment: main.log.bz2 added

comment:1 Changed 7 years ago by 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
}

comment:2 Changed 7 years ago by ryandesign (Ryan 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?

comment:3 Changed 7 years ago by 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.

comment:4 in reply to:  1 ; Changed 7 years ago by ryandesign (Ryan 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.

Changed 7 years ago by ryandesign (Ryan Schmidt)

Attachment: optflags.patch added

Changed 7 years ago by ryandesign (Ryan Schmidt)

Attachment: Portfile.diff added

comment:5 in reply to:  4 Changed 7 years ago by ryandesign (Ryan Schmidt)

Keywords: haspatch added

Successful build on Leopard ppc using the attached patch!

comment:6 Changed 7 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Resolution: fixed
Status: newclosed

r102318, thanks.

Changed 7 years ago by potmj

Attachment: main.log.zip added

Leopard i386 failure log

comment:7 in reply to:  6 Changed 7 years ago by potmj

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.

comment:8 Changed 7 years ago by ryandesign (Ryan Schmidt)

Cc: fmw@… added
Resolution: fixed
Status: closedreopened

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.

comment:9 Changed 7 years ago by potmj

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.

comment:10 Changed 7 years ago by ryandesign (Ryan Schmidt)

Right, -O2 should continue 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.

Last edited 7 years ago by ryandesign (Ryan Schmidt) (previous) (diff)

comment:11 Changed 7 years ago by 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... ?).

comment:12 Changed 7 years ago by ryandesign (Ryan Schmidt)

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

Let's have a separate ticket for changing base.

comment:13 in reply to:  12 ; Changed 7 years ago by potmj

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

comment:14 Changed 7 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Ticket for base: #38218

comment:15 Changed 7 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:16 in reply to:  13 Changed 7 years ago by ryandesign (Ryan 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.

comment:17 Changed 7 years ago by dershow

Cc: dersh@… added

Cc Me!

comment:18 Changed 6 years ago by jeremyhu (Jeremy Huddleston Sequoia)

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

comment:19 Changed 6 years ago by ryandesign (Ryan 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).

comment:20 Changed 6 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Summary: webkit-gtk: ld: scattered reloc r_address too largeLeopard PPC: webkit-gtk: ld: scattered reloc r_address too large

comment:21 Changed 6 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Keywords: leopard added

comment:22 Changed 6 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Resolution: fixed
Status: reopenedclosed
Note: See TracTickets for help on using tickets.