source: rtems/aclocal.m4 @ 2617b345

4.104.114.84.95
Last change on this file since 2617b345 was e81ef51, checked in by Joel Sherrill <joel.sherrill@…>, on 02/17/98 at 14:12:01

Patch from Ralf Corsepius <corsepiu@…>:

Yep, I have a bunch of bug-fixes and additions pending (Yet another monster
patch, ... I can hear you scream :-).

1) configure.in : one AC_CONFIG_HEADER(...) line too much.

2) configure.in: gcc28 support is enabled by default, i.e. if no
--enable-gcc28 option is passed on the command line. I am not sure if this
is intentional.

IMO, AC_ARG_ENABLE for --enable-gcc28 should look like:

AC_ARG_ENABLE(gcc28, \
[ --enable-gcc28 enable use of gcc 2.8.x features], \
[case "${enableval}" in

yes) RTEMS_USE_GCC272=no ;;
no) RTEMS_USE_GCC272=yes ;;
*) AC_MSG_ERROR(bad value ${enableval} for gcc-28 option) ;;

esac],[RTEMS_USE_GCC272=yes])

3) At the end of c/src/exec/score/cpu/m68k/m68k.h

#ifdef cplusplus
}
#endif

#endif /* !ASM */

in my opinion these two statements should be swapped:

#endif /* !ASM */

#ifdef cplusplus
}
#endif

I didn't try to compile for m68k, but does't this give an error? Is it
compensated somewhere else - or didn't I look carefully enough?

5) configure.in: --enable-cpp should probably be renamed to --enable-cxx, as
gnu-programs use "cxx" to specify C++ specific configure options, while cpp
is used for the preprocessor (e.g egcs uses --with-cxx-includedir, autoconf
internally uses $CXX),

