reduce-algebra upgrade renamed reduce-3.8.0-r1535 - installs both csl and psl versions

[mbrethen]

The upgrade to reduce-algebra 3.8.0-r1534 renames the port to reduce-3.8.0-r1535, following other distributions and installs both psl and csl versions. This gives the user the freedom of trying both and simplifies the installation.

[jjstickel@…]

Cc Me!

[nerdling (Jeremy Lavergne)]

The old port (reduce-algebra) will also be set to PortGroup obsolete.

[nerdling (Jeremy Lavergne)]

This port should be UsingTheRightCompiler. It also appears to be forcing a universal build (ppc i386).

[nerdling (Jeremy Lavergne)]

results of snow leopard run, enforcing UsingTheRightCompiler

[mbrethen]

I compared your log (building on SL) with mine (building on Lion):

Enabling thread-safe will cause FOX to use the thread-safe equivalent API's for some common C library functions like getpwuid(), readdir() and so on.

Apparently these aren't supported on OS X -- suggest removing.

WARNING: unrecognized options: --with-x, --with-opengl, --enable-threadsafe

Here's the first error:

Snow Leopard:

:info:configure checking build system type... i386-apple-darwin10.8.0
:info:configure checking host system type... i386-apple-darwin10.8.0

Lion:

:info:configure checking build system type... x86_64-apple-darwin11.2.0
:info:configure checking host system type... x86_64-apple-darwin11.2.0

Snow Leopard:

:info:configure configure: Building for Macintosh/Darwin with X11
:info:configure configure: error: No SDK found - I need at least the 10.6 version

Lion:

:info:configure configure: Building for Macintosh/Darwin with X11
:info:configure configure: x86_64 binary creation will probably be possible using 10.6

I don't know why the SDK isn't found on SL, nor why it tries to build universal. Need to investigate.

[nerdling (Jeremy Lavergne)]

Further info from my Snow Leopard install:

$ uname -a
Darwin lavergne.gotdns.org 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64

$ ls /Developer/SDKs/
MacOSX10.6.sdk

[mbrethen]

Replying to snc@…:

This port should be UsingTheRightCompiler. It also appears to be forcing a universal build (ppc i386).

What compiler did you set?

[nerdling (Jeremy Lavergne)]

The default for my setup is llvm-gcc-4.2, but gcc is being used in many of the Makefiles.

[mbrethen]

We could patch the makefiles or put a lib dependency on gcc. But part of the problem could be the universal build.

[mbrethen]

Replying to snc@…:

The default for my setup is llvm-gcc-4.2, but gcc is being used in many of the Makefiles.

Please post the config.log, which is found in /trunk.

[mbrethen]

I traced the SDK failure to the Fox config script in .../trunk/csl/fox/:

  *darwin*)
    echo "#include <stdio.h>" > conftest.c
    echo "int main() { printf(\"hello\"); return 0; }" >> conftest.c
# On the next line gcc will fail if the 10.6 SDK is not available, and in
# such cases it will moan about "no include path in which to search for
# stdio.h"  and then that the built-in function printf has been implicitly
# declared in a way that is messed up. The result would look ugly for something
# where the fail-safe response is just to avoid using it, and that is why
# I redirect stdout and stderr to /dev/null.
    if test "x$with_lionSDK" != "xno" &&
       gcc -isysroot /Developer/SDKs/MacOSX10.7.sdk -arch i386 -arch x86_64 conftest.c -o conftest 1> /dev/null 2> /dev/null
    then
      { $as_echo "$as_me:${as_lineno-$LINENO}: \"Macintosh x86_64 binaries via 10.7\"" >&5
$as_echo "$as_me: \"Macintosh x86_64 binaries via 10.7\"" >&6;}
#     enable_dependency_tracking="no"
      archflags="-arch x86_64 "
    else
      if gcc -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch x86_64 conftest.c -o conftest 1> /dev/null 2> /dev/null
      then
        { $as_echo "$as_me:${as_lineno-$LINENO}: \"Macintosh x86_64 binaries via 10.6\"" >&5
$as_echo "$as_me: \"Macintosh x86_64 binaries via 10.6\"" >&6;}
#       enable_dependency_tracking="no"
        archflags="-arch x86_64 "
      else
