Hitting a linking problem zcc/z80asm externs etc.

Post Reply
jacotton
Member
Posts: 89
Joined: Fri Nov 24, 2017 1:35 am

Hitting a linking problem zcc/z80asm externs etc.

Post by jacotton »

Working on a complex (mess) set of code.

The root problem is:

(in list file in /tmp)
tmpSREnBPfR.lis:233 0000 ;int trace;
tmpSREnBPfR.lis:1212 0002 00 00 ._trace defs 2
tmpSREnBPfR.lis:1285 04CD PUBLIC _trace

Error from compiler during link attempt.

Error at file '/tmp/tmp8iDBMFDB.asm' line 175: symbol '_trace' not defined
^ ---- ld hl,(_trace)

I am not certain, but, it looks like ._trace is not the same as _trace.

I don't see a flag that fixes this.

simplified sample code...

a.c
int trace;
main()
{
}

b.c
extern int trace;
void bla()
{
int i = trace;
}
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

I didn't encounter the error (although I did encounter another one, see next post):

foo.c

Code: Select all

int trace;

void main(void)
{
}
bar.c

Code: Select all

extern int trace;

void bla(void)
{
   int i = trace;
}
(guessing cpm target although it won't matter for this test)

classic sccz80:
zcc +cpm foo.c bar.c -o baz -create-app

classic zsdcc:
zcc +cpm -compiler=sdcc --reserve-regs-iy foo.c bar.c -o baz -create-app

newlib sccz80:
zcc +cpm -clib=new foo.c bar.c -o baz -create-app

newlib zsdcc:
zcc +cpm -clib=sdcc_iy foo.c bar.c -o baz -create-app


All symbols have to be available when the binary is made. Here I'm giving the list of all involved source files in one compile line so all symbols will always be available. If you're doing separate compilation, ie making object files then joining them together:

zcc +cpm -vn -c -clib=new foo.c
zcc +cpm -vn -c -clib=new bar.c
zcc +cpm -vn -clib=new foo.o bar.o -o baz -create-app

The public and extern symbols are encoded in the object file and then the extern symbols are patched by the linker in the last step which makes the binary.

z80nm foo.o

Code: Select all

File foo.o at $0000: Z80RMF11
  Name: foo
  Names:
    G A $0000 _trace (section bss_compiler) foo.c:28
    G A $0000 _main (section code_compiler) foo.c:20
z80nm bar.o

Code: Select all

File bar.o at $0000: Z80RMF11
  Name: bar
  Names:
    G A $0000 _bla (section code_compiler) bar.c:20
  External names:
    U         _trace
"_trace" is a global export in foo.o and is an unpatched symbol in bar.o.
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

Issue found with filenames and sccz80 compiles:
https://github.com/z88dk/z88dk/issues/673
jacotton
Member
Posts: 89
Joined: Fri Nov 24, 2017 1:35 am

Post by jacotton »

Thanks for looking at this.

Still not sure what is going on here, but I wonder if its a build environment issue.

I'll dig through the list files and see if there is an opposite case in the same code.
jacotton
Member
Posts: 89
Joined: Fri Nov 24, 2017 1:35 am

Post by jacotton »

I changed my compile flags and the problem moved.
new flags are
zcc +cpm -O3 -vn -DMALLOC -lmalloc --c-code-in-asm --list -no-cleanup -create-app
old flags
zcc +cpm -O3 -s -m -DAMALLOC -lmalloc --c-code-in-asm --list -no-cleanup -create-app
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

It works for me with both compile lines:

zcc +cpm -O3 -vn -DMALLOC --c-code-in-asm --list -no-cleanup -create-app foo.c bar.c
zcc +cpm -O3 -s -m -DAMALLOC --c-code-in-asm --list -no-cleanup -create-app foo.c bar.c

I think you have an older version that may have some problems you're seeing. The "-lmalloc" is not necessary anymore because malloc is part of the target's library now.

Maybe move to the current version?

Nightly builds (there will be a fix for the issue brought up here in tonight's build)
http://nightly.z88dk.org/

Install instructions:
https://www.z88dk.org/wiki/doku.php?id= ... stallation

or via github (always up to date but you have to update the binaries and z80 libraries yourself):
https://github.com/z88dk/z88dk
Post Reply