language extensions needed by linux /usr/include headers

J

jacob navia

Hi

Going on with the porting of lcc-win64 to lcc-linux-64 I have discovered
that most system headers in /usr/include need a compiler with at least
the following #defines prdefined:

__USE_XOPEN_EXTENDED=1
__gnuc_va_list=va_list
__i386__=1

If you do not have those symbols you wont be able to compile any header.

Since stdio.h and all headers use the non portable headers definitions
in /usr/include/bits /usr/include/asm it is imperative to predefine
those symbols.

Question: Is there somewhere a list of those needed symbols? I have
found those by trial and error and it costs a lot of effort to figure
out what is going wrong each time.

Another problem of this situation is that I need to provide (as I did
under windows) my own headers, but I do not know where to put them since
accessing /usr/include would need root access.

Since there are quite a lot of linux gurus around here, maybe some of
them has this list?
 
V

vippstar

Since there are quite a lot of linux gurus around here, maybe some of
them has this list?

Navia, you moron, don't (cross)post this crap to comp.lang.c
 
B

Bernhard Agthe

Hi,

jacob said:
Going on with the porting of lcc-win64 to lcc-linux-64 I have discovered
that most system headers in /usr/include need a compiler with at least
the following #defines prdefined:
....

Which compiler are you using, what does the command line look like (e.g.
using gcc in special modes?). Try compiling the "hello world"
application, to check your build environment. If that is fine, you can
go for the compilation problems of your app.

By the way, this has nothing to do with "language extensions", more with
build environment.
Another problem of this situation is that I need to provide (as I did
under windows) my own headers, but I do not know where to put them since
accessing /usr/include would need root access.

Different problem. Installation or application build?

Usually you have your own headers in your project directory (source or
include subdirectory, remember to inform the compiler about your include
dir: "-I../myinclude"). Once you install your application to a system,
check out the PREFIX mechanism commonly used by Unix installation
mechanisms.

By the way, your question should be placed to

Ciao..
 
A

Antoninus Twink

Question: Is there somewhere a list of those needed symbols? I have
found those by trial and error and it costs a lot of effort to figure
out what is going wrong each time.

If you haven't already, you might want to check out
/usr/include/features.h, and the manpage for feature_test_macros.
Another problem of this situation is that I need to provide (as I did
under windows) my own headers, but I do not know where to put them
since accessing /usr/include would need root access.

Typically, your Makefile will have a PREFIX variable (in a typical
autoconf setup, the default PREFIX is /usr/local, but the user can
override it by giving a PREFIX=$HOME/mystuff command-line option to
configure).

Then "make install" will put binaries in $(PREFIX)/bin, headers in
$(PREFIX)/include, etc. You trust the user to set CPPFLAGS etc.
appropriately to find the headers in the directories where they've
installed them (certainly /usr/include and /usr/local/include will
already be in the default include path for most sane setups).
 
A

Antoninus Twink

Which compiler are you using, what does the command line look like (e.g.
using gcc in special modes?). Try compiling the "hello world"
application, to check your build environment. If that is fine, you can
go for the compilation problems of your app.

By the way, this has nothing to do with "language extensions", more with
build environment.

I think you misunderstand the situation.

Jacob Navia is the author of a compiler, which he's porting to Linux.
AIUI, he wants to be able to let developers using his compiler use parts
of the glibc standard library, e.g. the i/o routines, but for this he
needs to be able to compile the GNU C library headers with his own lcc
compiler (as far as I'm aware, he's relying on the GNU linker for the
linking step).
 
R

Richard

Navia, you moron, don't (cross)post this crap to comp.lang.c

It's about a C compiler and bringing it (for free) to Linux. I can not
think of anything more on topic (Programming and Using C).
 
J

jacob navia

Richard said:
It's about a C compiler and bringing it (for free) to Linux. I can not
think of anything more on topic (Programming and Using C).

The regulars again...

Just ignore them
 
B

Bart

Navia, you moron, don't (cross)post this crap to comp.lang.c

You know, you should learn to rein in your nasty temper if you want to
help out in a public forum. I'm sure your rude posts put some people
off posting.
 
R

Richard

Bart said:
You know, you should learn to rein in your nasty temper if you want to
help out in a public forum. I'm sure your rude posts put some people
off posting.

Not as much as his incorrect posts.
 
J

jacob navia

William said:
Normally, this misuse of the word 'regulars' does not
bother me, but for some reason I find it irksome today.
Jacob Navia is clearly a 'regular' on this group. Many
'regulars' in this group are not overly narrow in
their definition of topicality. Please stop abusing
the word. I do not think it means what you think
it means.

Well, what I mean is that there is a group of people here that will
attack any post I do here for no other reason that its me. "vippstar" is
a good example of this people. I used the "regulars" because is the
way they call themselves.