#--     if gcc -isysroot /Developer/SDKs/MacOSX10.5.sdk -arch ppc -arch i386 -arch x86_64conftest.c -o conftest 1> /dev/null 2> /dev/null
#--     then
#--       AC_MSG_NOTICE("Macintosh fat binaries via 10.5")
#--       enable_dependency_tracking="no"
#--       archflags="-arch ppc -arch i386 -arch x86_64"
#--     else
#--       if gcc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 conftest.c -o conftest 1> /dev/null 2> /dev/null
#--       then
#--         AC_MSG_NOTICE("Macintosh fat binaries via 10.4u")
#--         enable_dependency_tracking="no"
#--         archflags="-arch ppc -arch i386"
#--       else
#--         AC_MSG_NOTICE("Macintosh fat binary creation seems impossible")
#--       fi
#--     fi
        as_fn_error $? "SDK not found - need at least the 10.6 version" "$LINENO" 5
      fi
    fi
    ;;

Can someone explain to me why this works on lion but not on snow leopard?

[nerdling (Jeremy Lavergne)]

Since all the tests are based on using gcc it likely doesn't work properly on either version of the OS. The tests should run with whatever compiler MacPorts uses for the given system (gcc-4.2, llvm-gcc-4.2, clang, etc).

[mbrethen]

On the Lion build I only found warnings, but the build completed and the fox gui appears to work.

:info:configure configure: Building for Macintosh/Darwin with X
:info:configure llvm-gcc-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin11-llvm-gcc-4.2': execvp: No such file or directory
:info:configure lipo: can't figure out the architecture type of: /var/tmp//ccEvsPPv.out
:info:configure llvm-gcc-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin11-llvm-gcc-4.2': execvp: No such file or directory
:info:configure conftest.c:1:19: error: stdio.h: No such file or directory
:info:configure conftest.c: In function 'main':
:info:configure conftest.c:3: warning: incompatible implicit declaration of built-in function 'printf'
:info:configure lipo: can't figure out the architecture type of: /var/tmp//ccePR8EZ.out
:info:configure llvm-gcc-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin11-llvm-gcc-4.2': execvp: No such file or directory
:info:configure conftest.c:1:19: error: stdio.h: No such file or directory
:info:configure conftest.c: In function 'main':
:info:configure conftest.c:3: warning: incompatible implicit declaration of built-in function 'printf'
:info:configure lipo: can't figure out the architecture type of: /var/tmp//ccJriiCO.out
:info:configure configure: fat binary creation will probably NOT be possible

[nerdling (Jeremy Lavergne)]

Snow Leopard config.log

[nerdling (Jeremy Lavergne)]

Please post the config.log, which is found in /trunk.

It's attached​ now.

[mbrethen]

This is the code in configure that reports the build system type:

{ $as_echo "$as_me:${as_lineno-$LINENO}: checking build system type" >&5
$as_echo_n "checking build system type... " >&6; }
if ${ac_cv_build+:} false; then :
  $as_echo_n "(cached) " >&6
else
  ac_build_alias=$build_alias
test "x$ac_build_alias" = x &&
  ac_build_alias=`$SHELL "$ac_aux_dir/config.guess"`
test "x$ac_build_alias" = x &&
  as_fn_error $? "cannot guess build type; you must specify one" "$LINENO" 5
ac_cv_build=`$SHELL "$ac_aux_dir/config.sub" $ac_build_alias` ||
  as_fn_error $? "$SHELL $ac_aux_dir/config.sub $ac_build_alias failed" "$LINENO" 5

fi
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_build" >&5
$as_echo "$ac_cv_build" >&6; }

config.guess sets ac_cv_build. Have a look at it and see why it thinks you're an i386 machine (or, I'll look at it later).

It's ridiculous in that right above the core test (under platform) it shows:

