#72 Header include provokes library build?


I'm compiling a file with the following command line:

c:\Projects\vario\gbparanoia>sdcc --stack-auto --vc -mgbz80 -IC:/gameboy/gbdk-3.0/include -IC:/SDCC-2.9/device/include -c -o part1.o part1.c

The file part1.c refers to to function defined in the header file C:/gameboy/gbdk-3.0/include . The file compiles fine - but then I get this message:

ar ruv C:/SDCC-2.9/lib/gbz80/gbz80.lib
ar: C:/SDCC-2.9/lib/gbz80/gbz80.lib: No such file or directory

Which suggests that it's trying to build the library (which isn't available yet. My make file includes an explicit link command. How can I suppress or eliminate this error?

Also, so far I've been using a file gbdk.lib which consists of a list of object modules in the same directory. This has worked very well for my purpose. The documentation - I've just upgraded to 2.9.0 is a little unclear to me as to whether I can continue to use this method.

Robert Ramey


  • Borut Ražem

    Borut Ražem - 2010-04-07

    Header include doesn't provoke anything else then the header inclusion ;-)
    To exactly see which subcommands are run by sdcc, you can use the -V command line option:

    sdcc -V --stack-auto --vc -mgbz80 -IC:/gameboy/gbdk-3.0/include -IC:/SDCC-2.9/device/include -c -o part1.o part1.c

    If I understand you well, you are executing sdcc from makefile, so it is possible that there is a make rule (explicit or implicit), which tries to build the library? How does your makefile look like?

    Does the invocation of ar happen also if you run sdcc from command line (not from makefile)?

    Anyway, the gbz80.lib should exist, since is a part of the sdcc installation. How did you install sdcc?

    sdcc can use 3 library types: the "list of object modules" you mentioned, libraries produced with the "sdcclib" utility and "ar" format libraries. System libraries prior the 2.9.0 version were "list of object modules" type, in version 2.9.0 they are "ar" format libraries.


  • Robert Ramey

    Robert Ramey - 2010-04-10

    Thanks for your prompt and helpful response!

    I traced the problem to the usage of the -- switch which was used to specify that the linker arguments should be taken from the command line. It seems that this facility is no longer supported in 2.9.0

    The raises the question as to how one can use the linker in a makefile. The arguments come from a make variable (e.g. OBJ=a.o b.o ..). If I can't use this in the command line - how can I pass that information to the linker? I could create a *.lnk file and use the -c switch - but then I have to maintain that and keep it in sync with the makefile - another source of hard to fine build errors - not to mention the extra work.

    What do you recommend?

    Robert Ramey

  • Borut Ražem

    Borut Ražem - 2010-04-10

    The -- switch was available only for z80 and gb targets, so it was removed due the sdld unification and synchronization with asxxxx. Actually it is still supported in the official 2.9.0 release, but it was removed later.

    The .lnk file can be generated on the fly by the makefile by echoing each line into it, including "echo $(OBJ) >> <*>.lnk". So you have to maintain only the makefile.

    The other possibility would be to re-introduce the -- switch, but it should be available in asxxxx too, which will be a longer process, probably not available in sdcc 3.0 release...


  • Robert Ramey

    Robert Ramey - 2010-04-10

    Again that's for a helpful and timely response.

    I re-introduced the -- switch by merging some code from the 2.6 version. This solved my problem.

    Of course, now I have another one. Here is the background.

    a few years ago I embarked upon a project to make a flight instrument for hanggliders which used the Gameboy as the user interface. This project is described at www.rrsd.com.

    Of course I need to make software for my project and I started out using lcc compiler and the gbdk from pascal felber.

    The project kept growing. I made numerous changes to the gbdk.

    The project kept growing. I needed to implement memory banking. I enhanced the hardware to support it then discovered that support for banking was "almost there". I tweaked the sdcc 2.6 compiler to support it. After more effort than I really wanted to invest, I had things working again. Now I could run a program with upto 128K code into the gameboy color!.

    Last year, I decided to add "just one feature". This a very trick calculation of windspeed from GPS input which required extensive floating point math. I managed to get the algorithm working on the PC - a lot more effort than I had anticipated. Then I tried to put it into the Gameboy. No luck. The floating point code sin, cos, tan, atan, exp, log, etc couldn't be made to fit. Also it was excrutiatingly slow. So I rewrote a number of basic floating point functions (fsadd, fssub, fsmul, fsdiv, etc) in assembler and finally made things fit - and alot faster too. I made some basic tests and felt my code was working OK.

    Alas, my program didnt' properly on my Gameboy simulator. I knew that I had to test my
    floating point code independently. I looked around and found http://people.sc.fsu.edu/~burkardt/c_src/paranoia/paranoia.html. I took this program and compiled it with my system. I had to re-organize it to fit - in separate segments - but it does fit (barely) so now I have an exhaustive test of the gameboy floating point implementation.

    It failed the second test. As I investigated, I found that the problem for this failure was not in the library code (where I could fix it) but rather in the compiler which generates some code for floating point operations (e.g. x == 0.0f). I downloaded the 2.9 compiler and generated some code with it and found that it corrected at this problem. So I resolved to switch to the 2.9 version. I rebuilt it and here I am.

    except for one thing. It doesn't generate the code I expect for bank switching. It's almost there. It does generate the bank # in right place (right after the call). But whether I use the -bo ? or #praga bank ? sytax, the code is not found in CODE_? but rather in the area beyond the data. I expect to see

    CODE_1 ...

    but rather I see


    I'll investigate this some more.

    When I started this comment I had a question but now I forgot what it was. Either making this comment answered the question for me (often happens) or I just forget or wanted some empathy.

    Robert Ramey

    Then with some more effort got it loaded into the Gameboy. This basically entailed organizing code in the right memory banks. Finally I was ready to fire it up - only to discover th

  • Robert Ramey

    Robert Ramey - 2010-04-11

    found one of my problems - FWIW here it is

    I used the idiom

    #define PARANOIA_BANK 1
    #pragma bank PARANOIA_BANK

    which used to work in version 2.6 - now it doesn't

    I traced this to an improvement in the pre-processor. It no longer expands macros is #pragma statements. This turns out to be correct behavior even though it is inconvenient in my case. This was very convenient as it permited me to make do

    #include "banks.h"

    which let me re-organize code into banks at one convenent place.

    Finally, there is one last issue.

    #pragma bank X

    creates a new area _X in my linker map. So

    #pragma bank 1

    creates an area _1 in my code.

    Turns out if I use

    #pragma bank CODE_1

    gives me what I expect. I guess that now #pragma bank is equivalent to
    #pragma codeseg <name>

    which is equivalent to --codeseg

    which I suppose I can work with - though it's a pain to change all my make and source files

    Robert Ramey

  • Maarten Brock

    Maarten Brock - 2011-11-05

    This looks like a closed discussion so I've set it pending.

  • Maarten Brock

    Maarten Brock - 2011-11-05
    • status: open --> pending
  • Maarten Brock

    Maarten Brock - 2013-09-21
    • status: pending --> closed
    • assigned_to: Maarten Brock
    • Group: -->

Log in to post a comment.

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

Sign up for the SourceForge newsletter:

No, thanks