I do not have any better name for them.
 
K

Kenny McCormack

William Pursell said:
Normally, this misuse of the word 'regulars' does not
bother me, but for some reason I find it irksome today.
Jacob Navia is clearly a 'regular' on this group. Many
'regulars' in this group are not overly narrow in
their definition of topicality. Please stop abusing
the word. I do not think it means what you think
it means.

Wrong. The word has a specific meaning, in the context of "clc".
I.e., the phrase "clc reg" means a specific thing.

I should know, as I am generally credited with coining the term.
 
K

Kenny McCormack

jacob navia said:
Well, what I mean is that there is a group of people here that will
attack any post I do here for no other reason that its me. "vippstar" is
a good example of this people. I used the "regulars" because is the
way they call themselves.

And you were (and are) perfectly right to do so.
I do not have any better name for them.

We have other names, but some are not printable.
 
M

Martin Ambuhl

Bart said:
You know, you should learn to rein in your nasty temper if you want to
help out in a public forum. I'm sure your rude posts put some people
off posting.

If it discourages the flood of off-topic postings, that can only be
considered a good thing. Jacob is among that group of some 5 posters
who are making a conscious effort to destroy comp.lang.c with off-topic
postings, trolling messages, and such. We don't need any more of them.
 
J

jacob navia

Martin said:
If it discourages the flood of off-topic postings, that can only be
considered a good thing. Jacob is among that group of some 5 posters
who are making a conscious effort to destroy comp.lang.c with off-topic
postings, trolling messages, and such. We don't need any more of them.

I have retired from this group and post only very occasionally. You are
lying (as always).
 
K

Keith Thompson

Martin Ambuhl said:
If it discourages the flood of off-topic postings, that can only be
considered a good thing. Jacob is among that group of some 5 posters
who are making a conscious effort to destroy comp.lang.c with
off-topic postings, trolling messages, and such. We don't need any
more of them.

I don't believe jacob is deliberately trying to destroy comp.lang.c.
I think he just has a different (and IMHO quite wrong) idea of what's
topical. I certainly don't think he's a *deliberate* troll.

And vippstar, your response was not helpful. Do you really expect to
change jacob's mind by calling him a moron? If you want to vent your
frustration, perhaps you could find a better place to do it.
 
J

jacob navia

George said:
You're probably going to experience other problems too. I wrote a compiler
that was used for source level translation of some C code that was extended
with more operators. I first wrote it for NetBSD and then ported it to
GNU/Linux. Porting it to GNU/Linux was more difficult, because of the GNU
featuritis.

In some cases the GNU libc headers use a lot of features of gcc, such as
__attribute__((packed)), and various other macros defined that use
__attribute__. There's also an __extension__ IIRC.

You will also need to support all of the extended asm features, so that some
syscalls, and other features work, because some of the syscalls are
implemented as inline functions in the headers that use the asm keyword.

Parsing the same code as gcc in a non-ambiguous way is somewhat difficult.
gcc uses a mostly hand-written parser, so trying to parse the same thing
with yacc isn't easy. This was my first serious yacc project, but it took
a while to make the grammar non-ambiguous.

There is a compiler that has been revived called pcc. It was based
originally on the portable C compiler sources from many years ago. My
understanding is that the current developers are trying to create a BSD
licensed alternative to gcc, with a cleaner design, and compatibility with
gcc to some extent.

See: http://pcc.ludd.ltu.se/

Perhaps you could learn from that. I'm not sure what state it's in at the
moment, but it's something to consider.

Another thing that occurred to me that might help:

gcc -dumpspecs

and:

gcc -v somefile.c

Those should both provide some information you need.


George

Gosh this looks terrible.

But I am used to it. Microsoft does the same thing, and they do
include assembler in their system headers. The work around is to
provide your own header that replaces theirs. If I create an
lcc include path and I look there first, I can bypass the gnu
headers that can't be converted.

In any case, thanks for your answer. It was very helpful
 
K

Kaz Kylheku

["Followup-To:" header set to comp.lang.c.]
Hi

Going on with the porting of lcc-win64 to lcc-linux-64 I have discovered
that most system headers in /usr/include need a compiler with at least
the following #defines prdefined:

It is glibc's "features.h" which establishes values for some of these internal
macros. Some of them come from GCC.
__USE_XOPEN_EXTENDED=1

This one comes from glibc itself. See the features.h header.
__gnuc_va_list=va_list

Not sure.
__i386__=1

From gcc.
If you do not have those symbols you wont be able to compile any header.

Since stdio.h and all headers use the non portable headers definitions

What ``non portable''. This is part of an implementation which is not
constrained by portability concerns. Glibc development takes place with gcc.
That's what is supported. Don't expect help from the libc-alpha mailing list.
Question: Is there somewhere a list of those needed symbols? I have
found those by trial and error and it costs a lot of effort to figure
out what is going wrong each time.