6) The macro files from aclocal/*.m4 contain the buggy sed-rules formerly
contained in aclocal..m4, i.e. the sed/sort-bug fix to aclocal.m4 didn't
make it to aclocal/*.m4. I think I should feel guilty for that - Obviously I
submitted the contents of an old aclocal-directory last time. - Sorry.

7) For sh-rtems, we currently need to add additional managers to
MANAGERS_REQUIRED (from inside of custom/*.cfg). Currently MANAGERS_REQUIRED
is defined in make/compilers/*.cfg. This seems to prevent overriding
MANAGERS_REQUIRED from custom/*.cfg files - Obviously the files are included
in such a way that the settings from compilers/*cfg always override settings
from custom/*.cfg files.

Furthermore, I think, defining MANAGERS_* inside gcc-<target>.cfg files is
not correct - MANAGERS are not gcc-variant-dependent, but depend
on targets/bsps and therefore should be defined in a bsp/target dependent
file, e.g. in custom/*.cfg or target.cfg.in.

I think defining default settings for MANAGERS* in custom/default.cfg could
be an appropriate location. But this requires all custom/*.cfg files to
include default.cfg, which *-posix.cfg files don't seem to do.

Therefore I would like propose to move MANAGERS* to target.cfg.in - they are
included by all custom/*.cfg files. Perhaps we/you should use this
opportunity to merge parts from custom/default.cfg into target.cfg.in. This
ensures to have the setting included once per target makefile and will open
the opportunity to have autoconf doing additional work on
bsp-configurations.

Peanuts sofar, ... but here it comes ... (:-)

8) I am preparing a major enhancement to autoconf support for
gnutools/compilers. It is not yet finished, but usable and I'll therefore
attach a preliminary version to this mail.

Motivation:

  • Fix problems with --enable-gcc28, if target-cc is not gcc28 compatible
  • Fix -pipe problems
  • Fix problems with hard-coded paths in configuration files (esp. posix)
  • Fix consistency problems with explictly given gnutools and gcc's gnutools

Currently included:

  • detection and checking of host and target compiler (gcc/g++)
  • checking if target gnutools are in path
  • checking if <target>-gcc -specs works (autodisabling gcc28 if not)
  • checking if <target>-gcc -pipe works

Todo :

  • *posix.cfg files are not yet adapted => The hard-coded paths for these systems are still in use.
  • Check if the host compiler $CC is properly propagated to the Makefiles (I doubt it, but this should not matter)
  • Check if rtems' generic tools still work properly (It looks like, but who knows)
  • Integrate CXX support into default.cfg or gcc-target-default.cfg (It looks like C++ support is only used by posix BSPs)
  • Automatically handle RANLIB/MKLIB for targets
  • Plenty ... (:-)

Open problems:

  • Untested for non-gcc compatible host and target compilers. This should be no problem if the tools are named follow gnutool's naming convention and are included in $PATH while running configure.
  • Intentionally using different tools than that gcc has been configured for, e.g. use a different assembler ? This should be still possible if XX_FOR_TARGET is hard-coded into custom/*.cfg. I don't see why anybody should want to do this, but who knows?

I have tested this version on linux and solaris hosts, with gcc's
directories mounted at weird non-standard mount points, using egcs
(linux/sh-rtemscoff), gcc-2.7.2.2 using native tools (solaris), gcc-2.7.2.3
w/ gnutools (solaris/linux). I don't expect it to break anything, but of
cause I can't promise it. It will break most/all *-posix.cfg configuration
almost for certain, but not more as rtems' current *posix.cfg configurations
already do (hard-coded configurations).

I am not sure if this is ready to be included into the next snapshot or not.
Perhaps you might try this on your systems and if it you don't notice
serious bugs you might put it into the snapshot for public testing (I don't
like this, but I don't see another possiblity to test generality).

I enclose a patch for configure.in and some configuration files which
comprizes fixes for all items mentioned except of #3 . Don't forget to run
"aclocal -I aclocal; autoconf;" after applying the patch (:-).

  • Property mode set to 100644
File size: 8.6 KB
Line 
1dnl aclocal.m4 generated automatically by aclocal 1.2
2
3dnl $Id$
4
5dnl macro to detect mkdir
6AC_DEFUN(RTEMS_PATH_MKDIR,
7[AC_PATH_PROG(MKDIR,mkdir)
8])
9
10dnl macro to check for mkdir -p
11AC_DEFUN(RTEMS_PROG_MKDIR_P,
12[
13AC_REQUIRE([RTEMS_PATH_MKDIR])
14AC_MSG_CHECKING([for working $MKDIR -p])
15AC_CACHE_VAL(rtems_cv_prog_mkdir_p,
16[rm -rf conftestdata
17if $MKDIR -p conftestdata 2>/dev/null ;then
18rtems_cv_prog_MKDIR_P="yes"
19else
20rtems_cv_prog_MKDIR_P="no"
21fi])dnl
22rm -rf conftestdata
23AC_MSG_RESULT($rtems_cv_prog_MKDIR_P)
24])
25
26dnl macro to check for mkdir -m 0755
27AC_DEFUN(RTEMS_PROG_MKDIR_M,
28[
29AC_REQUIRE([RTEMS_PATH_MKDIR])
30AC_MSG_CHECKING([for working $MKDIR -m 0755])
31AC_CACHE_VAL(rtems_cv_prog_MKDIR_P,
32[rm -rf conftestdata
33if $MKDIR -m 0775 conftestdata 2>/dev/null; then
34rtems_cv_prog_MKDIR_M="yes"
35else
36rtems_cv_prog_MKDIR_M="no"
37fi])dnl
38rm -rf conftestdata
39AC_MSG_RESULT($rtems_cv_prog_MKDIR_M)
40])
41
42
43dnl $Id$
44
45dnl canonicalize target name
46dnl NOTE: Most rtems targets do not fullfil autoconf's
47dnl target naming conventions "processor-vendor-os"
48dnl Therefore autoconf's AC_CANONICAL_TARGET will fail for them
49dnl and we have to fix it for rtems ourselves
50
51AC_DEFUN(RTEMS_CANONICAL_TARGET_CPU,
52[AC_MSG_CHECKING(rtems target cpu)
53changequote(<<, >>)dnl
54target_cpu=`echo $target | sed 's%^\([^-]*\)-\(.*\)$%\1%'`
55changequote([, ])dnl
56AC_MSG_RESULT($target_cpu)
57])
58
59dnl
60dnl $Id$
61dnl
62dnl Check for target gcc
63dnl
64dnl Adaptation of autoconf-2.12's AC_PROG_CC to rtems
65dnl
66dnl 98/02/10 Ralf Corsepius     (corsepiu@faw.uni-ulm.de)
67dnl
68
69AC_DEFUN(RTEMS_PROG_CC,
70[
71AC_BEFORE([$0], [AC_PROG_CPP])dnl
72AC_BEFORE([$0], [AC_PROG_CC])dnl
73AC_CHECK_PROG(CC, gcc, gcc)
74if test -z "$CC"; then
75  AC_CHECK_PROG(CC, cc, cc, , , /usr/ucb/cc)
76  test -z "$CC" && AC_MSG_ERROR([no acceptable cc found in \$PATH])
77fi
78
79RTEMS_PROG_CC_WORKS
80AC_PROG_CC_GNU
81
82if test $ac_cv_prog_gcc = yes; then
83  GCC=yes
84dnl Check whether -g works, even if CFLAGS is set, in case the package
85dnl plays around with CFLAGS (such as to build both debugging and
86dnl normal versions of a library), tasteless as that idea is.
87  ac_test_CFLAGS="${CFLAGS+set}"
88  ac_save_CFLAGS="$CFLAGS"
89  CFLAGS=
90  AC_PROG_CC_G
91  if test "$ac_test_CFLAGS" = set; then
92    CFLAGS="$ac_save_CFLAGS"
93  elif test $ac_cv_prog_cc_g = yes; then
94    CFLAGS="-g -O2"
95  else
96    CFLAGS="-O2"
97  fi
98else
99  GCC=
100  test "${CFLAGS+set}" = set || CFLAGS="-g"
101fi
102
103CC_FOR_TARGET=$CC
104rtems_cv_prog_gcc=$ac_cv_prog_gcc
105rtems_cv_prog_cc_g=$ac_cv_prog_cc_g
106
107dnl restore initial values
108unset CC
109unset ac_cv_prog_gcc
110unset ac_cv_prog_cc_g
111unset ac_cv_prog_CC
112])
113
114
115dnl Almost identical to AC_PROG_CC_WORKS
116dnl added malloc to program fragment, because rtems has its own malloc
117dnl which is not available while bootstrapping rtems
118
119AC_DEFUN(RTEMS_PROG_CC_WORKS,
120[AC_MSG_CHECKING([whether the target C compiler ($CC $CFLAGS $LDFLAGS) works])
121AC_LANG_SAVE
122AC_LANG_C
123AC_TRY_COMPILER(
124[void *malloc() { return 0; }
125 main(){return(0);}],
126rtems_cv_prog_cc_works, rtems_cv_prog_cc_cross)
127AC_LANG_RESTORE
128AC_MSG_RESULT($rtems_cv_prog_cc_works)
129if test $rtems_cv_prog_cc_works = no; then
130  AC_MSG_ERROR([installation or configuration problem: target C compiler cannot create executables.])
131fi
132AC_MSG_CHECKING([whether the target C compiler ($CC $CFLAGS $LDFLAGS) is a cross-compiler])
133AC_MSG_RESULT($rtems_cv_prog_cc_cross)
134])
135
136dnl
137dnl $Id$
138dnl
139dnl Check whether the target compiler accepts -specs
140dnl
141dnl 98/02/11 Ralf Corsepius     corsepiu@faw.uni-ulm.de
142dnl
143
144AC_DEFUN(RTEMS_GCC_SPECS,
145[AC_REQUIRE([RTEMS_PROG_CC])
146AC_CACHE_CHECK(whether $CC_FOR_TARGET accepts -specs,rtems_cv_gcc_specs,
147[touch confspec
148echo 'void f(){}' >conftest.c
149if test -z "`${CC_FOR_TARGET} -specs confspec -c conftest.c 2>&1`";then
150  rtems_cv_gcc_specs=yes
151else
152  rtems_cv_gcc_specs=no
153fi
154rm -f confspec conftest*
155])])
156
157dnl
158dnl $Id$
159dnl
160dnl Check whether the target compiler accepts -pipe
161dnl
162dnl 98/02/11 Ralf Corsepius     corsepiu@faw.uni-ulm.de
163dnl
164
165AC_DEFUN(RTEMS_GCC_PIPE,
166[AC_REQUIRE([RTEMS_PROG_CC])
167AC_CACHE_CHECK(whether $CC_FOR_TARGET accepts --pipe,rtems_cv_gcc_pipe,
168[
169echo 'void f(){}' >conftest.c
170if test -z "`${CC_FOR_TARGET} --pipe -c conftest.c 2>&1`";then
171  rtems_cv_gcc_pipe=yes
172else
173  rtems_cv_gcc_pipe=no
174fi
175rm -f conftest*
176])])
177
178dnl
179dnl $Id$
180dnl
181dnl Check for target g++
182dnl
183dnl Adaptation of autoconf-2.12's AC_PROG_CXX to rtems
184dnl
185dnl 98/02/10 Ralf Corsepius (corsepiu@faw.uni-ulm.de)
186dnl
187 
188AC_DEFUN(RTEMS_PROG_CXX,
189[
190AC_BEFORE([$0], [AC_PROG_CXXCPP])dnl
191AC_BEFORE([$0], [AC_PROG_CXX])dnl
192AC_CHECK_PROGS(CXX, $CCC c++ g++ gcc CC cxx cc++, gcc)
193
194RTEMS_PROG_CXX_WORKS
195AC_PROG_CXX_GNU
196
197if test $ac_cv_prog_gxx = yes; then
198  GXX=yes
199dnl Check whether -g works, even if CXXFLAGS is set, in case the package
200dnl plays around with CXXFLAGS (such as to build both debugging and
201dnl normal versions of a library), tasteless as that idea is.
202  ac_test_CXXFLAGS="${CXXFLAGS+set}"
203  ac_save_CXXFLAGS="$CXXFLAGS"
204  CXXFLAGS=
205  AC_PROG_CXX_G
206  if test "$ac_test_CXXFLAGS" = set; then
207    CXXFLAGS="$ac_save_CXXFLAGS"
208  elif test $ac_cv_prog_cxx_g = yes; then
209    CXXFLAGS="-g -O2"
210  else
211    CXXFLAGS="-O2"
212  fi
213else
214  GXX=
215  test "${CXXFLAGS+set}" = set || CXXFLAGS="-g"
216fi
217CXX_FOR_TARGET=$CXX
218
219dnl restore initial values
220unset CXX
221unset ac_cv_prog_gxx
222])
223
224
225dnl Almost identical to AC_PROG_CXX_WORKS
226dnl Additional handling of malloc
227dnl NOTE: using newlib with a native compiler is cross-compiling, indeed.
228AC_DEFUN(RTEMS_PROG_CXX_WORKS,
229[AC_MSG_CHECKING([whether the target C++ compiler ($CXX $CXXFLAGS $LDFLAGS) works])
230AC_LANG_SAVE
231AC_LANG_CPLUSPLUS
232
233dnl this fails if rtems uses newlib, because rtems has its own malloc which
234dnl is not available at bootstrap
235AC_TRY_COMPILER(
236  [main(){return(0);}],
237  rtems_cv_prog_cxx_works, rtems_cv_prog_cxx_cross)
238if test "$rtems_cv_prog_cxx_works" = "no"; then
239  dnl now retry with our own version of malloc
240  AC_TRY_COMPILER(
241    [extern "C" void *malloc();
242     void *malloc() { return (0); }
243     main(){return(0);}],
244    rtems_cv_prog_cxx_works, rtems_cv_prog_cxx_cross)
245fi
246AC_LANG_RESTORE
247AC_MSG_RESULT($rtems_cv_prog_cxx_works)
248if test $rtems_cv_prog_cxx_works = no; then
249  AC_MSG_ERROR([installation or configuration problem: target C++ compiler cannot create executables.])
250fi
251AC_MSG_CHECKING([whether the target C++ compiler ($CXX $CXXFLAGS $LDFLAGS) is a cross-compiler])
252AC_MSG_RESULT($rtems_cv_prog_cxx_cross)
253])
254
255dnl $Id$
256dnl
257dnl Set target tools
258dnl
259dnl 98/02/12 Ralf Corsepius     (corsepiu@faw.uni-ulm.de)
260dnl
261
262AC_DEFUN(RTEMS_CANONICALIZE_TOOLS,
263[AC_REQUIRE([RTEMS_PROG_CC])dnl
264if test "$rtems_cv_prog_gcc" = "yes" ; then
265  dnl We are using gcc, now ask it about its tools
266  dnl Necessary if gcc was configured to use the target's native tools
267  dnl or uses prefixes for gnutools (e.g. gas instead of as)
268  AR_FOR_TARGET=`$CC_FOR_TARGET --print-prog-name=ar`
269  AS_FOR_TARGET=`$CC_FOR_TARGET --print-prog-name=as`
270  LD_FOR_TARGET=`$CC_FOR_TARGET --print-prog-name=ld`
271  NM_FOR_TARGET=`$CC_FOR_TARGET --print-prog-name=nm`
272  RANLIB_FOR_TARGET=`$CC_FOR_TARGET --print-prog-name=ranlib`
273fi
274
275dnl check whether the tools exist
276dnl FIXME: What shall be done if they don't exist?
277
278dnl NOTE: CC_FOR_TARGET should always be valid at this point,
279dnl       cf. RTEMS_PROG_CC 
280AC_PATH_PROG(CC_FOR_TARGET,"$program_prefix"gcc,no)
281
282dnl FIXME: This may fail if the compiler has not been recognized as gcc
283dnl       and uses tools with different names
284AC_PATH_PROG(AR_FOR_TARGET,"$program_prefix"ar,no)
285AC_PATH_PROG(AS_FOR_TARGET,"$program_prefix"as,no)
286AC_PATH_PROG(NM_FOR_TARGET,"$program_prefix"nm,no)
287AC_PATH_PROG(LD_FOR_TARGET,"$program_prefix"ld,no)
288
289dnl NOTE: This is doubtful, but should not disturb all current rtems'
290dnl       targets (remark: solaris fakes ranlib!!)
291AC_PATH_PROG(RANLIB_FOR_TARGET,"$program_prefix"ranlib,no)
292
293dnl NOTE: These may not be available, if not using gnutools
294AC_PATH_PROG(OBJCOPY_FOR_TARGET,"$program_prefix"objcopy,no)
295AC_PATH_PROG(SIZE_FOR_TARGET,"$program_prefix"size,no)
296])
297
298dnl $Id$
299
300dnl RTEMS_CHECK_MAKEFILE(path)
301dnl Search for Makefile.in's within the directory starting
302dnl at path and append an entry for Makefile to global variable
303dnl "makefiles" (from configure.in) for each Makefile.in found
304dnl
305AC_DEFUN(RTEMS_CHECK_MAKEFILE,
306[RTEMS_CHECK_FILES_IN($1,Makefile,makefiles)
307])
308
309dnl $Id$
310
311dnl RTEMS_CHECK_FILES_IN(path,file,var)
312dnl path .. path relative to srcdir, where to start searching for files
313dnl file .. name of the files to search for
314dnl var  .. shell variable to append files found
315AC_DEFUN(RTEMS_CHECK_FILES_IN,
316[
317AC_MSG_CHECKING(for $2.in in $1)
318if test -d $srcdir/$1; then
319  rtems_av_save_dir=`pwd`;
320  cd $srcdir;
321  rtems_av_tmp=`find $1 -name "$2.in" -print | sed "s/$2\.in/%/" | sort | sed "s/%/$2/"`
322  $3="$$3 $rtems_av_tmp";
323  cd $rtems_av_save_dir;
324  AC_MSG_RESULT(done)
325else
326  AC_MSG_RESULT(no)
327fi
328])
329
330
Note: See TracBrowser for help on using the repository browser.