Undefined reference

[deevans]

Trying to reproduce the Pascal copytext using J&K Software Tools modules results in the following:

copy.mod compiling copy. Main program. 259 chars. /tmp/ccsPZDIr.o: In function main': /home/sinuhe/src/obn/copy.c:14: undefined reference toFilters__init' /home/sinuhe/src/obn/copy.c:17: undefined reference to `Filters_copy' collect2: error: ld returned 1 exit status Assemble and link: gcc -fPIC -g -I "/opt/voc/include" copy.c -o copy -L"/opt/voc/lib" -l voc -- failed: status 0, exitcode 1. Terminated by Halt(1).

The following code was used:

MODULE Prims; IMPORT ulmIO; CONST FS* = 1CX; EOF* = 1CX;

PROCEDURE getc*(VAR c: CHAR): CHAR; VAR ch: CHAR; BEGIN ulmIO.Read(ch); IF ~ulmIO.Done THEN c := EOF ELSE c := ch END; RETURN c END getc;

PROCEDURE putc*(c: CHAR); BEGIN ulmIO.Write(c) END putc;

END Prims.

MODULE Filters; IMPORT Prims;

PROCEDURE copy*; VAR c: CHAR; BEGIN WHILE (Prims.getc(c) # Prims.EOF) DO Prims.putc(c) END END copy;

END Filters.

MODULE copy; IMPORT Filters; BEGIN Filters.copy END copy.

These were compiled with the following commands, assuming separate files for each module:

voc Prims.mod; voc Filters.mod; voc -m copy.mod

This is on Fedora 24 with GCC 6.1.1.

Is there something I'm doing wrong?

Oddly, a more classic copytext works, as it is essentially the same program:

MODULE copytext; IMPORT ulmIO; VAR ch: CHAR;

BEGIN ulmIO.Read(ch); WHILE ulmIO.Done DO ulmIO.Write(ch); ulmIO.Read(ch); END END copytext.

[deevans]

I take that back: the copytext module compiled, but did not work correctly:

% ./copytext hello, world % llo, world -bash: llo,: command not found

This almost looks like a problem with the ulmIO library. I wonder if rewriting the above with a different library (oo2c?) might change the result.

[norayr]

try more classical approach:

MODULE hello;
  IMPORT Oberon, Texts;
  VAR W: Texts.Writer;
BEGIN
  Texts.OpenWriter(W);
  Texts.WriteString(W, "Hello."); Texts.WriteLn(W);
  Texts.Append(Oberon.Log, W.buf)
END hello.

or Console module

MODULE hello;
  IMPORT Console;
BEGIN
  Console.String("Hello."); Console.Ln;
END hello.

will it work?

[norayr]

also, i did not understand, do you have troubles compiling it?

then may be

voc -s Prims.mod Filters.mod copy.mod -m

will work better for you? I'll see your comments after several hours.

[norayr]

from what I see now, it stalls in endless loop in Filters.copy.

[norayr]

I can compile it.

[deevans]

will work better for you?

Yes, that works for compiling, but the Ulm library seems broken.

However, if I want to build several programs, does that mean I have to rebuild Prims and Filters each time? Shouldn't I be able to build once, then relink against the existing module?

[norayr]

no, it works for me, if it's the expected behaviour.

noch@debed /tmp $ ./copy 
aa
aa
oo
oo
bb
bb
cc
cc
dd
dd
^C
noch@debed /tmp $ 

[norayr]

Shouldn't I be able to build once, then relink against the existing module?

right now voc has no 'make' functionality. i don't know if it's better to write a separate make tool, use gnu make for that, or include such a feature in voc itself.

[norayr]

i am afraid right now you have to link by hand with gnu ld, in order to link with already existing object files.

[norayr]

I'll write here how makefile can look like, when reach home.

[norayr]

copytext.Mod also works for me:

 $ ./copytext 
aa
aa
oo
oo
bb
bb
cc
cc
dd
dd
^C
noch@debed /tmp $ 

[deevans]

% voc -s Prims.mod Filters.mod copy.mod -m Prims.mod compiling Prims. New symbol file. 505 chars. Filters.mod compiling Filters. New symbol file. 385 chars. copy.mod compiling copy. Main program. 259 chars. % ./copy hello, world % ello, world -bash: ello,: command not found

Oddly, this also creates a Prims and FIlters binary, which I don't need, but that seems an artifact of not being able to build the module for export.

[deevans]

I notice you're typing Ctrl-C. On Unix, Ctrl-d would be the appropriate way to end that session.

[deevans]

I take that back about the Prims and Filters binaries. That was a remnant of a previous command.

[deevans]

One final note, this particular test is on a 32-bit, not 64-bit, install of Fedora 24.

[norayr]

try this, i also included binaries. https://github.com/norayr/test_for_sinuhe it generates .o files, and leaves them. it's okay. do you mean object files by saying binaries? they are not executable files.

[norayr]

you can make clean them if you want.

[norayr]

i also will update the makefile so that it would be possible to not build every file again.

[norayr]

I am on x86_64. Can you try it on x86_64 and confirm the same results? May it be that UlmIO is broken for x86 or 32 bits?

[deevans]

I did not mean .o files. When I ran voc -ms Filters... it created a Filters executable. Again, never mind that. It is a remnant of an experiment, not the commands I posted here.

[deevans]

The make file you provide is very similar to the build script I use:

if test ! -d bin then mkdir bin fi

(echo ==== hello ====; voc -m hello.mod) (echo ==== copytext ====; voc -s Prims.mod Filters.mod copy.mod -m)

mv hello copy bin/

rm .o .c .h .sym

[deevans]

I have a 64-bit Slackware system. I'll test it on that when I get a chance.

[dcwbrown]

I think I see a problem in the ulm implementation in voc.

ulmIO.Mod ReadChar line 127 calls SYS.UNIXCALL, passing uninitialised LONGINT r0 as the second param, and then returns ReadChar success only if it UNIXCALL sets it to >0.

However ulmSYSTEM.Mod UNIXCALL does not change its second parameter. So the success test is based on uninitialised memory.

Now, I have changed code around here. But also the original code didn't appear to change the second parameter.

Will look further tomorrow (going out now).

-- Dave.

[dcwbrown]

I tested this fix with the example in your original post above David, and it's working for me ... Please let me know if it fixes it OK for you. Thanks!

[deevans]

Success, thank you.

[dcwbrown]

Excellent. Thanks for testing.