Cannot find user library on D0: about hi-tech-z80-c HOT 11 CLOSED

The compiler driver program has limitations. When you define the HITECH environment variable, it will assume all your libraries are in the drive/user area you set it to. You can, however, specify the library file name on the command line and it will be passed to the linker - e.g.

D>c -v -o -x -i0:d: vicdemo1.c 0:d:libc3l.lib

If you look at the source-code to the driver program (in the repo file CPM/C309-16.C) you’ll see the processing of the -L option just prefixes the HITECH path and LIB to what you specify (e.g. In your case -lc3l becomes 0:B:LIBC3L.LIB).

Tony

from hi-tech-z80-c.

This doesn't work when you need the second pass i.e. c -o -x -i0:d: -lc3l -lc3l vicdemo1.c which works if I copy the lib to b:. You get undefined symbols error. In this case you need:

D>c -v -o -x -i0:d: vicdemo1.c 0:d:libc3l.lib 0:d:libc3l.lib

from hi-tech-z80-c.

The ordering of modules in your library may need to be adjusted to reduce//eliminate references to object modules that have already been scanned by the linker. Repeating the library (as you found out) also is a work-around. This is a limitation of the one-pass linker. I found I needed to do this too with the standard libraries after I tinkered with them.

from hi-tech-z80-c.

I actually got this from the the original docs back in the 90s. Are you saying my includes need to be recorded? It only happens on 2 programs. Or are you saying libr order needs to change. How do I know the proper order?

from hi-tech-z80-c.

If you get a listing of the modules in your library - some of your object modules may have externals that make backward references to another library module (which the linker has already scanned past). It could be as simple as re-ordering the modules in your library to only have forward references (so the linker can resolve them by reading more modules from your library in its single pass).

D>libr s 0:d:libc3l.lib

will show the modules and references.

from hi-tech-z80-c.

I should add - sometimes you can't make all modules do forward references only. In this situation you can add a duplicate copy of a module when you create the library. e.g. where module1 references module2 symbols and module2 back references module1 symbols, then you can add module1 to the library twice
using -

libr
libr> r libtest.lib \
libr> module1.obj \
libr> module2.obj \
libr> module1.obj

from hi-tech-z80-c.

I assume (didn't read libr docs) D means down reference and U means up reference?

from hi-tech-z80-c.

In the module listing from libr, D means the symbol is defined by the module, and U means the symbol is undefined (or external) to the module.

It is the undefined ones that the linker tries to resolve by reading forward through the libraries. If one of the modules it has loaded previously has defined the symbol it will use it - but it won't go backwards looking for previously unloaded modules to resolve it. (I hope my explanation is clear).

from hi-tech-z80-c.

Oh yeah, normally you don't deal with this stuff, but it's like a 2 pass assembler figuring out forward references. Cannot do it in a single pass. I'll figure out the order, thanks. I haven't played with HTC for about 5 years. Before that it was the early 90s.

from hi-tech-z80-c.

Modern linkers solve this by performing multiple passes. There are linkers for CP/M that can do multiple passes (like Phoenix PLINK-II and perhaps Microsoft L80) - but the object file format from HITECH C is not compatible with them.

from hi-tech-z80-c.

It was easier to use the undefined symbols error output then just move that obj file to the bottom once you figure out which one it is. libr s didn't really help (or at least from what I could tell). In any event, you pointed me in the right direction and this will hopefully be bread crumbs for others to follow. Thanks again.

from hi-tech-z80-c.