[GRASS-dev] build problems on Mac OS X 10.5.2.

GRASS GRASS developer
1

Hello,

I am trying to build Grass from source on Leopard(Mac OS X 10.5.2 with gcc 4.0.1).

While PROJ.4 built and installed without problem, configure failed for GRASS proper. The resulting error is ...
"checking External PROJ.4 version... configure: error: *** Could not determine External PROJ.4 version."

Consider this line from the trace output of the configure script.

+ eval echo configure:6910: '"${CC-cc}' -o conftest '$CFLAGS' '$CPPFLAGS' '$LDFLAGS' 'conftest.$ac_ext' '$LIBS' '1>&5"'
++ echo configure:6910: 'gcc -o conftest.dSYM -g -O2 conftest.c 1>&5'

The dSYM file extension on the output file is the critical bit. If the output file ends with a dSYM file extension, only supporting data is generated. No executable. (see example below). I worked around the problem by deleting references to ${ac_exeext}. What's the right fix for the configure script? Apparently there is a supporting script to autoconf which needs to be updated, right?

Sincerely,

-John

%%% with file extension - no executable

[Macintosh:grass/grass63_release/try] jkern% gcc -o try.dSYM -g -O2 try.c
[Macintosh:grass/grass63_release/try] jkern% ls -l
total 8
-rw-r--r-- 1 jkern staff 171 May 2 16:04 try.c
drwxr-xr-x 3 jkern staff 102 May 8 18:02 try.dSYM
[Macintosh:grass/grass63_release/try] jkern% ls -R
try.c try.dSYM

./try.dSYM:
Contents

./try.dSYM/Contents:
Info.plist Resources

./try.dSYM/Contents/Resources:
DWARF

./try.dSYM/Contents/Resources/DWARF:
try.dSYM
[Macintosh:grass/grass63_release/try] jkern%

%%%% without the extension - all is well.

[Macintosh:grass/grass63_release/try] jkern% gcc -o try -g -02 try.c
[Macintosh:grass/grass63_release/try] jkern% ls -l
total 40
-rwxr-xr-x 1 jkern staff 12832 May 8 19:24 try
-rw-r--r-- 1 jkern staff 171 May 2 16:04 try.c
drwxr-xr-x 3 jkern staff 102 May 8 19:24 try.dSYM

2

Hello,

I just realized I forgot to mention I am working off the Grass 6.3 branch.

-John

On May 8, 2008, at 7:26 PM, John Kern wrote:

Hello,

I am trying to build Grass from source on Leopard(Mac OS X 10.5.2 with gcc 4.0.1).

While PROJ.4 built and installed without problem, configure failed for GRASS proper. The resulting error is ...
"checking External PROJ.4 version... configure: error: *** Could not determine External PROJ.4 version."

Consider this line from the trace output of the configure script.

+ eval echo configure:6910: '"${CC-cc}' -o conftest '$CFLAGS' '$CPPFLAGS' '$LDFLAGS' 'conftest.$ac_ext' '$LIBS' '1>&5"'
++ echo configure:6910: 'gcc -o conftest.dSYM -g -O2 conftest.c 1>&5'

The dSYM file extension on the output file is the critical bit. If the output file ends with a dSYM file extension, only supporting data is generated. No executable. (see example below). I worked around the problem by deleting references to ${ac_exeext}. What's the right fix for the configure script? Apparently there is a supporting script to autoconf which needs to be updated, right?

Sincerely,

-John

%%% with file extension - no executable

[Macintosh:grass/grass63_release/try] jkern% gcc -o try.dSYM -g -O2 try.c
[Macintosh:grass/grass63_release/try] jkern% ls -l
total 8
-rw-r--r-- 1 jkern staff 171 May 2 16:04 try.c
drwxr-xr-x 3 jkern staff 102 May 8 18:02 try.dSYM
[Macintosh:grass/grass63_release/try] jkern% ls -R
try.c try.dSYM

./try.dSYM:
Contents

./try.dSYM/Contents:
Info.plist Resources

./try.dSYM/Contents/Resources:
DWARF

./try.dSYM/Contents/Resources/DWARF:
try.dSYM
[Macintosh:grass/grass63_release/try] jkern%

%%%% without the extension - all is well.

