Shibboleth Developers

["Scott Cantor" <>]

> Or it is a MacPort issue. So far I haven't seen one MacPort 64bit
> binary, which confirms Alan Brenner's post that mentions MacPort being
> i386 and ppc oriented only (excluding ppc64 and x86_64 )

I don't think it's a MacPort issue at all. All they do is call configure and
run make. The issue is what the default toolchain does, and Apple's doesn't
build 64-bit code unless you tell it to.

The flags for bitness are very non-portable with gcc, so it's not trivial to
get this right, or to know when to use them, which is why you don't
generally see people making a special effort. They just rely on the
toolchain to do what's best for the platform.

On Solaris, this means 32-bit code even on a 64-bit OS, because using 64-bit
code is considered the exception case. Their Apache ships 32-bit so things
work properly.

There's no good reason for making Apache 64-bit in 99% of cases, so that's
really the root of the problem here. I don't disagree with Apple leaving the
build flags 32-bit, they just shouldn't have made Apache start up 64-bit by
default.

That said, if the right flags can be determined, the most likely solution is
going to be to create a port variant that forces a 64-bit build. Or possibly
figure out the right platform variant section to use for this case, and do a
64-bit build there. I'm not in a position to try either one.

But, I would say that if Apple includes 32-bit support in the server modules
they provide themselves, it probably is best for most deployers to run the
command to strip out the 64-bit code and run it 32-bit anyway. Shibboleth is
much more tested under those conditions, and wouldn't benefit from 64-bit
use anyway.

So for now I'll probably add that note to the Mac install page.

Of course, people using the port version of Apache or building their own
should be getting a 32-bit version themselves, so nothing should break
there.

-- Scott