This is not really a C question, but a problem of making lcc look like gcc.

I'm quite sure that the people that have the best information about this do not
read the comp.lang.c newsgroup.

Either you can patch glibc headers until you are blue in the face so that they
works with lcc, or you can make lcc work with glibc by making it look a little
more like gcc.

You can see what constants gcc spits out by running this:

gcc -x c -E -dD - < /dev/null

Of course, that doesn't include things defined in gcc-specific headers.
Another problem of this situation is that I need to provide (as I did
under windows) my own headers, but I do not know where to put them since
accessing /usr/include would need root access.

To solve this problem, look how gcc does it. You can install gcc on your system
multiple times. You don't have to be root to have your own gcc installation.
Like many other programs, gcc can be configured with any --prefix.
If you are user joe, you can install gcc in /home/joe/gcc (for example).

As part of its build steps, gcc runs a program called fixincludes, which
analyzes headers in the system directory according to some pattern matching
rules. When broken, noncompliant or otherwise incompatible headers are
detected, then workarounds will be installed in gcc's headers directory.

You will likely have to solve the same problem.

Watch out: glibc on Linux integrates with kernel headers. When you build glibc,
you must specify a kernel header tree. This kernel header tree gets installed
together with the rest of glibc's headers, which won't work without it. (That
step is outside of the glibc build process). Kernel headers are a moving
target and cause problems, even for gcc, which has to target some of them with
fixincludes.

The glibc headers themselves at least pay some service to the idea that they
may be compiled by a compiler other than gcc. For instance the glibc
<string.h> header only includes the machine-specific optimizations in
<bits/string.h> if it detects the presence of gcc. This looks to be reasonably
well-behaved and friendly. The optimizations use gcc inline assembly syntax.
Someone providing a different compiler might want to roll his own optimizations
and just replace that header. #include <string.h> in your compiler could
include your header and then fall back on the glibc one to get the rest of the
material, minus the gcc-specific optimizations.

Kernel headers assume that the compiler is GCC. Programs that depend on kernel
headers will probably be the most difficult to support under a non-gcc
compiler. And most programs depend on some kernel headers to some extent,
indirectly through glibc headers that include kernel headers.
 
J

jacob navia

Kaz said:
["Followup-To:" header set to comp.lang.c.]
If you do not have those symbols you wont be able to compile any header.

Since stdio.h and all headers use the non portable headers definitions

What ``non portable''. This is part of an implementation which is not
constrained by portability concerns. Glibc development takes place with gcc.
That's what is supported. Don't expect help from the libc-alpha mailing list.

I thought that the operating system would be open to any compiler, not
just a single compiler. Windows headers are the same but then, Microsoft
is accused of being the empire of evil... I thought linux would be more
open.
> Either you can patch glibc headers until you are blue in the face so that they
works with lcc, or you can make lcc work with glibc by making it look a little
more like gcc.

Obviously I will not replicate the inline assembler of gcc, what would
cost me at least 5-6 months of effort. Any header that has assembler in
it will be replaced by a similar header without assembler.
Watch out: glibc on Linux integrates with kernel headers. When you build glibc,
you must specify a kernel header tree. This kernel header tree gets installed
together with the rest of glibc's headers, which won't work without it. (That
step is outside of the glibc build process). Kernel headers are a moving
target and cause problems, even for gcc, which has to target some of them with
fixincludes.

Well, I do not want to compile glibc or the kernel with my compiler.
Probably I will port lcc-win's glibc to linux anyway since they are
specific to the features I use.
The glibc headers themselves at least pay some service to the idea that they
may be compiled by a compiler other than gcc. For instance the glibc
<string.h> header only includes the machine-specific optimizations in
<bits/string.h> if it detects the presence of gcc. This looks to be reasonably
well-behaved and friendly. The optimizations use gcc inline assembly syntax.
Someone providing a different compiler might want to roll his own optimizations
and just replace that header. #include <string.h> in your compiler could
include your header and then fall back on the glibc one to get the rest of the
material, minus the gcc-specific optimizations.

Kernel headers assume that the compiler is GCC. Programs that depend on kernel
headers will probably be the most difficult to support under a non-gcc
compiler. And most programs depend on some kernel headers to some extent,
indirectly through glibc headers that include kernel headers.

Any headers can be replaced. The problem will be all the libraries that
use gcc stuff.
 
C

CBFalconer

jacob said:
.... snip ...

Well, what I mean is that there is a group of people here that
will attack any post I do here for no other reason that its me.
"vippstar" is a good example of this people. I used the
"regulars" because is the way they call themselves.

More wrong information. You never get attacked when you stay
on-topic. There are many groups handling linux. This is NOT one
of them.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top