hostname = lavergne.gotdns.org
uname -m = x86_64
uname -r = 10.8.0
uname -s = Darwin
uname -v = Darwin Kernel Version 10.8.0: Tue Jun  7 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64

/usr/bin/uname -p = i386
/bin/uname -X     = unknown

/bin/arch              = unknown
/usr/bin/arch -k       = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo      = Mach kernel version:
	 Darwin Kernel Version 10.8.0: Tue Jun  7 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64
Kernel configured for a single processor only.
1 processor is physically available.
1 processor is logically available.
Processor type: i486 (Intel 80486)
Processor active: 0
Primary memory available: 768.00 megabytes
Default processor set: 66 tasks, 201 threads, 1 processors
Load average: 1.47, Mach factor: 0.15
/bin/machine           = unknown
/usr/bin/oslevel       = unknown
/bin/universe          = unknown

With the exception of the rev. number, this is identical to my lion machine, which it correctly identifies:

configure:1814: Absolute path to source directory = /opt/local/var/macports/build/_Users_marbre_ports_math_reduce/reduce/work/trunk
configure:1850: checking build system type
configure:1864: result: x86_64-apple-darwin11.2.0
configure:1884: checking host system type
configure:1897: result: x86_64-apple-darwin11.2.0
configure:2498: host=x86_64-apple-darwin11.2.0 args= '--with-psl'
configure:2520: Will build in the x86_64-mac_10.7_lion-darwin11.2.0 subdirectory
configure:2568: +++ Will build in /opt/local/var/macports/build/_Users_marbre_ports_math_reduce/reduce/work/trunk/pslbuild/x86_64-mac_10.7_lion-darwin11.2.0

I'm glad I don't do this stuff for a living!

[mbrethen]

Replying to snc@…:

This port should be UsingTheRightCompiler. It also appears to be forcing a universal build (ppc i386).

I read the wiki you referenced and noticed this sentence:

"Now anytime a port tries to use one of these unversioned programs, the above script will be found instead of the actual program and the compile will stop with an error."

So, in effect, the script referenced interferes with the compile process?

[nerdling (Jeremy Lavergne)]

A raw reference to "gcc" will result in an error, since macports _never_ uses just "gcc".

It (paraphrasing—do research this) uses gcc-4.2 on 10.5, llvm-gcc-4.2 on 10.6 with xcode 4.1, clang on 10.7.

[mbrethen]

Replying to snc@…:

Please post the config.log, which is found in /trunk.

It's attached​ now.

Since uname -p returns i386 on 64 bit Darwin, it tries to determine whether the C preprocessor defines the symbol __LP64__. Is your UsingTheRightCompiler script interfering with that as well?

I can patch the makefiles and forward them to the developers of reduce, but not until we know it works on snow leopard (i can't see it being an issue on lion, since it builds already without hijacking the compiler).

What version of autoconf is macports using on snow leopard? It looks like, for lion, its using 2.68.

[ecronin (Eric Cronin)]

It would probably fail in the same way on Lion if you had the patch from UsingTheRightCompiler applied. That patch doesn't make bad ports use the right compiler; it makes using the wrong compiler become an explicit error. The configure script hunks you've pasted are clearly running "gcc" explicitly, which is not what macports wants, even in configure scripts, and on Lion that would fail as well. This may or may not compile on SL if the UsingTheRightCompiler patch isn't in play, but the portfile should still take care of replacing bare calls to cc or gcc with the right compiler even if it appears to succeed. That's the patch you should give upstream, removing all bare calls to gcc and replacing them with ${CC}, and setting ${CC} to gcc if the user (or macports on our case) hasn't provided a compiler to use (and the same for g++/ld/cpp/etc).

[mbrethen]

I'm now faced with a choice: either I patch the config/make scripts to make use of the environment variables (like $CC) that MacPorts passes (and I have no idea how much effort it would take), or abandon the work I started. I have forwarded this information to the reduce developers and await a response. In the emantime, if someone with more experience than myself would like to get involved, I would gladly welcome the help.

[mbrethen]

This ticket can be closed. It is replaced by Ticket #32973.