Undefined symbols: "_main" on Leopard/ppc64

[mistydemeo]

Combining together various reports of the same base problem:

58

56

55

54

52

50

49

46

All of these share the same pattern: the build progresses creating 64-bit object files as requested, but ld rejects every object file as being "not of required architecture".

In #49, the zsh build, ld also rejects two dylibs which are 64-bit only. This makes it clear that the build itself is okay, and ld is wrongly determining that it's supposed to be building for a 32-bit architecture.

According to the ld manpage:

The architecture for the output file is specified using the -arch option. If this option is not used, ld attempts to determine the output architecture by examining the object files in command line order. The first "thin" architecture determines that of the output file. If no input object file is a "thin" file, the native 32-bit architecture for the host is used.

I think ld is determining this wrongly. Not only is -m64 not filtering down to ld, but every object file it's being fed should be 64-bit. There should not be any thin 32-bit objects.

For example, in the dialog build (#46), only three object files are present: dialog, libdialog.a, and libncurses. dialog and libdialog.a are both rejected as being of the wrong architecture, and ncurses is (according to the gist in #37) 4-way universal.

@breakeven If you come across further issues like this, can you post the build logs in this issue rather than filing new ones, so we can track them all in one place?

[mistydemeo]

Specifying -arch ppc64 in the CFLAGS may filter down to ld correctly.

Alternately, we may need to force a newer, less buggy ld by injecting tigerbrew's ld64.

[ghost]

Certainly will do.

[mistydemeo]

Can you post the output of ld -v?

[mistydemeo]

OK, pushed a commit which may help these. Can you please test and retry?

[mistydemeo]

Pick any one of them, preferably the quickest to build for your sake ;)

[ghost]

ld -v @(#)PROGRAM:ld PROJECT:ld64-85.2.1

[mistydemeo]

OK, tigerbrew's ld64 is newer than that.

[ghost]

I just tried rebuilding brew and pth. Same stuff. :(

[mistydemeo]

Can I see the updated build logs for pth?

[ghost]

https://gist.github.com/anonymous/5640375

by the way I just tried to build tigerbrew's ld64 and got the same error as the topic.

[ghost]

https://gist.github.com/anonymous/5640380

[mistydemeo]

Oh crap. ld64 itself won't build?

[mistydemeo]

That's... not good. ld64 may be the solution to the problem but it may also be necessary to build itself

[ghost]

A new challenger arrives. :)

[mistydemeo]

Tried to fix up the LDFLAGS in bfc775319f5c0ba0546ba3fd3c0d5ce5c8c2fa3b. Can you brew update and try pth again?

[ghost]

Still broken, but at least it's a different symbol now :)

https://gist.github.com/anonymous/5640458

I hope you're having fun, because I am. :)

[mistydemeo]

Argh, it's still mostly the same problem. :/

I do enjoy the detective work! But we're running out of options here, unfortunately.

Is the ld64 build still broken?

[mistydemeo]

OK, I added ENV.m32 if MacOS.version == :leopard to ld64. This will force it to build 32-bit, which Leopard's ld is capable of. If that builds okay for you, try this:

brew install https://gist.github.com/mistydemeo/56d990d32a9db55962c1/raw/0a635e4aea16c8bf31add02b8323e9eff75b99ed/pth.rb

[ghost]

Hey ld64 built after your changes in bfc7753! Let me try some other stuff...

[ghost]

By the way I tried to brew link --force ld64, and I still see the ld64 in /usr/bin

[mistydemeo]

Yeah, brew link --force links into Homebrew's prefix. It won't touch the system's version.

Linking ld64 won't make gcc use it. gcc is very particular about how it finds its tools. The ENV.ld64 method forces it in in two separate ways, and it's what is triggered by depends_on :ld64.

[ghost]

Right. Well anyway, it built. So that's a good first step :)

[ghost]

BTW I mean that it built in 64-bit mode -- not 32-bit.

[mistydemeo]

Oh! Before you pulled in the ENV.m32 change?

[ghost]

Correct!

[mistydemeo]

Nice! I'll undo that change, then.

Next step, does the version of pth with the :ld64 that I linked build?

[ghost]

brew install will automatically make use of it if it is installed? Because as I said, the one in /usr/bin is the one in my path.

[ghost]

ld64 build logs: https://gist.github.com/anonymous/5640574

pth (failed install) build logs: https://gist.github.com/anonymous/5640579

[mistydemeo]

brew will only make use of it when requested - both the dependency and the special environment variables are activated by depends_on :ld64. The brew command for pth I gave above will install a version of the formula with that in it.

[mistydemeo]

I wish I could confirm if that were using our ld64 or not... pth's ./libtool may have hardcoded the path, ignoring our requests.

[ghost]

Trying again with pth from your URL above...

[mistydemeo]

Ah yeah, thanks - ld64 won't be used otherwise.

[mistydemeo]

But if this turns out to be necessary, I may always enable ld64 on Leopard/64-bit when it's installed...

[ghost]

Alas: https://gist.github.com/anonymous/5640590

I wonder if your thought about libtool isn't right.

[mistydemeo]

Can you drop depends_on :ld64 into some of those other formulae that wouldn't build, and retry those?

[ghost]

What does depends_on do exactly?

bash failed: https://gist.github.com/anonymous/5640652

zsh: WORKED!

interesting!

[mistydemeo]

Nice, we're on to something :D

Can you keep trying others? It may be that bash is a one-off that needs special fixes, but ld64 will fix most.

What does depends_on do exactly?

Two things:

• If the argument is a string, specifies a dependency on a formula of that name. Errors out if no formula by that name exists.
• If the argument is a symbol, executes special logic that's written into Homebrew. This might introduce a formula dependency on some OSs and not others (for example, the :autoconf/:automake/:libtool dependencies that resolve to those formulae only on Xcode versions that don't come with them), modify the build environment, indicate a dependency on something that Homebrew doesn't provide (e.g. Xcode), etc.

