bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Minix support, part 2


From: Bruno Haible
Subject: Minix support, part 2
Date: Sun, 31 Jul 2011 16:58:02 +0200
User-agent: KMail/1.13.6 (Linux/2.6.37.6-0.5-desktop; KDE/4.6.0; x86_64; ; )

The second part of Minix support: The native compiler on Minix 3,
/usr/bin/cc, is of brand "Amsterdam Compiler Kit" and defines __ACK__.
The GCC and GNU binutils are also available on this platform, but
not fully interoperable: When 'ar' and 'ranlib' are used to create
libraries from object files built with cc, cc cannot use the resulting
libraries:

$ make
...
ar cru libtests.a localename.o glthread/lock.o  malloca.o glthread/thread.o  
glthread/threadlib.o btowc.o putenv.o setenv.o unsetenv.o wcrtomb.o wctob.o
ranlib libtests.a
source='test-alloca-opt.c' object='test-alloca-opt.o' libtool=no  DEPDIR=.deps 
depmode=none /bin/sh ../build-aux/depcomp  cc -DHAVE_CONFIG_H -I. -I..  
-DGNULIB_STRICT_CHECKING=1  -DIN_GNULIB_TESTS=1  -I. -I.  -I.. -I./..  
-I../gllib -I./../gllib    -g -c -o test-alloca-opt.o test-alloca-opt.c
"test-alloca-opt.c", line 38: (warning) 'main' old-fashioned function definition
cc  -g   -o test-alloca-opt test-alloca-opt.o libtests.a ../gllib/libgnu.a 
libtests.a  
/usr/lib/em_led: libtests.a: wrong magic number (fatal)
*** Error code 1

The difference between both kinds of libraries becomes apparent using the
'file' command on a glibc system:

For libc.a from /usr/lib/:
  libc.a:     current ar archive random library
For the library generated with "ar":
  libtests.a: current ar archive

The fix is to use "cc -c.a -o libtests.a ..." instead of
"ar cru libtests.a ...".

There could be two ways of achieving this:
  a) Autoconf and Automake could introduce a macro that defines not only
     RANLIB, but also AR and ARFLAGS.
  b) Two dummy scripts could be added to Minix, as
     /usr/bin/ar and /usr/bin/ranlib. The first one would invoke "cc -c.a",
     the second one would do nothing.
The problem with approach b) is that if $PATH contains /usr/pkg/bin before
/usr/bin, GNU binutils will be used nevertheless. And conversely, if
$PATH contains /usr/pkg/bin after /usr/bin, then builds with CC=gcc will
not work.

So it seems to be that a) would be desirable. But it's the Minix developers
who will have to approach the Autoconf and Automake maintainers; I can't speak
for them.

For the moment, I'm only adding this to gnulib.


2011-07-31  Bruno Haible  <address@hidden>

        Add support for Minix with ACK compiler.
        * m4/gnulib-common.m4 (gl_PROG_AR_RANLIB): New macro.
        * gnulib-tool (func_import, func_create_testdir): Emit invocation of
        gl_PROG_AR_RANLIB instead of AC_PROG_RANLIB.

--- m4/gnulib-common.m4.orig    Sun Jul 31 16:41:23 2011
+++ m4/gnulib-common.m4 Sun Jul 31 16:03:27 2011
@@ -1,4 +1,4 @@
-# gnulib-common.m4 serial 28
+# gnulib-common.m4 serial 29
 dnl Copyright (C) 2007-2011 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -211,6 +211,35 @@
 [m4_define([AS_VAR_IF],
 [AS_IF([test x"AS_VAR_GET([$1])" = x""$2], [$3], [$4])])])
 
+# gl_PROG_AR_RANLIB
+# Determines the values for AR, ARFLAGS, RANLIB that fit with the compiler.
+AC_DEFUN([gl_PROG_AR_RANLIB],
+[
+  dnl Minix 3 comes with two toolchains: The Amsterdam Compiler Kit compiler
+  dnl as "cc", and GCC as "gcc". They have different object file formats and
+  dnl library formats. In particular, the GNU binutils programs ar, ranlib
+  dnl produce libraries that work only with gcc, not with cc.
+  AC_REQUIRE([AC_PROG_CC])
+  AC_EGREP_CPP([Amsterdam],
+    [
+#ifdef __ACK__
+Amsterdam
+#endif
+    ],
+    [AR='cc -c.a'
+     ARFLAGS='-o'
+     RANLIB=':'
+    ],
+    [dnl Use the Automake-documented default values for AR and ARFLAGS.
+     AR='ar'
+     ARFLAGS='cru'
+     dnl Use the ranlib program if it is available.
+     AC_PROG_RANLIB
+    ])
+  AC_SUBST([AR])
+  AC_SUBST([ARFLAGS])
+])
+
 # AC_PROG_MKDIR_P
 # is a backport of autoconf-2.60's AC_PROG_MKDIR_P, with a fix
 # for interoperability with automake-1.9.6 from autoconf-2.62.
--- gnulib-tool.orig    Sun Jul 31 16:41:23 2011
+++ gnulib-tool Sun Jul 31 16:03:04 2011
@@ -5126,7 +5126,7 @@
     echo "  m4_pattern_allow([^gl_ES\$])dnl a valid locale name"
     echo "  m4_pattern_allow([^gl_LIBOBJS\$])dnl a variable"
     echo "  m4_pattern_allow([^gl_LTLIBOBJS\$])dnl a variable"
-    echo "  AC_REQUIRE([AC_PROG_RANLIB])"
+    echo "  AC_REQUIRE([gl_PROG_AR_RANLIB])"
     if test -n "$uses_subdirs"; then
       echo "  AC_REQUIRE([AM_PROG_CC_C_O])"
     fi
@@ -5735,7 +5735,7 @@
        echo "AC_PROG_CC"
        echo "AC_PROG_INSTALL"
        echo "AC_PROG_MAKE_SET"
-       echo "AC_PROG_RANLIB"
+       echo "gl_PROG_AR_RANLIB"
        echo
        if test -n "$uses_subdirs"; then
          echo "AM_PROG_CC_C_O"
@@ -5850,7 +5850,7 @@
    echo "m4_pattern_allow([^gl_LIBOBJS\$])dnl a variable"
    echo "m4_pattern_allow([^gl_LTLIBOBJS\$])dnl a variable"
    echo
-   echo "AC_PROG_RANLIB"
+   echo "gl_PROG_AR_RANLIB"
    echo
    if test -n "$any_uses_subdirs"; then
      echo "AM_PROG_CC_C_O"

-- 
In memoriam Jean Jaurès <http://en.wikipedia.org/wiki/Jean_Jaurès>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]