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

Re: [RFH] Loki bug #409370: missing 64-bit executablex



On Mon, 24 Mar 2008, brian m. carlson wrote:

Here's the difference: in <sys/stat.h>, the following occurs:

#if __WORDSIZE == 64
   long int __unused[3];
#else
# ifndef __USE_FILE_OFFSET64
   unsigned long int __unused4;
   unsigned long int __unused5;
# else
   __ino64_t st_ino;                   /* File serial number.  */
# endif
#endif

So on 64-bit platforms, a field called __unused is defined. But in param_lex.c, the following code exists:

#if defined(__FreeBSD__)
#include <sys/cdefs.h>
#else
#define __unused
#endif

So that code in <sys/stat.h> comes out to:
 long int [3];
which isn't valid.

Sounds reasonable.

The solution is not to define things that aren't in your namespace, so flex shouldn't #define __unused, or use it, for that matter.

Well, the file param_lex.c was autogenerated in the first place

/* A lexical scanner generated by flex */

/* Scanner skeleton version:
 * $Header: /home/daffy/u0/vern/flex/RCS/flex.skl,v 2.91 96/09/10 16:58:48 vern Exp $
 * $FreeBSD: src/usr.bin/lex/flex.skl,v 1.8 2004/01/06 19:03:44 nectar Exp $
 */
...


and I get

$ grep -A2 -B2 __unused *
param_lex.c-#include <sys/cdefs.h>
param_lex.c-#else
param_lex.c:#define __unused
param_lex.c-#endif
param_lex.c-
--
param_lex.c-
param_lex.c-static void *yy_flex_alloc YY_PROTO(( yy_size_t ));
param_lex.c:static void *yy_flex_realloc YY_PROTO(( void *, yy_size_t )) __unused;
param_lex.c-static void yy_flex_free YY_PROTO(( void * ));
param_lex.c-


So while I probably might be able to patch this via

  s/__unused/__unused_by_other_systems_but__FREEBSD__/

this might break on som Debian/FREEBSD port and it would be better to
fix the according flex input.

I also wonder whether there is some hidden quirk in flex.  It might be that
this only happens in old versions of flex and I have to admit that I have
no idea at all about flex and what I would have to do to.

Kind regards

         Andreas.

--
http://fam-tille.de


Reply to: