#2279 Build Error on OS X Mavericks

open
nobody
None
other
5
2015-04-20
2014-06-17
No

This is observed on OS X, while building revision 9034

./configure --disable-z80-port --disable-z180-port --disable-r2k-port --disable-r3ka-port --disable-gbz80-port --disable-tlcs90-port --disable-ds390-port --disable-ds400-port --disable-pic14-port --disable-pic16-port --disable-hc08-port --disable-s08-port --disable-stm8-port --disable-sdcdb --disable-non-free --disable-ucsim

Then when building:

$ make
/bin/sh ./libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. -I./../include  -DHAVE_asxxxx_vec  -DBINDIR='"/usr/local/bin"'  -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT asxxxx.lo -MD -MP -MF .deps/asxxxx.Tpo -c -o asxxxx.lo asxxxx.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I. -I. -I./../include -DHAVE_asxxxx_vec -DBINDIR=\"/usr/local/bin\" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT asxxxx.lo -MD -MP -MF .deps/asxxxx.Tpo -c asxxxx.c -o asxxxx.o
asxxxx.c:169:19: error: unused variable 'digs' [-Werror,-Wunused-const-variable]
static const char digs[] = "0123456789ABCDEF";
                  ^
1 error generated.
make[5]: *** [asxxxx.lo] Error 1
make[4]: *** [all-recursive] Error 1
make[3]: *** [all] Error 2
make[2]: *** [all-bfd] Error 2
make[1]: *** [all] Error 2
make: *** [sdcc-sdbinutils] Error 2

Using very latest XCode command line utils (April 2014)

$ gcc -v Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.2.0 Thread model: posix

Discussion

  • George Oikonomou

    Just to quickly add that the build succeeds if we add --disable-werror to the configure argument list, as discussed under 2245

     
  • Ben Shi

    Ben Shi - 2014-06-18
    • status: open --> closed
     
    • George Oikonomou

      May I enquire about the reason for closing this? Fixed, Invalid, Can't reproduce, Duplicate, something else?

      Thanks

       
  • Ben Shi

    Ben Shi - 2014-06-18

    I thought this is not a bug, since adding --disable-error to configure can make the build successful. What is your opinion?

     
  • Maarten Brock

    Maarten Brock - 2014-06-18

    If SDCC doesn't build out-of-the-box I consider it broken.

    I would agree if George added -Werror himself but I understand he didn't and had to add --disable-error to get it working.

     
    Last edit: Maarten Brock 2014-06-18
  • Maarten Brock

    Maarten Brock - 2014-06-18
    • status: closed --> open
     
    • Ben Shi

      Ben Shi - 2014-06-18

      besides disable werror and fix the spreading warnings, how to fix?

      and how do the mac machines do in build farm?

       
      Last edit: Ben Shi 2015-05-07
  • George Oikonomou

    My opinion on this is that a simple ./configure should lead to a working build (provided dependencies installed). But of course I understand that this is often easier said than done.

    Having said that, this didn't break due to a change in SDCC itself. It stopped working due to changes in the OS X toolchain for Mavericks. I've been working with SDCC rev #8717 for ages and it used to build just fine without --disable-werror. I just tried to re-build it and guess what :)

    For my configuration (mcs51 only), I got two errors:

    The first one is easy to fix:

    /bin/sh ./libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. -I./../include  -DHAVE_asxxxx_vec  -DBINDIR='"/usr/local/bin"'  -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT asxxxx.lo -MD -MP -MF .deps/asxxxx.Tpo -c -o asxxxx.lo asxxxx.c
    libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I. -I. -I./../include -DHAVE_asxxxx_vec -DBINDIR=\"/usr/local/bin\" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT asxxxx.lo -MD -MP -MF .deps/asxxxx.Tpo -c asxxxx.c -o asxxxx.o
    asxxxx.c:169:19: error: unused variable 'digs' [-Werror,-Wunused-const-variable]
    static const char digs[] = "0123456789ABCDEF";
                      ^
    1 error generated.
    make[5]: *** [asxxxx.lo] Error 1
    make[4]: *** [all-recursive] Error 1
    make[3]: *** [all] Error 2
    make[2]: *** [all-bfd] Error 2
    make[1]: *** [all] Error 2
    make: *** [sdcc-sdbinutils] Error 2
    

    Removing the declaration of digs fixes it. The TOHEX macro relies on digs, but it's not called so perhaps best remove it too.

    The second one is a bit of a problem:

    gcc -DHAVE_CONFIG_H -I.  -I. -I. -I../bfd -I./../bfd -I./../include -DLOCALEDIR="\"/usr/local/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation  -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT nm.o -MD -MP -MF .deps/nm.Tpo -c -o nm.o nm.c
    nm.c:1697:28: error: 'sbrk' is deprecated [-Werror,-Wdeprecated-declarations]
          char *lim = (char *) sbrk (0);
                               ^
    /usr/include/unistd.h:582:7: note: 'sbrk' declared here
    void    *sbrk(int);
             ^
    1 error generated.
    make[5]: *** [nm.o] Error 1
    make[4]: *** [all-recursive] Error 1
    make[3]: *** [all] Error 2
    make[2]: *** [all-binutils] Error 2
    make[1]: *** [all] Error 2
    make: *** [sdcc-sdbinutils] Error 2
    

    Every page I looked at seems to suggest that this is a problem caused by clang and that it is best fixed by compiling with -Wno-deprecated

    configure could automatically turn off --disable-error for OS X, but I think it's not the best way forward. Perhaps, we can compile sdbinutils with -Wno-deprecated?

    And by the way "Hi, Ben" :)

     
    • Ben Shi

      Ben Shi - 2014-06-18

      besides the two errors in mcs51, there are also other similar ones spread in the entire source code.

      maybe the best way is to improve sdcc's code quality, make it acceptable by all platforms / native compilers.

      in fact, while building sdcc, much more warnings rise on my macos than my ubuntu.

      btw: sbrk seems to be a linux sys-call, which is deprecated on bsd / macos?

       
      Last edit: Ben Shi 2015-05-07
  • Ben Shi

    Ben Shi - 2015-03-11

    Bug [#2247] is the same problem with this. They are all due to newer gcc/clang become more strict. And they can all be fixed by improving sdcc itself code quality.

     

    Related

    Bugs: #2247


    Last edit: Maarten Brock 2015-07-30
  • Ben Shi

    Ben Shi - 2015-04-20
    • Category: Build --> other
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks