reduce-csl: build failure under OS X 10.10.5 (Yosemite)

[zzanderr]

reduce-addons and reduce-common both built without any apparent problems. However, the build for reduce-csl fails after listing warnings such as:

:info:build ld: warning: object file (/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_reduce/reduce-csl/work/reduce-src-2014-11-30/cslbuild/x86_64-mac_unknown_version-darwin14.5.0/lib/libcrlibm.a(asincos.o)) was built for newer OSX version (10.10) than being linked (10.9)
:info:build ld: warning: object file (/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_reduce/reduce-csl/work/reduce-src-2014-11-30/cslbuild/x86_64-mac_unknown_version-darwin14.5.0/lib/libcrlibm.a(atan_fast.o)) was built for newer OSX version (10.10) than being linked (10.9)
.
.
.
:info:build ld: warning: object file (/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_reduce/reduce-csl/work/reduce-src-2014-11-30/cslbuild/x86_64-mac_unknown_version-darwin14.5.0/lib/libcrlibm.a(zero_scs.o)) was built for newer OSX version (10.10) than being linked (10.9)
:info:build Rez -t APPL -o bootstrapreduce /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_reduce/reduce-csl/work/reduce-src-2014-11-30/csl/cslbase/mac.r
:info:build Makefile:4895: TRACE: bootstrapreduce.img :: bootstrapreduce
:info:build rm -f bootstrapreduce.img
:info:build mkdir -p buildlogs
:info:build echo Building in `pwd`
:info:build Building in /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_reduce/reduce-csl/work/reduce-src-2014-11-30/cslbuild/x86_64-mac_unknown_version-darwin14.5.0/csl
:info:build chmod 664 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_reduce/reduce-csl/work/reduce-src-2014-11-30/csl/cslbase/../../cslbuild/generated-c/*
:info:build ./bootstrapreduce -w -z -Dno_init_file \
:info:build 		/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_reduce/reduce-csl/work/reduce-src-2014-11-30/csl/cslbase/buildreduce.lsp -D@srcdir=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_reduce/reduce-csl/work/reduce-src-2014-11-30/csl/cslbase -D@reduce=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_reduce/reduce-csl/work/reduce-src-2014-11-30/csl/cslbase/../.. \
:info:build 		-- buildlogs/bootstrapreduce.log \
:info:build 		-j bootstrapreduce.dep
:info:build Output redirected to "buildlogs/bootstrapreduce.log"
:info:build Info: basic CSL
:info:build Info: bootstrap RLISP
:info:build make[4]: *** [bootstrapreduce.img] Abort trap: 6
:info:build make[4]: *** Deleting file `bootstrapreduce.img'
:info:build make[3]: *** [/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_reduce/reduce-csl/work/reduce-src-2014-11-30/csl/cslbase/../../cslbuild/generated-c/make.stamp] Error 2
:info:build make[2]: *** [all] Error 2
:info:build make[1]: *** [all] Error 2
:info:build Building failed with return code 2 for version cslbuild/x86_64-mac_unknown_version-darwin14.5.0
:info:build make: *** [all] Error 2
:info:build make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_reduce/reduce-csl/work/reduce-src-2014-11-30'
:info:build Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_reduce/reduce-csl/work/reduce-src-2014-11-30" && /usr/bin/make -w all 
:info:build Exit code: 2

...etc.

reduce-psl built without a snag, and it is probably what I want anyway, so if there is no easy solution for this error, is there any way for me to install reduce without reduce-psl? Is reduce itself just a "wrapper" for the other sub-ports, or does it contain essential code for proper operation?

I am attaching the build log.

Thanks for your time.

[mbrethen]

It installs under Yosemite on my macbook pro. What version of XCODE do you have? I have read that using the Xcode 7 linker, one gets messages such as you describe when linking objects generated using llvm. I did not upgrade to 7.

You are correct, reduce is just a stub to install all the sub-ports. You can install the reduce-psl and reduce-common sub-ports and it should work fine.

[zzanderr]

Thanks for your quick response!

I have Xcode 7.1.1. So it has a bad linker? Any advice for future builds ? : )

[ryandesign (Ryan Carsten Schmidt)]

The log you attached is filled with examples of MACOSX_DEPLOYMENT_TARGET being set to 10.9 before some compile commands but not others, hence the error message you observed. There is no reason for the build system to set this variable. This should be removed from the build system. Let MacPorts dictate what deployment target to use and everything should be fine. Looks like there are 4 separate configure scripts from which this should be removed.

[mbrethen]

Replying to ryandesign@…:

The log you attached is filled with examples of MACOSX_DEPLOYMENT_TARGET being set to 10.9 before some compile commands but not others, hence the error message you observed. There is no reason for the build system to set this variable. This should be removed from the build system. Let MacPorts dictate what deployment target to use and everything should be fine. Looks like there are 4 separate configure scripts from which this should be removed.

The developer added LC_VERSION_MIN_MACOSX directives when Mavericks was released. I think it had something to do with a path change to the SDK, but I don't remember the specifics. The XCode 7 linker seems to expect that LC_VERSION_MIN_MACOSX contains the minimum version number of the MacOS X SDK (10.9, 10.11, ...), NOT the Darwin kernel version number! See LLVM bug 24927: ​https://llvm.org/bugs/show_bug.cgi?id=24927. The only new thing with the Xcode 7 linker is that it is now reporting a warning for the version mismatch.

A fix was suggested at the link above:

#if defined(OSX)
#if (LLVM_VERSION_MAJOR < 3) || ((LLVM_VERSION_MAJOR == 3) && (LLVM_VERSION_MINOR < 8))
        triple = Triple(triple.getArchName(),
                        triple.getVendorName(),
                        "darwin",
                        triple.getEnvironmentName());
#endif
#endif

This prevents the LC_VERSION_MIN_MACOSX directives from being emitted into the LLVM generated object files. I can pass this on to the developer. Which configure scripts did you notice the deployment target statement?

[zzanderr]

Mark, thanks for the link. For me, probably the best way to deal with the nuisance is to have more than a vague idea of what I should be alert for, at least until Apple has a fix. Although I might reluctantly squander another 10 GB of storage for Xcode 6, and use xcode-select when necessary, I don’t want to squander the time quite yet. So now, at least I know what to watch for.

For what it’s worth, I am posting the result of

grep -rn -H --binary-files=without-match -B 2 -A 2 "MACOSX_DEPLOYMENT_TARGET" ./reduce-src-2014-11-30/

Thanks again.

[zzanderr]

grep of work directory

[mbrethen]

Replying to zanderpower@…:

Mark, thanks for the link. For me, probably the best way to deal with the nuisance is to have more than a vague idea of what I should be alert for, at least until Apple has a fix. Although I might reluctantly squander another 10 GB of storage for Xcode 6, and use xcode-select when necessary, I don’t want to squander the time quite yet. So now, at least I know what to watch for.

For what it’s worth, I am posting the result of

grep -rn -H --binary-files=without-match -B 2 -A 2 "MACOSX_DEPLOYMENT_TARGET" ./reduce-src-2014-11-30/

Thanks again.

Could you post the result of

gcc --version

[zzanderr]

Yep, it's

gcc (MacPorts gcc5 5.2.0_0) 5.2.0

[mbrethen]

Replying to zanderpower@…:

Yep, it's

gcc (MacPorts gcc5 5.2.0_0) 5.2.0

Oh, that's very different. My setup is:

$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.5.0
Thread model: posix

How are setting the Macports gcc5 to be the default?

[mbrethen]

Okay, I tried

$ port select --list gcc
Available versions for gcc:
	mp-gcc5
	none (active)

So, I suppose you used

$ sudo port select --set gcc mp-gcc5

[mbrethen]

Zander,

I was not able to duplicate the build error with gcc5 and Xcode 6. Would you try building with apple's compiler?

[mbrethen]

In cslbase/print.c line 105 there is a constant VPRINTF_CHUNK. The current value is 256 and an effect is that when it tries to print a message longer than that you get a buffer overflow. The path that macports repository uses triggers that very overflow. Whereas I was building from my local repository. Need to patch it .

I posted a patch to csl/cslbase/print.c so that the constant there is (say) 2048 rather than 256; and one for the portfile as well.

[ryandesign (Ryan Carsten Schmidt)]

So with your patch, the same problem will occur when the path is great than 2048 characters, right? Can this not be fixed to accommodate any length?

You increased the revision of all subports. Doesn't this problem only affect the reduce-csl subport? If so, only the revision of the reduce-csl subport should be increased.

[mbrethen]

Replying to ryandesign@…:

So with your patch, the same problem will occur when the path is great than 2048 characters, right? Can this not be fixed to accommodate any length?

That's what the developer changed it to. I don't know if it can accommodate any length.

You increased the revision of all subports. Doesn't this problem only affect the reduce-csl subport? If so, only the revision of the reduce-csl subport should be increased.

What about the stub port?

[ryandesign (Ryan Carsten Schmidt)]

This patch changes nothing about how the stub port installs so there's no need to increase its revision.

When a port has subports, I find it helpful to put an explicit revision line in each subport, even if the revision is 0, to make it clear where revisions can be set.

[mbrethen]

Replying to ryandesign@…:

When a port has subports, I find it helpful to put an explicit revision line in each subport, even if the revision is 0, to make it clear where revisions can be set.

Done.

[ryandesign (Ryan Carsten Schmidt)]

r142768