[Macintosh:grass/grass63_release/try] jkern% gcc -o try -g -02 try.c
[Macintosh:grass/grass63_release/try] jkern% ls -l
total 40
-rwxr-xr-x 1 jkern staff 12832 May 8 19:24 try
-rw-r--r-- 1 jkern staff 171 May 2 16:04 try.c
drwxr-xr-x 3 jkern staff 102 May 8 19:24 try.dSYM

3

On May 8, 2008, at 9:26 PM, John Kern wrote:

Hello,

I am trying to build Grass from source on Leopard(Mac OS X 10.5.2 with gcc 4.0.1).

While PROJ.4 built and installed without problem, configure failed for GRASS proper. The resulting error is ...
"checking External PROJ.4 version... configure: error: *** Could not determine External PROJ.4 version."

Consider this line from the trace output of the configure script.

+ eval echo configure:6910: '"${CC-cc}' -o conftest '$CFLAGS' '$CPPFLAGS' '$LDFLAGS' 'conftest.$ac_ext' '$LIBS' '1>&5"'
++ echo configure:6910: 'gcc -o conftest.dSYM -g -O2 conftest.c 1>&5'

The dSYM file extension on the output file is the critical bit. If the output file ends with a dSYM file extension, only supporting data is generated. No executable. (see example below). I worked around the problem by deleting references to ${ac_exeext}. What's the right fix for the configure script? Apparently there is a supporting script to autoconf which needs to be updated, right?

These dSYM errors don't necessarily mean there is something wrong with configure. When configure is testing for things and they fail, a dSYM error is more likely a symptom of that failure, not a bug in configure.

I have seen some problems when compiling with debug symbols (-g) on Leopard. I usually force my own CFLAGS so rarely run into this. Try setting CFLAGS and CXXFLAGS to "-Os" before running configure.

Another note: you will probably run into a libGL linking problem if you are using Xcode 3.0. This has been fixed in the Xcode 3.1 beta, so I recommend installing that - it's included for now in the iPhone SDK beta. The -g issue may also be fixed in Xcode 3.1, I haven't tried that yet.

