#1431 Wrong pic14devices.txt used

closed-fixed
nobody
5
2013-05-25
2008-02-24
No

If an older version of SDCC is already installed when building the pic14 libraries the wrong pic14devices.txt file is used. On my system this resulted in pic16f886 and pic16f887 not being recognized.

To reproduce this bug from a working build, do a 'make install' and remove any device from /usr/local/share/include/pic/pic14devices.txt.
Then do 'make clean' in the sdcc/device/lib/ source directory and finally 'make' SDCC again.

The error message is:
'16f886' was not found.

The version is anything after 2008-01-24 (#5000).

A work-around is to manually remove /usr/local/share/include/pic/pic14devices.txt before the build.

Maarten

Discussion

  • Borut Ražem

    Borut Ražem - 2008-02-25

    Logged In: YES
    user_id=568035
    Originator: NO

    The problem is that "installation" paths (see SDCCmain.c, setIncludePath()) are searched first and if the device file is not found, the "second attempt is used when initially building the libraries" (see src/pic/device.c, find_device()).

    I think that this is a correct behavior, since sdcc is meant to be used in "user" environment and not in "build" environment (I would even remove the "second attempt is used when initially building the libraries").

    We developers should be carefull to avoid such problems...

    Borut

     
  • Raphael Neider

    Raphael Neider - 2008-03-03
    • milestone: --> fixed
    • status: open --> closed-fixed
     
  • Raphael Neider

    Raphael Neider - 2008-03-03

    Logged In: YES
    user_id=1115835
    Originator: NO

    This time I agree with Maarten and changed the search order for the pic14devices.txt file; I also removed the "second attempt", as it was completely bogus...

    Fixed in SDCC r5063.

     
  • Borut Ražem

    Borut Ražem - 2008-03-03

    Logged In: YES
    user_id=568035
    Originator: NO

    Raphael, you solution by looking first in user defined paths an then in system paths is optimal.

    I was just against adding an new "special purpose hard coded" path. And you even removed the "second attempt" :-)

    Borut

     

Log in to post a comment.

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

Sign up for the SourceForge newsletter:





No, thanks