Kimball Thurston <[EMAIL PROTECTED]> writes:
> Adding AC_C_INLINE to configure.in will automatically add a #define for
> the appropriate inline... and a line in config.h.in. Oh, you mention
> that below. I haven't tried with 0.2.7 - before ( 0.2.3 or somewhere
> around there ) didn't have the AC_C_INLINE in the configure.
I have it in my sources here, but I can't say for sure if it got in
0.2.7. Anyway, it would be nice if you could add that to your
configure.in (if it isn't there already) and tell me if that solves
the problem.
> The other env settings are necessary to point the SGI c compiler to
> libs and includes it doesn't know about by default, or we want to
> override the included (sometimes ancient) versions, so I wouldn't
> expect those to change. The only other change, and I don't have an
> example to give you, as it's been a while since I hacked autoconf,
> but adding a check to see if alloca and or malloc is defined and
> included in the std C lib, or if -lmalloc is necessary to get the
> alloca/malloc stuff would be cool... Perhaps using AC_CHECK_FUNC or
> something like that?
Testing for -lmalloc should be easy (I'm assuming that malloc() is the
appropriate function to test for?). As for includes and library
directories, it is possible to have a list of directories to try in
configure.in. I.e, first try linking with zlib with no extra flags. If
that fails, try -L/usr/local/lib, if that fails also, try
/usr/gnu/lib, etc. If one of the directories works, add it to the
linker flags. And similarly for include directories.
> The problem is with the extern... only gcc can deal with extern inline,
> which if I remember correctly was something Linus added to gcc for
> linux, so particular kernel functions can make sure to not have a stack
> frame or something bizarre like that - I can't remember. He at least
> cares about that existing for some reason... :)
I think extern inline is the recommended modifiers (from the gcc
manual) when inline functions are used as macros. But one could add a
test for that. It should also be possible to conditionalize the
definitions in the .c file so that they are included iff the functions
are declared as extern in the header file. At least I think that will
do the right thing. In libc you actually need both definitions;
otherwise you get link errors if you try to actually call (rather than
inline) the function. For instance, if you compile without
optimization, or if you take the address of the function.
> > > ! static const char bad_key_err[] =
> > > ! static const char *bad_key_err =
> > I don't quite understand what happens here (I didn't write this code).
> > Can you explain? Perhaps the bugfix should be sent to the glibc folks.
>
> It's a deal with gcc and how gcc allows you to define variables. I don't
> remember all the changes that are in for C9X, but many compilers don't
> have those changes. Anyways, N_ is a gettext-ism if I remember
> correctly, and so it's acting as a function or something like that (I
> don't remember right now), and you can't initialize [] char strings to a
> return value in most compilers...
It depends on what the N_ expands to. If it expands to
{ some, nonconstant, values, }
it's a gcc-ism. If it expands to a function call, I don't think it
will work with any compiler. You can't initialize a foo[] from a foo*,
not even with gcc. Hmm, perhaps if the function somehow returns an
array *by value*, but that sounds really bizarre?
> Most of the changes that end up being made to make OSS projects compile
> usually have to do with gcc-isms. Most commonly it's things like this,
> or initializing variables based on a function argument. This is fine for
> C++ and gcc, but good old C doesn't allow anything but a constant for an
> initializer, although I believe they've changed that for C9X, but I
> don't think many compilers support most of the C9X changes yet (gcc only
> supports about half, in terms of 2.95.2)...
I hope it's in C9X. It's a really useful extension.
/Niels
