ACK - what level of C language compliance? - Minix

This is a discussion on ACK - what level of C language compliance? - Minix ; With which level of the C language specification is the current ACK compiler intended to comply? C89/90, C99, or what? I've recently tried porting several popular packages to Minix3, but most will not build with ack; they build fine with ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: ACK - what level of C language compliance?

  1. ACK - what level of C language compliance?

    With which level of the C language specification is the current ACK compiler
    intended to comply? C89/90, C99, or what?

    I've recently tried porting several popular packages to Minix3, but most
    will not build with ack; they build fine with gcc, however. I thought I
    would contribute a few nice packages, but I'm not sure what the policy is on
    packages that will only build with gcc.

    The first example is Ian Darwin's implementation of the file command - the
    one that's included in all known BSD and Linux distributions, and even in
    Solaris. It will only build with gcc, because ack doesn't recognize the long
    long datatype (C99), and I'm not too keen asking the maintainer to customize
    every occurrence of long long to accommodate ack.

    Is it worthwhile trying to package this up and make it available, even
    though it requires gcc? If so, I'd be more than happy to submit the basic
    Minix patches (header file inclusion stuff, magic file entries to identify
    Minix binaries, etc.) to Ian.


    A couple of other things that run into ack problems but work fine with gcc
    are the FVWM window manager and vim built with the X gui interface (no
    flames here, please - if I can manage to get Motif to build, NEdit is next
    on my list!).


    Bob Woodside
    Woodsway Consulting, Inc.



  2. Re: ACK - what level of C language compliance?

    All,

    > Is it worthwhile trying to package this up and make it available, even
    > though it requires gcc? If so, I'd be more than happy to submit the basic
    > Minix patches (header file inclusion stuff, magic file entries to identify
    > Minix binaries, etc.) to Ian.


    Sure, packages that need gcc are no problem.

    =Ben



  3. Re: ACK - what level of C language compliance?


    "Ben Gras" wrote in message
    news:slrnfoua90.1tr.beng@fspc128-minix.cs.vu.nl...
    > All,
    >
    >> Is it worthwhile trying to package this up and make it available, even
    >> though it requires gcc? If so, I'd be more than happy to submit the basic
    >> Minix patches (header file inclusion stuff, magic file entries to
    >> identify
    >> Minix binaries, etc.) to Ian.

    >
    > Sure, packages that need gcc are no problem.
    >
    > =Ben
    >


    Kewl! I'll clean up my patches, test the build.minix script for
    idempotence, and try to buld a package. Assuming I'll mess that up on the
    first try, I'll try, try again. :-) Then I'll build a couple of virgin
    systems (3.1.2a & 3.1.3a) and try installing on them to be sure there aren't
    any hidden dependencies on local mods on my dev. system.

    If that all goes well, I'll put the first package (file-4.23) up on our
    website and make its presence known here.


    -Bob




  4. Re: ACK - what level of C language compliance?

    On Jan 16, 2:32*pm, "Bob Woodside" wrote:
    > The first example is Ian Darwin's implementation of the file command - the
    > one that's included in all known BSD and Linux distributions, and even in
    > Solaris. It will only build with gcc, because ack doesn't recognize the long
    > long datatype (C99), and I'm not too keen asking the maintainer to customize
    > every occurrence of long long to accommodate ack.


    Hi Bob! You will want to test your build for proper use of long long,
    as I have noticed some very strange (read broken) effects of using
    long long under Minix.

    James T. Sprinkle (The Grue)
    http://www.myspace.com/jamestsprinkle

  5. Re: ACK - what level of C language compliance?


    wrote in message
    news:5201b247-d715-4593-b97d-02d2be95ed4a@i12g2000prf.googlegroups.com...
    On Jan 16, 2:32 pm, "Bob Woodside" wrote:
    > The first example is Ian Darwin's implementation of the file command - the
    > one that's included in all known BSD and Linux distributions, and even in
    > Solaris. It will only build with gcc, because ack doesn't recognize the
    > long
    > long datatype (C99), and I'm not too keen asking the maintainer to
    > customize
    > every occurrence of long long to accommodate ack.


    Hi Bob! You will want to test your build for proper use of long long,
    as I have noticed some very strange (read broken) effects of using
    long long under Minix.


    Howdy, Mr. Grue --

    Bummer! I haven't noticed any misbehavior of the file command, but I
    haven't really looked into its use of long long ints either.

    Any details you could provide on this would be welcome, as you certainly
    seem to have done a lot of Minix ports, to judge from your Web page.

    Thanks,
    Bob




  6. Re: ACK - what level of C language compliance?

    wrote in message
    news:5201b247-d715-4593-b97d-02d2be95ed4a@i12g2000prf.googlegroups.com...
    > On Jan 16, 2:32 pm, "Bob Woodside" wrote:
    >> The first example is Ian Darwin's implementation of the file command -
    >> [...]
    >> It will only build with gcc, because ack doesn't recognize the long
    >> long datatype (C99), and I'm not too keen asking the maintainer to
    >> customize
    >> every occurrence of long long to accommodate ack.


    > Hi Bob! You will want to test your build for proper use of long long,
    > as I have noticed some very strange (read broken) effects of using
    > long long under Minix.


    Thanks for your input, James!

    After a little testing with a home brewed function that prints the 2 words
    of the long long int in hex, I discovered that the problem is not gcc, but
    rather it's the C libraries. Code generated by gcc just Does The Right Thing
    with a long long int, but you can't print it without writing your own
    special functions to format a character string that concatenates the 2
    32-bit halves of the 64-bit integer. :-(

    It finally occurred to me that I was unconsciously laboring under the
    assumption that we had the standard gnu combination of gcc + glibc. However,
    it looks like the gnu libraries are just the standard Minix libs compiled
    with gcc. The version of printf, for example, doesn't recognize the "ll"
    length indicator (also specified in C99) - if you try a format string with
    "%lld", printf will just print "ld" (duh); and "%ld", of course, would just
    give you the low-order 32-bit word.

    As for my port of the file command, the good news is that gcc long long
    handling actually works - as long as you don't try to use them with any
    library functions!. The bad news is that the only places where he uses them
    is in calls to printf! The good news is that most of these cases are in
    debugging code that nobody ever uses, and probably most people don't even
    know about. The bad news is that there are a couple of them that I still
    have to check out to see whether they're important (and they probably are).
    And I thought that this one would be a very easy port!

    As for the general issue, I suppose there are 2 possible approaches to
    getting Minix to play nice with long long ints:

    1) trying to get the Minix C libs fixed, or
    2) trying to port glibc.

    I don't know that either of these sounds very hopeful at present. ACK
    doesn't appear to be a hotbed of development activity (and the Minix version
    is said to be "heavily modified"). And I've no idea what gotcha's may lurk
    in glibc, or how much patching may have been needed to get gcc to work on
    Minix. Ah, well...food for thought. I'll have to look into this later.

    - Bob



  7. Re: ACK - what level of C language compliance?

    --{ Bob Woodside a plopé ceci: }--

    > 2) trying to port glibc.
    >

    Imho, glibc is a heavy bloatware.

    > I don't know that either of these sounds very hopeful at present.


    Please, Keep Minix ISS


    --
    | A: Yes. |
    | >Q: Are you sure? |
    | >>A: Because it reverses the logical flow of conversation. |
    | >>>Q: Why is top posting frowned upon? |

  8. Re: ACK - what level of C language compliance?


    "Thierry B." wrote in message
    news:9v7c75-0gd.ln1@prout.stex...
    > --{ Bob Woodside a plopé ceci: }--
    >
    >> 2) trying to port glibc.

    >
    > Please, Keep Minix ISS
    >


    ISS - ?




  9. Re: ACK - what level of C language compliance?


    "Thierry B." wrote in message
    news:9v7c75-0gd.ln1@prout.stex...
    > --{ Bob Woodside a plopé ceci: }--
    >
    >> 2) trying to port glibc.
    >>

    > Imho, glibc is a heavy bloatware.
    >


    Well, I'm looking for lighter weight alternatives, too. But I'd want to
    avoid anything that requires yet another toolchain to build and install, as
    I think some of the lightweight libc implementations designed primarily for
    embedded systems do. I need to look into this further as time permits.

    I don't see much hope that ACK is going to get this problem (long long int
    support) fixed anytime soon. The Minix version is back at 5.6, and is
    heavily modified. From a very quick look at the version 6.0 sources at VU, I
    think it hasn't been fixed there, either.

    - Bob




  10. Re: ACK - what level of C language compliance?

    --{ Bob Woodside a plopé ceci: }--

    >>
    >> Please, Keep Minix ISS
    >>

    >
    > ISS - ?
    >

    KISS - Keep It Simple & Stupid - If I remember, words from
    Ken Thomson, about the design of Unix...

    --
    >>>>> Le serveur ne comprend pas beaucoup de valeur numériques: ici,
    >>>>> il connait 1664, 51, 27, 11.5 et 43.


  11. Re: ACK - what level of C language compliance?

    --{ Bob Woodside a plopé ceci: }--

    >> Imho, glibc is a heavy bloatware.
    >>

    >
    > Well, I'm looking for lighter weight alternatives, too. But I'd want to
    > avoid anything that requires yet another toolchain to build and install, as
    > I think some of the lightweight libc implementations designed primarily for
    > embedded systems do. I need to look into this further as time permits.
    >

    You can look at µclib and dietlibc, I think.
    Conbined with busybox, may be you can build a very small system.


    --

    Ne pas utiliser la gnôle des marais quand un futex vous a jeté
    un sort de catégorie "use gdb, you lamer".


  12. Re: ACK - what level of C language compliance?

    --{ Bob Woodside a plopé ceci: }--

    >> Imho, glibc is a heavy bloatware.
    >>

    >
    > Well, I'm looking for lighter weight alternatives, too. But I'd want to
    > avoid anything that requires yet another toolchain to build and install, as
    > I think some of the lightweight libc implementations designed primarily for
    > embedded systems do. I need to look into this further as time permits.
    >

    You can look at µclib and dietlibc, I think.
    Conbined with busybox, may be you can build a very small system.

    http://www.fefe.de/dietlibc/

    --

    Ne pas utiliser la gnôle des marais quand un futex vous a jeté
    un sort de catégorie "use gdb, you lamer".


  13. Re: ACK - what level of C language compliance?

    Thierry B. wrote:

    > KISS - Keep It Simple & Stupid - If I remember, words from
    > Ken Thomson, about the design of Unix...


    In that case you wrote the equivalent of "Keep Minix it simple stupid".


    Rui Maciel

  14. Re: ACK - what level of C language compliance?


    "Thierry B." wrote in message
    news:kk0e75-smh.ln1@prout.stex...
    > --{ Bob Woodside a plopé ceci: }--
    >
    >>> Imho, glibc is a heavy bloatware.
    >>>

    >>
    >> Well, I'm looking for lighter weight alternatives, too. But I'd want to
    >> avoid anything that requires yet another toolchain to build and install,
    >> as
    >> I think some of the lightweight libc implementations designed primarily
    >> for
    >> embedded systems do. I need to look into this further as time permits.
    >>

    > You can look at µclib and dietlibc, I think.
    > Conbined with busybox, may be you can build a very small system.
    >
    > http://www.fefe.de/dietlibc/


    Yes, I had already taken a quick look at these. µclib is one that requires
    its own toolchain - it's gcc-based, but uses a specially patched version.
    That doesn't necessarily rule it out, but I want to look more closely at
    dietlibc first, as it looks like it can use a stock gcc toolchain. I think
    we want to consider which implementation is more compliant with modern
    standards - since that's the whole purpose of looking for an alternative C
    library (small being a very nice added benefit).

    But right now, I'm looking at a less drastic solution than a whole new libc.
    The Trio library at

    http://daniel.haxx.se/projects/trio/

    offers a set of replacement string functions, including printf and friends.
    It looks to be C99 compliant, and my initial tests show that it works fine
    for the long long/printf case. I need to do some more rigorous testing,
    however.


    - Bob




+ Reply to Thread