language extensions needed by linux /usr/include headers

Discussion in 'C Programming' started by jacob navia, Feb 5, 2009.

  1. jacob navia

    jacob navia Guest

    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?
    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
     
    jacob navia, Feb 5, 2009
    #1
    1. Advertising

  2. jacob navia

    Guest

    On Feb 5, 2:11 pm, jacob navia <> wrote:

    <snip off-topic crap>

    > 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
     
    , Feb 5, 2009
    #2
    1. Advertising

  3. In article <>,
    <> wrote:
    >On Feb 5, 2:11 pm, jacob navia <> wrote:
    >
    ><snip off-topic crap>
    >
    >> 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


    They call him, vippy, vippy, ...

    Faster than lightning...
     
    Kenny McCormack, Feb 5, 2009
    #3
  4. Hi,

    jacob navia wrote:
    > 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
    news:comp.os.linux.development.apps

    Ciao..
     
    Bernhard Agthe, Feb 5, 2009
    #4
  5. On 5 Feb 2009 at 12:11, jacob navia wrote:
    > 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).
     
    Antoninus Twink, Feb 5, 2009
    #5
  6. On 5 Feb 2009 at 14:30, Bernhard Agthe wrote:
    > 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).
     
    Antoninus Twink, Feb 5, 2009
    #6
  7. jacob navia

    Richard Guest

    writes:

    > On Feb 5, 2:11 pm, jacob navia <> wrote:
    >
    > <snip off-topic crap>
    >
    >> 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


    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).
     
    Richard, Feb 5, 2009
    #7
  8. jacob navia

    jacob navia Guest

    Richard wrote:
    > writes:
    >
    >> On Feb 5, 2:11 pm, jacob navia <> wrote:
    >>
    >> <snip off-topic crap>
    >>
    >>> 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

    >
    > 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

    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
     
    jacob navia, Feb 5, 2009
    #8
  9. jacob navia

    Bart Guest

    On Feb 5, 12:55 pm, wrote:
    > On Feb 5, 2:11 pm, jacob navia <> wrote:
    >
    > <snip off-topic crap>
    >
    > > 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


    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.


    --
    Bartc
     
    Bart, Feb 5, 2009
    #9
  10. jacob navia

    Richard Guest

    Bart <> writes:

    > On Feb 5, 12:55 pm, wrote:
    >> On Feb 5, 2:11 pm, jacob navia <> wrote:
    >>
    >> <snip off-topic crap>
    >>
    >> > 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

    >
    > 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.
    >
    >
    > --
    > Bartc


    Not as much as his incorrect posts.
     
    Richard, Feb 5, 2009
    #10
  11. jacob navia

    jacob navia Guest

    William Pursell wrote:
    > On 5 Feb, 15:39, jacob navia <> wrote:
    >> Richard wrote:
    >>> writes:

    >
    >>>> 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).

    >> The regulars again...
    >>

    >
    > 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.

    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
     
    jacob navia, Feb 5, 2009
    #11
  12. In article <>,
    William Pursell <> wrote:
    ....
    >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.
     
    Kenny McCormack, Feb 5, 2009
    #12
  13. In article <498b1725$0$4087$>,
    jacob navia <> wrote:
    ....
    >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.
     
    Kenny McCormack, Feb 5, 2009
    #13
  14. Bart wrote:
    > On Feb 5, 12:55 pm, wrote:
    >> On Feb 5, 2:11 pm, jacob navia <> wrote:


    >>> 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

    >
    > 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.
     
    Martin Ambuhl, Feb 5, 2009
    #14
  15. jacob navia

    jacob navia Guest

    Martin Ambuhl wrote:
    > Bart wrote:
    >> On Feb 5, 12:55 pm, wrote:
    >>> On Feb 5, 2:11 pm, jacob navia <> wrote:

    >
    >>>> 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

    >>
    >> 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.


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

    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
     
    jacob navia, Feb 5, 2009
    #15
  16. Martin Ambuhl <> writes:
    > Bart wrote:
    >> On Feb 5, 12:55 pm, wrote:
    >>> On Feb 5, 2:11 pm, jacob navia <> wrote:
    >>>> 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

    >> 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.


    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.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Feb 5, 2009
    #16
  17. jacob navia

    jacob navia Guest

    George Peter Staplin wrote:
    > jacob navia wrote:
    >
    >> 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?

    >
    > 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

    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
     
    jacob navia, Feb 5, 2009
    #17
  18. jacob navia

    Kaz Kylheku Guest

    ["Followup-To:" header set to comp.lang.c.]
    On 2009-02-05, jacob navia <> wrote:
    > 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.
     
    Kaz Kylheku, Feb 5, 2009
    #18
  19. jacob navia

    jacob navia Guest

    Kaz Kylheku wrote:
    > ["Followup-To:" header set to comp.lang.c.]
    > On 2009-02-05, jacob navia <> wrote:
    >> 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.

    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
     
    jacob navia, Feb 5, 2009
    #19
  20. jacob navia

    CBFalconer Guest

    jacob navia wrote:
    >

    .... 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.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.
     
    CBFalconer, Feb 5, 2009
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John Salerno
    Replies:
    30
    Views:
    2,024
    Stephan Kuhagen
    Aug 10, 2006
  2. Yves Dorfsman

    #!/usr/bin/env python vs. #!/usr/bin/python

    Yves Dorfsman, May 2, 2008, in forum: Python
    Replies:
    27
    Views:
    2,090
    Tim Roberts
    May 10, 2008
  3. TsanChung
    Replies:
    4
    Views:
    1,289
    TsanChung
    Sep 21, 2008
  4. shankha
    Replies:
    0
    Views:
    738
    shankha
    May 5, 2009
  5. anne001
    Replies:
    1
    Views:
    584
Loading...

Share This Page