#52 order of library search

closed
None
5
2004-01-20
2004-01-07
No

A change in the order in which the folders are searched
for *.lib files is required. First the folders specified in
the command line via -L option should be searched
before attempting to search the sdcclib. This change
will enable the end users to modify/rewrite the
functions which are there in the standard library.

Thanks in advance
ganesh

Discussion

  • Borut Ražem

    Borut Ražem - 2004-01-07

    Logged In: YES
    user_id=568035

    Please be more specific about the target and SDDC version,
    vhere you found the problem.

     
  • ganesh meenu

    ganesh meenu - 2004-01-07

    Logged In: YES
    user_id=945594

    I use sdcc 2.3.5 (June 10 2003) (MINGW32) on Win2K box.
    My target device is mcs51. Sorry about not giving this info in
    first place

    Regards Ganesh

     
  • Borut Ražem

    Borut Ražem - 2004-01-07

    Logged In: YES
    user_id=568035

    Did you try with a newer SDCC version?
    Can you attach an short example, comman line and the
    produced .lkr file?
    I took a look to the code, and it seems OK: -k entries for
    -L paths are (or at least should be :-) before system library
    path entries.

    If the .lkr file is OK, then this is probably a linker problem...

    Borut

     
  • ganesh meenu

    ganesh meenu - 2004-01-09

    Logged In: YES
    user_id=945594

    I rewrote the strcpy function to add 0x200 to the bytes as
    they are copied. I named the function as strcpy and the file
    containing this function as strcpy.c. I placed this file in a
    folder called lib in my working folder. I compiled this file with
    sdcc -c strcpy.c and it compiled OK creating the strcpy.rel
    file. I added an entry strcpy in my already existing utils.lib
    file. Now I created TEST_LIB.c file which has the main()
    function. In this, I created a string ucase[]
    = "ABCDEFGHIJKLMNOP". I copied this to another string lcase
    [17] using strcpy(lcase, ucase); I displayed both the strings
    in the 2x16 LCD connected to my kit. I expect to see
    ABCDEFGHIJKLMNOP & abcdefghijklmnop, but I see
    uppercase in both the lines. (I get expected result if I
    rename my function to zstrcpy and call zstrcpy in the main. )

    The following are the extracts from the .map and .lnk files:
    Extract from TEST_LIB.map
    -----------------8><---------------------------------------------
    -------

    Libraries Linked [ object file ]

    lib/LCD.lib [ lcd_pos ]
    D:\SDCC_235_20030610\bin\..\lib\small/libsdcc.lib
    [ _strcpy ]
    lib/LCD.lib [ lcd_string ]
    D:\SDCC_235_20030610\bin\..\lib\small/libsdcc.lib [
    _startup ]
    D:\SDCC_235_20030610\bin\..\lib\small/libsdcc.lib [
    _gptrput ]
    D:\SDCC_235_20030610\bin\..\lib\small/libsdcc.lib
    [ _bp ]
    D:\SDCC_235_20030610\bin\..\lib\small/libsdcc.lib [
    _gptrget ]
    lib/utils.lib [ delay1ms ]
    -----------------8><---------------------------------------------
    -------
    Extract from TEST_LIB.lnk
    -----------------8><---------------------------------------------
    -------
    -k lib
    -k D:\SDCC_235_20030610\bin\..\lib\small
    -l libsdcc
    -l libint
    -l liblong
    -l libfloat
    -l utils.lib
    -l LCD.lib
    -l i2c.lib
    -l Serial.lib
    -l SerialStack.lib
    -l MDBStack.lib
    TEST_LIB.rel

    -e
    -----------------8><---------------------------------------------
    -------

    I feel even though the folders are searched in the required
    order (myfolder followed by sdccfolder) the lib files are taken
    the otherway around (sdcclib followed by mylib). As I had
    mentioned earlier, having mylib searched first will help the
    user to rewrite the some lib functions to suit his requirement.

    Regards Ganesh

     
  • Borut Ražem

    Borut Ražem - 2004-01-10

    Logged In: YES
    user_id=568035

    OK, now I see: the problem is not with -k lines, but with -l
    lines in .lnk file: libsdcc.lib is scanned before utils.lib.
    Can you provide the command line of sdcc invocation?
    Did you try with the lates sdcc snapshot?

    Sorry for so many questions,
    Borut

     
  • Borut Ražem

    Borut Ražem - 2004-01-10
    • assigned_to: nobody --> borutr
     
  • Borut Ražem

    Borut Ražem - 2004-01-10

    Logged In: YES
    user_id=568035

    fixed in src/SDCCmain.c, revision: 1.188.

    ganeshaadityan: can you verify it?

    Borut

     
  • ganesh meenu

    ganesh meenu - 2004-01-12

    Logged In: YES
    user_id=945594

    Hi Borut,
    Thanks for your help. I am not (yet) in the habit of building
    my own sdcc, I download windoze binaries. I am not sure
    whether this patch would have made it's way into the
    winbins dated 11th Jan. So I'll wait for the next binaries,
    download it, and confirm the results (want to avoid
    downloading 2.7 Mb twice ;-).

    Thanks once again for looking into my problem.

    Regards Ganesh

     
  • Bernhard Held

    Bernhard Held - 2004-01-12

    Logged In: YES
    user_id=203539

    The head of the ChangeLog is included in each snapshot. The
    ChangeLog clearly tells you, if the fix made it's way into the
    snapshot.

     
  • ganesh meenu

    ganesh meenu - 2004-01-13

    Logged In: YES
    user_id=945594

    Hi Borut,

    The patch seems to work ok, as could be seen from the *.lnk
    and *.map files generated.

    I say 'seems' because ver 2.3.7 dated 12th-Jan-2004 has
    apparently broken some of my previous code.
    For example consider the follwoing :

    #define CRYSTAL_FREQUENCY 11059000
    #define CLOCKS_PER_CYCLE 12

    #define ITES_PER_MSEC (CRYSTAL_FREQUENCY/
    (10010*CLOCKS_PER_CYCLE)) - 2

    const unsigned int ites_per_msec =
    ITES_PER_MSEC;

    When compiled with sdcc -c, the value assigned to
    ites_per_msec is 0x005a in the previous version

    (2.3.5 dated 10th Jun 2003 MINGW32) whereas it is 0xfc0d
    with the latest version (2.3.7 dated 12th

    Jan 2004 MINGW32).

    I tried to verify the present problem, by circumventing the
    above (by #define ITES_PER_MSEC

    0x005A), but still my code is not running correctly (it is
    compiling ok).

    I'll explore further and keep you all posted.

    Meanwhile can anything be done about the pre-processor
    problem highlighted above?

    Also, the head of ChangeLog file seems to be a plain text
    ascii file which opens in the notepad, but the contents are
    not directly human readable. Any special utility required for
    that?

    Thanks in advance

    Regards Ganesh

     
  • Bernhard Held

    Bernhard Held - 2004-01-13

    Logged In: YES
    user_id=203539

    SDCC certainly throwed a warning: "integer overflow in
    expression". The expression is evaluated with the type "int",
    so that (10010*CLOCKS_PER_CYCLE) = 130120 = 0x1fc48
    overflows. Fix it with:

    #define ITES_PER_MSEC (CRYSTAL_FREQUENCY/
    (10010L*CLOCKS_PER_CYCLE)) - 2

     
  • ganesh meenu

    ganesh meenu - 2004-01-20
    • status: open --> closed
     
  • ganesh meenu

    ganesh meenu - 2004-01-20

    Logged In: YES
    user_id=945594

    Hi All,

    Finally I could verify the feature. It works.

    Thanks Borut.

    Thanks to other developers.

    Regards Ganesh

     

Log in to post a comment.

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

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks