Building lame on Tiger fails as the SDK name is incorrect

[RealKGB (WhitetailAni)]

I am attempting to install ffmpeg on my iMac G5 running OS X 10.4.11. One of the required dependencies is lame, but when trying to build, it produces the log attached below. When looking in the log and looking up the errors, the reoccurring one is expected '=', ',', ';', 'asm' or '__attribute__' before 'size_t' - which means this is C++ code, that a C compiler is trying to compile. I've attached the log if that helps at all.

[RealKGB (WhitetailAni)]

Log that occurs when building lame

[kencu (Ken)]

the problem is this recent commit is wrong for Tiger:

[ad0b70302b368b8da1342fd586db04ffce1f6fe5/macports-ports]

In Tiger, the SDK name is different than all other systems…. there is a “u” in it.

The commit needs to be rejigged to account for this.

[kencu (Ken)]

also not all ppc systems support altivec, so that should be fixed too

[ryandesign (Ryan Carsten Schmidt)]

I wonder why that commit is setting the SDK path manually. Doesn't MacPorts already set it?

[kencu (Ken)]

Yes, I believe ${configure.sdkroot} would be set to the proper path by base.

[barracuda156]

Replying to kencu:

also not all ppc systems support altivec, so that should be fixed too

Should we disable optimizations for Tiger or how to handle it correctly?

[barracuda156]

Replying to kencu:

In Tiger, the SDK name is different than all other systems…. there is a “u” in it.

The commit needs to be rejigged to account for this.

I know that, but I thought macosx_sdk_version already picks the correct name.

[kencu (Ken)]

Replying to barracuda156:

Replying to kencu:

In Tiger, the SDK name is different than all other systems…. there is a “u” in it.

The commit needs to be rejigged to account for this.

I know that, but I thought macosx_sdk_version already picks the correct name.

see:

​https://github.com/search?q=repo%3Amacports%2Fmacports-base%20macosx_sdk_version&type=code

and

​https://github.com/search?q=repo%3Amacports%2Fmacports-base+configure_get_sdkroot&type=code

[kencu (Ken)]

Replying to barracuda156:

Replying to kencu:

also not all ppc systems support altivec, so that should be fixed too

Should we disable optimizations for Tiger or how to handle it correctly?

disabling altivec on Tiger is the easy way out, but then is not quite right for Tiger systems that do have altivec…

testing for altivec during the build and enabling it if present is kinda better, but then breaks the prebuilt binaries from the buildbots if the buildbot supports altivec but the user does not.

testing for altivec during the build and enabling it if present, and also disabling prebuilt binaries for the port, works, but people will complain about no prebuilt binaries someday perhaps. As we will probably never have a Tiger builbot anyway, this is what we usually do.

building it both with and without altivec and determining “on the fly” if the machine can use altivec is really the way to go, but almost nobody knows how to properly do that :)

[barracuda156]

Replying to kencu:

Replying to barracuda156:

Replying to kencu:

also not all ppc systems support altivec, so that should be fixed too

Should we disable optimizations for Tiger or how to handle it correctly?

disabling altivec on Tiger is the easy way out, but then is not quite right for Tiger systems that do have altivec…

testing for altivec during the build and enabling it if present is kinda better, but then breaks the prebuilt binaries from the buildbots if the buildbot supports altivec but the user does not.

testing for altivec during the build and enabling it if present, and also disabling prebuilt binaries for the port, works, but people will complain about no prebuilt binaries someday perhaps. As we will probably never have a Tiger builbot anyway, this is what we usually do.

building it both with and without altivec and determining “on the fly” if the machine can use altivec is really the way to go, but almost nobody knows how to properly do that :)

For 10.5, we can assume that no one gonna install it on a G3?

[RealKGB (WhitetailAni)]

Work began on running 10.5 on G3's but it was never completed. I think one partially functional build was able to run but I would not assume anyone doing that expects MacPorts support

[barracuda156]

Replying to kencu:

Yes, I believe ${configure.sdkroot} would be set to the proper path by base.

Apparently ${configure.sysroot} works fine.

[kencu (Ken)]

Yes, that is a newer thing Josh added to macports, that is set to ${configure.sdkroot} or to “/“ if $configure.sdkroot} is empty.

We had been asking for base to set $configure.sdkroot} to “/“ if it was empty, but he felt that was incorrect and so came up with a new replacement token everyone should use instead.

So probably most portfiles should be using that instead of ${configure.sdkroot} now, and removing the code that sets ${configure.sdkroot} to “/“ manually seen everywhere in the ports tree.

It just takes a long time (years) for that to filter down through the ports tree as nobody wants to break things that are already working.

[barracuda156]

Well, I can add a fix for this port, at least someone tried to install it on 10.4 :)