See the macosx/ReadMe.rtf for all my current OSX notes (hmm, I don't have the -g issue in there).

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

Earth: "Mostly harmless"

- revised entry in the HitchHiker's Guide to the Galaxy

4

Hello William,

Thanks for the prompt reply. I missed the macosx subdirectory. I will read it. Also, your wiki entry (http://www.kyngchaos.com/wiki/software:grass) is informative. I have installed the iPhone SDK.

You're response doesn't acknowledge a key point. The error results in the configure script failing. This check breaks down to a trivial c program. When I extracted it from the configure script(see try.c) and compile it as we see in the trace output, it fails. Consider the try.c testcase.

%%% with file extension - no executable

[Macintosh:grass/grass63_release/try] jkern% gcc -o try.dSYM -g -O2 try.c
[Macintosh:grass/grass63_release/try] jkern% ls -l
total 8
-rw-r--r-- 1 jkern staff 171 May 2 16:04 try.c
drwxr-xr-x 3 jkern staff 102 May 8 18:02 try.dSYM
[Macintosh:grass/grass63_release/try] jkern% ls -R
try.c try.dSYM

./try.dSYM:
Contents

./try.dSYM/Contents:
Info.plist Resources

./try.dSYM/Contents/Resources:
DWARF

./try.dSYM/Contents/Resources/DWARF:
try.dSYM
[Macintosh:grass/grass63_release/try] jkern%

%%%% without the extension - all is well.

[Macintosh:grass/grass63_release/try] jkern% gcc -o try -g -02 try.c
[Macintosh:grass/grass63_release/try] jkern% ls -l
total 40
-rwxr-xr-x 1 jkern staff 12832 May 8 19:24 try
-rw-r--r-- 1 jkern staff 171 May 2 16:04 try.c
drwxr-xr-x 3 jkern staff 102 May 8 19:24 try.dSYM

It fails. no executable is generated. The check fails too. So, I don't think the output file should end with a .dSYM extension. I wasn't able to file a document on apple's site detailing the generation of the <file>.dSYM directory. Do you know of one?

Sincerely,

John

(attachments)

try.c (171 Bytes)

5

I don't claim to understand the inner workings of gcc, particularly on the
mac but I ran into the exact same issue you're having a week or so back. As
William pointed out the issue is with the -g flag being passed which for
some unknown reason seems to result in the test programs compiling as OSX
applications, hence that directory organization you were seeing, and then
failng to run as the configure script cannot locate the executable. If you
just run the configure script with out any CFLAGS you should be able to get
things at least compiling, 'env CFLAGS="" ./configure' is what worked for
me.
--
View this message in context: http://www.nabble.com/build-problems-on-Mac-OS-X-10.5.2.-tp17140529p17143187.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

6

On May 8, 2008, at 11:27 PM, John Kern wrote:

Thanks for the prompt reply. I missed the macosx subdirectory. I will read it. Also, your wiki entry (http://www.kyngchaos.com/wiki/software:grass) is informative. I have installed the iPhone SDK.

Those build instructions are a bit old, though mostly still valid. The readme in the source is basically an updated version of that.

You're response doesn't acknowledge a key point. The error results in the configure script failing. This check breaks down to a trivial c program. When I extracted it from the configure script(see try.c) and compile it as we see in the trace output, it fails. Consider the try.c testcase.

That was my suggestion - to try configuring by setting CFLAGS to -Os only, so the -g flag (default) is not used. If you want debug symbols, the workaround is to configure without, then add -g to platform.make after configuring.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

All generalizations are dangerous, even this one.

7

On May 9, 2008, at 3:02 AM, crundel wrote:

William pointed out the issue is with the -g flag being passed which for
some unknown reason seems to result in the test programs compiling as OSX
applications, hence that directory organization you were seeing, and then

I never really thought about it. It may be because of the way GCC handles compilation vs linking. In configure, for a run test, it compiles *and* links the test program in one step ($ac_link). When the debug flag is used, GCC may be assuming that we want an OSX application and quietly packages one up for us.

-g works in GRASS compilation later because all programs are compiled to object files first (even if there is only one), then linked into the program binary.

So, maybe it is kindof a broken configure - this app packaging problem started in Xcode 3.0 on Leopard, and GRASS' configure doesn't know about it yet.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty."

"Don't you even hate 'em?"

"What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the ____ it wouldn't kill one ___ nor shorten the war one day."

<Ha, ha> "And it might give 'em all stomach ulcers."

- Tarzan, on war

8

Hello,

Thanks for the help.

Just wanted to share in interesting nit. If you ditch the -g, ....

[Macintosh:grass/grass63_release/try] jkern% gcc -o try.dSYM -02 try.c
[Macintosh:grass/grass63_release/try] jkern% ls -l
total 40
-rw-r--r-- 1 jkern staff 171 May 2 16:04 try.c
-rwxr-xr-x 1 jkern staff 12612 May 9 06:59 try.dSYM
[Macintosh:grass/grass63_release/try] jkern% ./try.dSYM

the try.dSYM becomes the name of the executable which allows the configure check to work.

-John

On May 9, 2008, at 1:02 AM, crundel wrote:

I don't claim to understand the inner workings of gcc, particularly on the
mac but I ran into the exact same issue you're having a week or so back. As
William pointed out the issue is with the -g flag being passed which for
some unknown reason seems to result in the test programs compiling as OSX
applications, hence that directory organization you were seeing, and then
failng to run as the configure script cannot locate the executable. If you
just run the configure script with out any CFLAGS you should be able to get
things at least compiling, 'env CFLAGS="" ./configure' is what worked for
me.
--
View this message in context: http://www.nabble.com/build-problems-on-Mac-OS-X-10.5.2.-tp17140529p17143187.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

9

John Kern wrote:

I am trying to build Grass from source on Leopard(Mac OS X 10.5.2 with
gcc 4.0.1).

While PROJ.4 built and installed without problem, configure failed
for GRASS proper. The resulting error is ...
"checking External PROJ.4 version... configure: error: *** Could not
determine External PROJ.4 version."

Consider this line from the trace output of the configure script.

+ eval echo configure:6910: '"${CC-cc}' -o conftest '$CFLAGS'
'$CPPFLAGS' '$LDFLAGS' 'conftest.$ac_ext' '$LIBS' '1>&5"'
++ echo configure:6910: 'gcc -o conftest.dSYM -g -O2 conftest.c
1>&5'

The dSYM file extension on the output file is the critical bit. If the
output file ends with a dSYM file extension, only supporting data is
generated. No executable. (see example below). I worked around the
problem by deleting references to ${ac_exeext}. What's the right fix
for the configure script? Apparently there is a supporting script to
autoconf which needs to be updated, right?

It's autoconf's AC_EXEEXT macro which is the problem. It attempts to
determine the executable suffix automatically, with the following
code:

: echo $ac_n "checking for executable suffix""... $ac_c" 1>&6
: echo "configure:1009: checking for executable suffix" >&5
:
: if test "$CYGWIN" = yes || test "$MINGW32" = yes; then
: ac_cv_exeext=.exe
: else
: rm -f conftest*
: echo 'int main () { return 0; }' > conftest.$ac_ext
: ac_cv_exeext=
: if { (eval echo configure:1017: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
: for file in conftest.*; do
: case $file in
: *.$ac_ext | *.c | *.o | *.obj) ;;
: *) ac_cv_exeext=`echo $file | sed -e s/conftest//` ;;
: esac
: done
: else
: { echo "configure: error: installation or configuration problem: compiler cannot create executables." 1>&2; exit 1; }
: fi
: rm -f conftest*
: test x"${ac_cv_exeext}" = x && ac_cv_exeext=no
: fi
:
: EXEEXT=""
: test x"${ac_cv_exeext}" != xno && EXEEXT=${ac_cv_exeext}
: echo "$ac_t""${ac_cv_exeext}" 1>&6
: ac_exeext=$EXEEXT

Essentially, it deletes conftest.*, compiles and links a test program
named "conftest", then searches for any files matching conftest.*
whose extension isn't recognised as an intermediate file. If any such
file exists, it is assumed to be the executable, and its suffix is
treated as the executable suffix.

Clearly this fails if linking produces any unexpected files, such as
conftest.dSYM (which presumably contains debug symbols).

We should probably eliminate the use of that macro in favour of a
simple "if cygwin or mingw then .exe else nothing" test. I don't know
of any other supported platform where executables have a suffix.

--
Glynn Clements <glynn@gclements.plus.com>

10

On May 10, 2008, at 11:57 PM, Glynn Clements wrote:

The dSYM file extension on the output file is the critical bit. If the
output file ends with a dSYM file extension, only supporting data is
generated. No executable. (see example below). I worked around the
problem by deleting references to ${ac_exeext}. What's the right fix
for the configure script? Apparently there is a supporting script to
autoconf which needs to be updated, right?

It's autoconf's AC_EXEEXT macro which is the problem. It attempts to
determine the executable suffix automatically, with the following
code:

Essentially, it deletes conftest.*, compiles and links a test program
named "conftest", then searches for any files matching conftest.*
whose extension isn't recognised as an intermediate file. If any such
file exists, it is assumed to be the executable, and its suffix is
treated as the executable suffix.

Clearly this fails if linking produces any unexpected files, such as
conftest.dSYM (which presumably contains debug symbols).

We should probably eliminate the use of that macro in favour of a
simple "if cygwin or mingw then .exe else nothing" test. I don't know
of any other supported platform where executables have a suffix.

Ah, yes, I see. Even though the .dSYM bundle is created when debug sysmbols are ON, there is also a normal executable without an extension. But AC_EXEEXT sees the bundle first (and ignores that it is a directory) and assumes that's the executable.

Note that with the correct extention (ie none), run tests will still produce that .dSYM bundle. It seems to only happen when the compile and link steps are one, and not when object files are compiled, then linked in a separate step (so GRASS compilation won't be so messy). It's also only for the default OSX debug format, DWARF.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence....

- the wisdom of Tarzan

11

Glynn Clements wrote:

It's autoconf's AC_EXEEXT macro which is the problem. It attempts to
determine the executable suffix automatically, with the following
code:

We should probably eliminate the use of that macro in favour of a
simple "if cygwin or mingw then .exe else nothing" test. I don't know
of any other supported platform where executables have a suffix.

I've committed this change to SVN.

--
Glynn Clements <glynn@gclements.plus.com>