Path: news.daimi.aau.dk!poe
From: Peter Andersen <Peter.Andersen@mjolner.dk>
Newsgroups: comp.lang.beta
Subject: Re: problems with fragment system / compiler
Date: 31 May 1995 08:47:17 GMT
Organization: DAIMI, Computer Science Dept. at Aarhus University
Lines: 111
Approved: mailtonews@daimi.aau.dk
Distribution: world
Message-ID: <3qhael$no9@belfort.daimi.aau.dk>
NNTP-Posting-Host: daimi.daimi.aau.dk

Thomas Rosanski writes:
> 
> Q: Why is it (or am I) not possible to compile a library fragment that has
>    seperate fragments for the interface and the implementation?
> 
> e.g.: Take the example from MIA 90-02(1.3) August 1994, page 15 and 16:
> (shortened)
> 
> "Introduce the following SLOTs: (filename 'stack.bet')
>   ORIGIN '~beta/basiclib/current/betaenv';
>   BODY 'stackImp'
>   --- Lib: attributes ---
>   stack:
>     (# element:, Object;
>        private: @<<SLOT private: descriptor>>;
>        push: (# (* some code with another slot *) #);
>        (* more attributes *)
>      #)
> 
> Create a new fragment file 'stackImp.bet':
>   ORIGIN 'stack';
>   --- private: descriptor ---
>   (# A: ,[100] ^element;
>      top: @intger;
>   #)
>   (* some more fragment descriptions *)    "
> 
> I am useing the Mjolner Beta System 5.0(2) for Linux(Intel 386/486) and
> I can not compile the library fragment 'stack.bet'. After typeing
> 'beta stack' I get the following message:
> 
> Mjolner BETA System version 5.0(2) for Linux(Intel 386/486)
> Target machine type linux
> Building dependency graph for: 'stack' ...
> Parsing: 'stack'
> Parsing: 'stackImp'
> Translating fragments ...
> Open: '~beta/basiclib/current/betaenv'
> Basic BETA environment: '~beta/basiclib/current/betaenv'
> Bind fragments in: 'stack'!Checking!Code generation.
> assembling /home/linux/beta/linux/stackImp..s
> assembling /home/linux/beta/linux/stack..s
> Linking
> /usr/local/beta-3.0/basiclib/current/linux/betaenv.o: Undefined symbol  >>
> >> T1PROGRAM referenced from text segment
> 
> 
> ">>" means that this is one line.
> 
> But I can compile an ordinary program fragment useing the library, e.g.:
>   ORIGIN '~beta/basiclib/current/betaenv';
>   INCLUDE 'stack'
>   -- program: descriptor --
>   (# myStack: stack (# element:: IntegerObject #);
>      A: @myStack
>      do (* some code *)
>    #)
> 
> As far as I understood, the fragment system should include the facility
> to compile fragments seperatly. So what did I do wrong?
> 
> -- 
> Thomas Rosanski               student at the University of Dortmund, Germany
>                         Internet: rosans00@marvin.informatik.uni-dortmund.de
> 
> PS: Don't hesitate to contact me...
> 		...if you are programming BETA or SML as a novice
> 		...if you own an ATARI 8-bit micro
> 		...if you have a good-paid job for me
> 		...if you are a girl aged 18 to 22
> 		...if you can proof that 1+2^(2^100) is a prime number
> 		...if you just wanna talk with me
> 		...or for any other reason
> 
> 

From the BETA FAQ, version 1.6:

C11) Known errors in v5.0 of the compiler.
...
3. "T1PROGRAM undefined" reported by the linker

As explained in section 7.3 "Assembler and Linker Errors" in the
compiler reference manual [MIA 90-02], if an unbound SLOT of category
Descriptor or Dopart exist in your program, then this is currently not
reported by the compiler itself, but will be detected as an "Undefined
Entry" by the linker. Especially if you are new to BETA programming,
you may wonder why compiling this fragment (foolib.bet): 

    ORIGIN '~beta/basiclib/current/betaenv';
    -- LIB: attributes--
    foo: (# (* ... *) #);

with "beta foolib" causes the linker error "T1PROGRAM undefined". In
this case the reason is that the fragment is actually a library
fragment - it only declares attributes to be used by some program.
Specifically the PROGRAM descriptor SLOT defined in "betaenv" has not
been bound, and thus the error. 

The solution is quite simple: Just compile the program as "beta -c
foolib" instead. The next version of the BETA compiler will not
attempt to do the linking if the PROGRAM SLOT is not bound. 

If you think this is strange, compare to the equivalent situation in C
(foolib.c) 

    foo() { /* ... */ }

If you compile this file with e.g. "cc foolib.c", you will often get
the linker error that "_main" is not defined. The solution here is
like in BETA: "cc -c foolib.c"