Re: [Txr-users] installing

[Kaz Kylheku]

On Sat, 7 Apr 2012 08:55:06 -0400, "Christopher A. Simon"
<address@hidden> wrote:
> In file included from lib.c:44:
> lib.h:406: error: conflicting types for ‘trunc’
> /usr/include/architecture/i386/math.h:395: error: previous declaration
> of ‘trunc’ was here
> lib.h:432: error: conflicting types for ‘floorf’
> /usr/include/architecture/i386/math.h:370: error: previous declaration
> of ‘floorf’ was here
> In file included from lib.c:47:
> rand.h:32: error: conflicting types for ‘random’
> /usr/include/stdlib.h:224: error: previous declaration of ‘random’ was here
> make: *** [lib.o] Error 1

Hi Christopher,

Sorry, we are running into a nonconformance in the compilation
environment.

I don't build on OS/X so I rely on user reports for breakage like this.

I'm going to look into this issue, but in the meanwhile, the workaround
is to rename the clashing identifiers, e.g:

  #define trunc txr_trunc
  val trunc(val a, val b);

We don't call the system's trunc function so this is okay.

I will maybe add tests to the configure script for these clashing
situations and have it spit out these workaround #define directives
into "config.h".

The "config.h" is included before all other headers, and after
system headers, so it is a good place for this type of workaround.
(But if you do it by hand, it's not such a good place, because
it will be clobbered if you re-run configure.)

More background info:

I used -ansi and -D_POSIX_SOURCE=2 in hopes of restricting
the C dialect to ANSI C and what identifiers are visible from
the system headers to just some old POSIX functions. Evidently,
this is not being honored in some ways in the OS/X build
environment, or at least not by some headers and for some
identifiers.

See here about _POSIX_SOURCE:
http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_02.html#tag_02_02_01_01

The "trunc" function in TXR has nothing to do with any OS/X or
BSD function of that name; it's just that it's being made visible
in the <math.h> header even though we didn't ask for it.
C programs have a right to use "trunc" as an external name, and so
do programs written to the classic 1990 POSIX interface in
which "trunc" does not exist.

System headers must guard what identifiers they expose to the
program based on what feature selection macros are present.

For instance, in /usr/include/stdlib.h on the GNU C library, we have
this:

#if defined __USE_SVID || defined __USE_XOPEN_EXTENDED || defined
__USE_BSD
[...]
/* Return a random long integer between 0 and RAND_MAX inclusive.  */
extern long int random (void) __THROW;

Glibc is quite rigorous in obeying the Unix-standard feature selection
macros;
it does not expose the declaration of "random" unless you are using
feature selection macros like -D_BSD_SOURCE or -D_XOPEN_SOURCE on
the compiler command line or elsewhere.