sdcc-lib.h missing?

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

All of a sudden my code quit compiling with a ton of terrible looking errors. However if I go to the first error, it is this:

/stdio.h:34:22: error: sdcc-lib.h: No such file or directory

I am using ubuntu, and I installed everything that 'apt-cache search sdcc' came back with:

sdcc - Small Device C Compiler
sdcc-doc - Small Device C Compiler (documentation)
sdcc-libraries - Small Device C Compiler (libraries)
sdcc-ucsim - Micro-controller simulator for SDCC

But still no sdcc-lib.h anywhere on my hard drive. I assume this happened after an update. Has anyone else run into this issue? Am I wrong in thinking a package maintainer is to blame for my plight?

Just to check I reverted to code that I absolutely know was compiling last month, and even the month before that, and six month old code as well. So if it compiled before, but doesn't compile now, blame the build environment?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What does SDCC have to do with GCC? This forum is for supporting AVR-GCC which is entirely different from SDCC.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not exactly sure, I've never used sdcc specifically before, but it seems the stdio.h is calling it:

In file included from myheader.h:20,
                 from myprogram.c:16:
./stdio.h:34:22: error: sdcc-lib.h: No such file or directory

I assumed it was just a library being called, maybe I need to research just what the hell sdcc is? I was just posting here as I was sure someone else had run into the problem, as I have reinstalled twice from scratch just to make sure I didn't mess anything up. So I was just sure something in the gcc-avr package was the problem or some other package if not there. Maybe I'll post in ubuntu forums as well, but I doubt anyone there who answers will have any avr experience.

Like I said I didn't touch my build environment, just one day it started spitting out those errors, and a ton more (well I probably 'updated' which constitutes as touching it, but surely you catch my drift [nothing in /usr was touched]).

EDIT: also of note I haven't changed my makefile except for the 'TARGET' in over a year of developing on the AVR, so it's not like I just decided to start programming for sdcc in the middle of the night or anything. I just got compiler errors out of the blue, without a clue as to what is wrong. I seriously didn't change systems or anything else major, I MIGHT have updated, but I don't even recall doing that inbetween compiles working and when they didn't. But it's the only explanation I have for code that worked a month ago that does not work now. I have been using bazaar as my revision control system since last February, just to try it out, and no matter what revision I pull for the entire folder of my code nothing compiles. But even the CVS commits of the folder from january '08 no longer compile. I have got to have a build environment problem! Any ideas?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

egrep is your friend. So is diff, but if you use a SCCS then you should be able to see which new edits have introduced new identifiers.

"sdcc" is commonly used with 8051 controllers. The sdcc-pic port is a bit flaky, and I am not sure about other cpu targets.

I suspect that you have used a magic MACRO somewhere that hints that you are using sdcc. Several library headers and code will share source code with avr-gcc.

I identify sdcc specific code with the macro SDCC in my personal source code. sdcc does not follow the usual convention of using double-underscores for compiler specific identifiers. SDCC is a pre-defined macro (like __GNUC__ )

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ya I'm pretty sure none of that was in my code. Never used SDCC before in my life. And like I said, I reverted the entire folder of code I've been manipulating back to multiple instances where I know it was working. It seems somehow the stdio.h that is being called is not the one in /usr/avr. Once again I'm not using any macros other than one's I've previously seen here in the AVR forums, and even then I avoid them like the plague and keep my code simple. But other than variable declarations, and things like sbi and cbi used in standard AVR stuff I can't think of any other Macros I'm using.

The kicker to me is that even last months code doesn't work, which used to compile cleanly (and all versions of code before that as well). And I'm revisioning every file I'm using other than the stuff in /usr/avr.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As I suggested earlier, use your tools.

From the look of your error message, the compiler include path seems to be using a different .

I possess the header that you are looking for. It is in my sdcc include path.

Please copy and paste your build output.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bah humbug, after installing straight debian on another partition everything seems to be working just fine. And grep'ing around in /usr/avr shows no signs of sdcc-lib.h. Anyhow, if debian will get me along then that's fine. Now I'm even considering going back to gentoo, for a small partition that does nothing but AVR work. Does anyone have a preferred environment for locking down the build environment? Has anyone tried:

http://avrlivecd.umfragen-servic...

Sounds interesting. Though nothing is probably smaller than a debian net-install (gentoo's portage tree alone is over a gig, and dammsmalllinux gets bigger once you do an hd install and upgrade to apt [and its debian woody]).

And while I use diff on a daily basis, I've really grown quite fond of kdiff3. It's great for sitting back with a cup of coffee and getting a visual, after coding awhile with vi (even better than vimdiff as kdiff3 is a little nicer on onehandedness). So as much as I'd like to do a command line only debian net-install, I really do want a GUI every now and then. Any favorite OS's from you guys?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If I was you, I would want to know how I got an incorrect ${INCLUDE} directory.

Have a look at your environment variables, and see if someone is being too clever.

I have no problem with having ${INCLUDE} pointing to my native compiler. But to a cross-compiler ???

I would use find + grep to look for other 's

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ya my thoughts exactly, on the ubuntu partition that is. However, everything is smooth with straight debian for the moment. Going to troubleshoot my device now, instead of my build environment. But if I can narrow down what went wrong I'll post it here.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If your goal here was to build an avr-gcc toolchain on a Linux system you are far better just following Bingo's sticky thread at the top of this forum for a stress free life:

https://www.avrfreaks.net/index.p...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Very nice I guess that would be another very viable option, use just about any distro, and build a toolchain yourself which would effectively lock down the build environment. Thanks Superfreak for pointing that option out, and cheers to Bingo for the script! Is this generally the preferred method of those of you who are quite serious about these things?