The :ld64 special dependency does the following:

• Checks OS version. On Snow Leopard and newer, does nothing.
• Adds a dependency on the ld64 formula.
• Modifies the build environment to force gcc to use ld64 instead of its or the OS's linker.

[ghost]

dialog: works! x264: does not work pth: does not work e2fsprogs: works! antiword: does not work nasm: works!

[mistydemeo]

Nice! Can you post the build logs for the things that don't work?

x264 is... irksome. I bet it's still overriding our CFLAGS and insisting on building partly 32-bit. Wonder if that can be fixed.

[ghost]

x264: https://gist.github.com/anonymous/5641050 pth: https://gist.github.com/anonymous/5641052 antiword: https://gist.github.com/anonymous/5641053

[ghost]

backupninja: worked without any changes to the formula (didn't before) osxutils: worked without any changes to the formula (didn't before) lua: did not work even with depends_on -- https://gist.github.com/anonymous/5641147 mad: did not work even with depends_on -- https://gist.github.com/anonymous/5641153

[ghost]

protobuf: did not work even with depends_on -- https://gist.github.com/anonymous/5641172

[mistydemeo]

x264 has a new kind of problem we haven't seen before:

ld warning: codegen with reference kind 17 in _x264_mc_init prevents image from loading in dyld shared cache

Can you file a new issue for it with the logs?

[mistydemeo]

ld: warning: in ./.libs/libpth.dylib, file was built for ppc which is not the architecture being linked (ppc64)

Part of pth built 32-bit, part of pth build 64-bit. It's no longer a linking problem, but of convincing pth to build the whole thing 64-bit.

[mistydemeo]

./google/protobuf/stubs/platform_macros.h:61:2: error: #error Host architecture was not detected as supported by protobuf

protobuf no longer builds for powerpc, either 32-bit or 64-bit, but patches have been submitted upstream recently to fix this: https://code.google.com/p/protobuf/issues/detail?id=488

[mistydemeo]

lua:

ld: warning: in liblua.5.1.5.dylib, file was built for ppc which is not the architecture being linked (ppc64) ld: warning: in ./liblua.5.1.5.dylib, file was built for ppc which is not the architecture being linked (ppc64)

We requested a ppc64 build but part of lua built 32-bit.

[mistydemeo]

mad:

checking for architecture-specific fixed-point math routines... failed configure: error: bad --enable-fpm option

The mad formula passes a bad architecture on ppc64:

https://github.com/mistydemeo/tigerbrew/blob/master/Library/Formula/mad.rb#L34

Apparently we need to figure out what the correct --enable-fpm argument is.

[mistydemeo]

There is no specific ppc 64-bit --enable-fpm arch, but 64bit might work?

[mistydemeo]

Since this doesn't 100% work yet, I'm planning on disabling 64-bit support in tigerbrew by default. This 64-bit support will be turned on if the HOMEBREW_LEOPARD_64_BIT environment variable is set, e.g. export HOMEBREW_LEOPARD_64_BIT=1.

That won't be the case until later, sometime this weekend, but I'd suggest adding to your dotfiles in the meanwhile so you keep 64-bit support on!

I'll also enable ld64 on Leopard for every formula, as long as:

• The user is on Leopard (Tiger will still be 32-bit only, with ld64 by request);
• The user has HOMEBREW_LEOPARD_64_BIT set;
• The ld64 formula is installed.

[ghost]

Okay so the idea is that we can keep working on fixing it up, but it won't be default since there are still some problems?