Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

sdcc missing library error

Help
scsi050
2014-02-28
2014-03-06
  • scsi050
    scsi050
    2014-02-28

    I'm trying to get a very simple C code compiled with sdcc, but I can't get past this missing lib file error:

    root@server:/home/xxxx/testpic# sdcc -mpic14 -p16f877 test.c
    pic16f877.lib: No such file or directory

    SDCC version on Debian:
    SDCC : mcs51/gbz80/z80/z180/r2k/ds390/pic16/pic14/TININative/ds400/hc08 3.1.0 #7066 (Jun 5 2012) (Linux)

    test.c :

    include <string.h>

    char strl[10];

    void main(void) {
    strcpy(strl, "testing");
    }

    Any suggestions? thanks

     
    • Diego Herranz
      Diego Herranz
      2014-02-28

      It looks like you're missing the --use-non-free needed for PIC libraries due to Microchip restrictions.

       
  • scsi050
    scsi050
    2014-02-28

    no luck:

    root@server:/home/xxx/xxxpic# sdcc --use-non-free -mpic14 -p16f877 test.c
    pic16f877.lib: No such file or directory
    root@server:/home/xxxx/xxxspic#

     
  • Raphael Neider
    Raphael Neider
    2014-02-28

    You may need to install sdcc-nonfree as well (if that exists) or build sdcc from source to get access to the pic libraries. IIRC, Debian did not like the unclear license / terms of use of the headers and libraries generated for these targets.

     
  • scsi050
    scsi050
    2014-02-28

    where/how would i get the sdcc-nonfree install?

     
  • Diego Herranz
    Diego Herranz
    2014-02-28

    Can you attach test.c? Due to sourceforge formatting the include part can't be read.

     
  • scsi050
    scsi050
    2014-02-28

    see attachment. It's very simple, straight from the sdcc user manual.

     
    Attachments
  • Diego Herranz
    Diego Herranz
    2014-02-28

    Try adding this line:

    #include <pic16regs.h>

    More info:
    You can also do #include <pic16f877.h> but pic16regs.h includes the header file of the PIC you have defined with -p. This way, if you change to another PIC model, you won't need to change that include line.

     
  • scsi050
    scsi050
    2014-02-28

    adding the include line made no difference. According to the sdcc user manual, the code I have in test.c should compile successfully with the string.h include line. It's like sdcc doesn't know where to find the pic microcontroller lib files. And that's the funny thing, I don't see any p*.lib files in the /usr/share/sdcc folder. Is that why i need the non-free files?

     
    Last edit: scsi050 2014-02-28
  • Raphael Neider
    Raphael Neider
    2014-02-28

    Yes, that is indeed the reason. If Debian does not have the non-free parts (they might be hidden in universe or multiverse repositories, or non-free, if that exists as a repository), then you need to either build from source or use a snapshot build provided by the sdcc project. You can find the pre-built snapshots at http://sdcc.sourceforge.net/snap.php .

    Best regards,
    Raphael

     
  • scsi050
    scsi050
    2014-02-28

    thanks! i downloaded the most recent snap version and ran the install. I now am no longer getting that missing .lib file error, so that's great, but it still doesn't compile successfully:

    root@server:/home/xxxx/xxxpic# sdcc --use-non-free -mpic14 -p16f877 test.c
    message: using default linker script "/usr/share/gputils/lkr/16f877.lkr"
    error: missing definition for symbol "_strcpy", required by "test.o"

    Again, this test.c is the example from the sdcc user manual, so i don't see how there can be an inspector/syntax error now, but this is the farthest i've gotten after a week of this...

     
  • scsi050
    scsi050
    2014-03-05

    can anyone help? Why do I get this error message if sdcc can find the .lib files? thanks

    error: missing definition for symbol "_strcpy", required by "test.o"

     
  • Raphael Neider
    Raphael Neider
    2014-03-05

    Hi,
    strangely, I am sure that I had posted another comment on this one, but for some reason, my post did not make it...
    The PIC14 library (esp. the C standard library, which you are trying to use) is practically non-existing. The linker cannot find strcpy because there is no implementation available in any of the (few) libraries shipped with sdcc for PIC14.
    You need to include all library routines you want to use in your project and link them together with your application.
    You can find source code for many C library routines in the SDCC sources, mostly written in C, occasionally supplemented with assembly routines for specific targets. The Internet also provides source code for virtually every standard library routine.

     
    Last edit: Raphael Neider 2014-03-05
  • scsi050
    scsi050
    2014-03-05

    if I was to use something like a pic 18f452 instead, and used the pic16 libraries, are those libraries more populated?

    I guess I'm confused because I read a how-to article like this: http://hackaday.com/2010/11/03/how-to-program-pics-using-linux/ and they were obviously able to use sdcc (all be it 4 years ago), but still, why does it work for them and not me?

     
    Last edit: scsi050 2014-03-05
  • Raphael Neider
    Raphael Neider
    2014-03-06

    Support for PIC16 targets (18fxxx, 18fxxxx) is in much better shape both regarding correctness of the generated code and libraries (libc, I/O peripheral access libraries).

    The site you linked does not seem to use libc features (at least not in the code sample printed on the Web page). Also, 4 years ago, the "non-free" may not yet have been removed from the Debian packages (so they did not need to specify - - use-non-free).

    Beware:the configuration bit setup in SDCC had changed since then. The

    unsigned int at _CONFIG1 configWord1 = 0x2FF4;
    

    lines probably should be (maybe: must be) replaced with

    #pragma config NAME=value
    

    lines, the proper content of which is always somewhat unclear to me. Basically, SDCC follows the lead of Microchip's compiler here.

    Good luck,
    Raphael