[Ecls-list] C99

[Andy Hefner]

On Sat, Feb 18, 2012 at 6:03 PM, Andy Hefner <ahefner at gmail.com> wrote:
> Hi. I've been updating some code written a couple years ago to work on
> the latest ECL. I hit a snag relating to C99 support. I like to use
> C99 features in my inline C. It isn't essential - I could convert it
> back to C89, but probably better to work through a couple small
> issues.
>
> My build script compiles source files to .o with compile-file
> :system-p t and builds an executable with c:build-program. What I've
> done in the past, for C99 support, is putting "-std=c99" on the
> *user-cc-flags* (or previousl, c::*cc-flags*).


Apologies. Some gmail keyboard focus idiocy caused that email to be
sent prematurely. Hopefully that doesn't happen again.

I'll correct the previous paragraph:

My build script compiles and loads a few files of compile-time
dependencies (macros, mostly) to FASLs, then compiles any modified
source files to .o via compile-file :system-p t , building an
executable with c:build-program. What I've done in the past, for C99
support, is putting "-std=c99" on the *user-cc-flags*. Running this
script again this morning, there was a problem relating to leading
underscores in symbol names that caused the FASLs not to load. With
"-std=c99" enabled, I'd see a mix of calls to things like "_ecl_car"
that don't link, alongside the correct "ecl_car".  I don't understand
how GCC's C99 support affects identifier names, but there's probably a
simple fix for this.

As a workaround, I tried rebuilding all of ECL with -std=c99 on the
CFLAGS. This nearly works, but my object files don't link due to C99's
different treatment of inline functions causing duplicate symbols from
the gmp library. Applying the patch from the following post to ECL's
version of GMP fixes the problem:

http://gmplib.org/list-archives/gmp-devel/2009-December/001281.html

With that patch, I got my code building again. Working around a
unicode-related issue (possibly a bug in ECL; I still need to
investigate this), everything still seemed to work great. I noticed,
when building with threads enabled, that it seemed to freeze acquiring
a lock around the GC, but I guess that's to be expected with the
locking code in flux. I didn't need threads anyway, and feel better
keeping them disabled, for the sake of stability.