#957 compile fails on Mac OS X due to missing include

closed-accepted
None
5
2013-05-25
2005-07-23
Anonymous
No

Compile of SDCC 0.5.4 fails on Mac OS X Version 10.4.2 with the
attached errors.

Including system.h in dbuf.h allows compile to succeed.

Errors:
gcc -Wall -pipe -ggdb -g -O2 -I. -I.. -I../support/Util -c SDCCutil.c -
o SDCCutil.o
In file included from SDCCutil.c:30:
../support/Util/dbuf.h:32: error: parse error before "size_t"
../support/Util/dbuf.h:32: warning: no semicolon at end of struct or
union
../support/Util/dbuf.h:33: warning: type defaults to 'int' in
declaration of 'len'
../support/Util/dbuf.h:33: warning: data definition has no type or
storage class
../support/Util/dbuf.h:35: error: parse error before '}' token
../support/Util/dbuf.h:42: error: parse error before "size"
../support/Util/dbuf.h:43: error: parse error before "size_t"
../support/Util/dbuf.h:44: error: parse error before "size_t"
../support/Util/dbuf.h:45: error: parse error before "size_t"
../support/Util/dbuf.h:47: error: parse error before "dbuf_get_size"
../support/Util/dbuf.h:47: warning: type defaults to 'int' in
declaration of 'dbuf_get_size'
../support/Util/dbuf.h:47: warning: data definition has no type or
storage class
SDCCutil.c: In function 'appendStrSet':
SDCCutil.c:79: error: storage size of 'dbuf' isn't known
SDCCutil.c:79: warning: unused variable 'dbuf'
SDCCutil.c: In function 'joinStrSet':
SDCCutil.c:102: error: storage size of 'dbuf' isn't known
SDCCutil.c:102: warning: unused variable 'dbuf'
make[1]: *** [SDCCutil.o] Error 1
make: *** [sdcc-cc] Error 2

Discussion

  • Maarten Brock

    Maarten Brock - 2005-07-23
    • milestone: --> fixed
    • status: open --> open-accepted
     
  • Maarten Brock

    Maarten Brock - 2005-07-23

    Logged In: YES
    user_id=888171

    Hi,

    SDCC 0.5.4 never existed. The oldest version in CVS is
    2.1.x. size_t is defined in stddef.h and that's what's included
    now.

    Two questions:
    Please try again and tell us if you can compile and run it on
    OSX ?
    And please tell us your name, preferrably by logging in before
    you post. This also has the advantage you are kept up-to-
    date by email when someone adds to this thread.

    Thanks,
    Maarten

     
  • David Schmenk

    David Schmenk - 2005-08-02

    Logged In: YES
    user_id=800572

    This error can be overcome by moving the #include <ctype.h> outside of the
    #ifdef _WIN32 clause in SDCCUtil.c. However, you will get another error
    further along with a conflicting type stack_t in the pic16 code. I'm guessing
    the new BSD subsystem for Tiger moved and added typedefs. Panther
    seems to work OK.

     
  • David Schmenk

    David Schmenk - 2005-08-03

    Logged In: YES
    user_id=800572

    To continue with my previous comment, I did a global replace on stack_t with
    pstack_t in pic16/pcode.c to remove the conflict with a system define. That
    allowed the rest of sdcc to compile except for the simulator which has an ld
    error referring to unknown flag --start-group (which doesn't bother me). I'll
    compare the code generated with 2.4.0 under Panther.

     
  • Maarten Brock

    Maarten Brock - 2005-08-03

    Logged In: YES
    user_id=888171

    I checked this lately on an OS X server 10.3.9 (I have no clue
    what it's nickname is; panda? lion? cheetah? It was hard
    enough to find the version nr.) which has GCC 3.3. I found no
    errors other than those ld --start-group/--end-group problems
    for the simulator. Then I went looking in which version of GCC
    these options were introduced but they seem to be older than
    3.3. So I can only guess Apple crippled GCC for the Mac.

    B.t.w. size_t is not defined in <ctype.h> according to the
    standard but in <stddef.h> as mentioned. I've already
    changed this in cvs on 2005-07-23. And on 2005-05-14
    Raphael already renamed stack_t to dynstack_t.

    If you want to report bugs then PLEASE first check with the
    latest snapshot or cvs version if it still exists.

    Now if you could help us nail down this problem with ld then
    please do so. Our knowledge of OS X is very limited I guess
    as we were not able to get it to run regression tests or build
    snapshots for it in the last few years.

    Maarten

     
  • Borut Ražem

    Borut Ražem - 2005-09-14
    • assigned_to: nobody --> borutr
    • status: open-accepted --> closed-accepted
     
  • Borut Ražem

    Borut Ražem - 2005-09-14

    Logged In: YES
    user_id=568035

    Roger Hawkins <roger.au@iinet.net.au> had the same problem
    on Mac OS X (10.4).

    After David's fix of stack_t and my fix of ld --start-group
    Roger wrote:

    ...
    Also, the code compiled without modifications. I tested the
    compiler (looked at the build files) and it appears to be
    working correctly.
    ...

    So I think I can close this bug...

    Borut

     

Log in to post a comment.