[4.1] Problem building latest snapshot on OS X 10.3 target m68k.

[4.1] Problem building latest snapshot on OS X 10.3 target m68k.

[Mark Grosberg]

Hello all,

I just tried to build C targetting m68k-unknown-elf from the 
gcc-core-4.1-20050528 snapshot on OS X 10.3. It seems like the top-level 
configure script did not perform a configure in the intl/ subdirectory.

I invoked the top-level configure script as follows:

    ./configure --prefix=/path/to/install/dir
                --target=m68k-unknown-elf
                --enable-languages=c
                --with-headers=/path/to/newlib/hdrs
                --with-newlib

During compilation, building in intl/ failed because by default no 
config.h was generated and HAVE_TSEARCH was left defined for some reason. 
On my host machine (OS X 10.3) there is no <search.h> and compilation 
failed. Manually running configure within intl/ fixed the problem and 
allowed me to build.

Is this expected behavior or is there something awry with the top-level 
configure script?

N.B. After installing the 4.1 compiler it seemed to compile my source base 
without any ICEs so thats a good sign. :)

Thanks,
Mark G.

Re: [4.1] Problem building latest snapshot on OS X 10.3 target m68k.

[Eljay Love-Jensen]

Hi Mark,

The top level configure script cannot be invoked from within the source directory or any subdirectory thereof.

Make a peer directory (a build directory) to the source directory, and build from there specifying a relative path (or absolute path) to the configure script in the source directory.

HTH,
--Eljay

Re: [4.1] Problem building latest snapshot on OS X 10.3 target m68k.

[Mark Grosberg]

On Sun, 29 May 2005, Eljay Love-Jensen wrote:

> Hi Mark,
>
> The top level configure script cannot be invoked from within the source 
> directory or any subdirectory thereof.

Actually, sorry for my terse e-mail. I tried both an in-tree and 
out-of-tree build. I get the same behavior. I should mention that I 
consider my build environment somewhat same as I've built 2.95.3 and 3.4.3 
on this box frequently.

So I'm not 100% sure what the issue is. Here is the snapshot of the 
out-of-tree build failure:

--------------------------------------------------------------------------
metal:~/exp-toolchain-m68k/build/gcc-build myg$ make
make[2]: Nothing to be done for `all'.
make[1]: Nothing to be done for `all'.
rm -f stamp-h1
/bin/sh ./config.status config.h
config.status: creating config.h
config.status: config.h is unchanged
test -f config.h || (rm -f stamp-h1 && make stamp-h1)
gcc -no-cpp-precomp -c  -g -O2  -DHAVE_CONFIG_H 
-DLOCALEDIR="\"/Users/myg/exp-toolchain-m68k/run/share/locale\"" -I. 
-I../../gcc-4.1-20050528/intl ../../gcc-4.1-20050528/intl/dcigettext.c
../../gcc-4.1-20050528/intl/dcigettext.c:242:21: search.h: No such file or 
directory
../../gcc-4.1-20050528/intl/dcigettext.c: In function 
`libintl_dcigettext':
../../gcc-4.1-20050528/intl/dcigettext.c:575: warning: passing arg 1 of 
`mempcpy' makes pointer from integer without a cast
make[1]: *** [dcigettext.o] Error 1
make: *** [all-intl] Error 2
--------------------------------------------------------------------------

With an out-of-tree build I can't easily fix it (autoconf & automake 
aren't my specialties). If necessary I can put a configure log and my 
build scripts on a webserver somewhere.

But the relevant portion of building GCC is:

-----------------------------------------------------------------------
   tar xzvf ../tarballs/gcc-core-${VER_GNUCC}.tar.gz
   mkdir gcc-build
   cd gcc-build
   ../gcc-${VER_GNUCC}/configure                        \
               --prefix=/install/dir                    \
               --target=m68k-unknown-elf                \
               --enable-languages=c                     \
               --with-headers=/path/to/newlib/incl      \
               --with-newlib
   gnumake
   gnumake install
-----------------------------------------------------------------------

I should also note that I am using the -no-cpp-precomp option with my 
native CC as I've had the precompiled headers on OS X cause problems 
building GCC.

Thanks,
Mark G.
  - Man does my PowerBook heat up when compiling GCC.