[comp.sys.amiga.tech] Compiling shared libraries with Aztec 5.0*d*

jep@mtiame.mtia.oz (Jesper Peterson) (12/14/90)

Has anyone tried to compile a shared library with Aztec 5.0d? Something
seems to have been broken between 5.0a and the later releases. I'd
like to hear other users experiences before putting in a bug report
to Manx.

Here is what happens:
I am trying to recompile an unmodifed rexxhost.library from Fish Disk 355.
The only changes are:
	Comment out use of AG_CloseLib. I don't have this in my alerts.h
		what should it be?
	Cast the second argument in the Alert() calls to long.

Compiling this with cc from 5.0a and ln and as from 5.0d and linking with
the 5.0d libraries creates a perfect rexxhost.library tested with "fancydemo".

Compiling with the 5.0d suite exclusively and running fancydemo crashes
with guru 4. finding the specific cause of the suspected compiler bug is
no picnic but it seems the library base pointer is NULL within the
library routines. eg:
	LibOpen()
	{
		struct RexxHostBase	*RexxHostBase;
	etc....

Trying to initialise any fields in the library base structure here will
dereference a garbage or NULL pointer.

Turning optimisation off causes a hung process instead of crash but other
processes are unaffected.
I tried using combinations of compiler flags including the new -r6 flag which
causes A6 to be saved/restored around "amicalls"

All of the above seems to be true for the sample res_lib on one of the
Aztec distribution disks as well (haven't spent much time on this one).

Can anyone confirm that this happens to them also? Possibly try recompiling
your favourite library?

Smart-ass remarks from Lattice users will be ignored.

Thanks for your time.

Jesper Peterson.
-- 
------------------------------------------------------------------------------
USEnet: jep@mtiame.mtia.oz.au            UUCP: ...!uunet!munnari!mtiame.oz!jep
[...] I had to leave out reality to keep the post clean and to the point.
            - jeremy@milton.u.washington.edu (Jeremy York) in rec.music.misc

kent@swrinde.nde.swri.edu (Kent D. Polk) (12/14/90)

In article <1990Dec14.030337.11636@mtiame.mtia.oz> jep@mtiame.mtia.oz (Jesper Peterson) writes:
>
>Has anyone tried to compile a shared library with Aztec 5.0d? Something
>seems to have been broken between 5.0a and the later releases. I'd
>like to hear other users experiences before putting in a bug report
>to Manx.

>Can anyone confirm that this happens to them also? Possibly try recompiling
>your favourite library?

1) m8.lib is broken (scanf(), etc.). Use an earlier library. I put in a
bug report about the m8.lib and they agreed: it is broken. (Why is
m8.lib broken on every other release? Grrrrr)

2) Something is dreadfully wrong when you use the small functions.h in
conjunction with the C= 2.0 includes. First of all, I got all sorts of include
errors, so I hacked on functions.h & even chunked it and used the supplied
prototypes in the C= includes. All my software broke. I get a rash of invalid 
memory accesses (according to cputrap) whenever I call a shared library function.

Note the similarity with my last posting about the gadget library? ...
When I mentioned this problem to Manx tech support, they said that
everything they compile works.

---------------------------------------------------------------------
I went back to the old Manx includes, functions.h, and the old m8.lib,
recompiled with the 5.0d cc and ln, and all of my software which
doesn't use new 2.0 stuff is working again. So:

- cc and ln seem to work,
- m8.lib doesn't
- only the old-style functions.h and the old include files seem to work properly,
since cc appears to generate improper code without them.

>Smart-ass remarks from Lattice users will be ignored.
Agreed :^)

---------------------------------------------------------------------
Q#1 to Manx will be:
How do you use the small functions.h and the 2.0 includes, since nothing I
try can even compile as distributed?

Q#2: Did you guys even TRY compiling any 2.0-specific source? (Ok, maybe I won't
ask that question.)

====================================================================
Kent Polk - Southwest Research Institute - kent@swrinde.nde.swri.edu
        "Well... can't you get a Novell card for your Cray ?"
====================================================================

swalton@solaria.csun.edu (Stephen Walton) (12/18/90)

In article <283@swrinde.nde.swri.edu>, kent@swrinde (Kent D. Polk) writes:
In article <1990Dec14.030337.11636@mtiame.mtia.oz> jep@mtiame.mtia.oz (Jesper Peterson) writes:

>Has anyone tried to compile a shared library with Aztec 5.0d? Something
>seems to have been broken between 5.0a and the later releases.

The sample resident library on Manx's own distribution disk doesn't work
properly with 5.0d. The basic problem is an incorrect optimization:  if
a library routine has no local data accesses, geta4() isn't called.
Unfortunately, a value for a4 which was never pushed gets popped.

Also, I think it is probably wise to always run 5.0d with the -r6 switch
to preserve register a6 across subroutine calls.  This is probably mandatory
in a library, since a6 generally contains the library base address.

>1) m8.lib is broken (scanf(), etc.). Use an earlier library.

Kent, can you post details?  I'm interested.  I got both the 5.0b and 5.0d
updates from BIX;  the former was a complete library, and the latter was
a small set of routines to use to update.

>When I mentioned this problem to Manx tech support, they said that
>everything they compile works.

Hmm...when did you last get through to Manx tech support?  Mike Spille,
their nominal support person, hasn't said anything in public on either
BIX or the Manx BBS since early October.

>I went back to the old Manx includes, functions.h, and the old m8.lib,
>recompiled with the 5.0d cc and ln, and all of my software which
>doesn't use new 2.0 stuff is working again.

Hmm...meaning you have library source and recompiled?  This could be the
save vs. non-save of register 6 mentioned above?

>Q#1 to Manx will be:
>How do you use the small functions.h and the 2.0 includes, since nothing I
>try can even compile as distributed?

It is a requirement that a prototype for a library function be in scope
before a #pragma libcall for that function can be done.  Is this a problem?

Steve
-------------------------------
Stephen Walton, Dept. of Physics & Astronomy, Cal State Univ. Northridge
   I am srw@csun.edu no matter WHAT the stupid From: line says!

kent@swrinde.nde.swri.edu (Kent D. Polk) (12/21/90)

In article <1990Dec17.211311.2714@csun.edu> swalton@solaria.csun.edu (Stephen Walton) writes:
>Also, I think it is probably wise to always run 5.0d with the -r6 switch
>to preserve register a6 across subroutine calls.  This is probably mandatory
>in a library, since a6 generally contains the library base address.

Sorry I've taken so long to respond. Had some processes running at a higher
priority than the system (me).

>>1) m8.lib is broken (scanf(), etc.). Use an earlier library.
>
>Kent, can you post details?  I'm interested.  I got both the 5.0b and 5.0d
>updates from BIX;  the former was a complete library, and the latter was
>a small set of routines to use to update.

The Manx guys stated that the distributed m8.lib was incorrectly
built.  If you have sources, you can rebuild it correctly. I believe he
stated that m8.lib hadn't changed, so... use the old. I first
downloaded from the Manx BBS & when fscanf() using the m8.lib crashed,
I mentioned this to Manx & subsequently ordered the disk. It didn't
work either :^(

>Hmm...when did you last get through to Manx tech support?  Mike Spille,
>their nominal support person, hasn't said anything in public on either
>BIX or the Manx BBS since early October.

Last Monday. I just phone. Can 't get a response any other way.

>>I went back to the old Manx includes, functions.h, and the old m8.lib,
>>recompiled with the 5.0d cc and ln, and all of my software which
>>doesn't use new 2.0 stuff is working again.
>
>Hmm...meaning you have library source and recompiled?  This could be the
>save vs. non-save of register 6 mentioned above?

No, I mean I compile my programs with the old includes and the large
functions, while using 5.0d cc and ln.  I can't determine any
difference using the -r6 switch.

>It is a requirement that a prototype for a library function be in scope
>before a #pragma libcall for that function can be done.  Is this a problem?

If I:
#include <stdio.h>
#include <math.h>
....
#include <functions.h> (small)
#include <[Amiga-specific 2.0 stuff]>

then I don't get include errors for math.h, etc. If I include (small) functions.h
first, and use the 2.0 includes math.h, etc. gives me include file errors.

Note that while some programs run when compiled this way, they at least do
a massive number of read violations any time an Amiga library function is called
or dealt with in any manner. This is why I believe that 5.0d cc is generating
incorrect code from the 2.0 prototype information.

Also, any programs which are linked to PLPlot crash very dramatically
on certain PLPlot screen draw operations. Note that when compiled using
the pre-2.0 includes, these same sources result in very nicely behaved
executables :^) Hmmm, I ought to try Postscript output & see if that
works correctly...

--------------------------------------------------------------
Has anyone tried out the gadtools.library in 2.0 and Manx 5.0d?

====================================================================
Kent Polk - Southwest Research Institute - kent@swrinde.nde.swri.edu
        "Well... can't you get a Novell card for your Cray ?"
====================================================================

bj@cbmvax.commodore.com (Brian Jackson) (12/22/90)

In article <421@swrinde.nde.swri.edu> kent@swrinde.nde.swri.edu (Kent D. Polk)
asks:

>Has anyone tried out the gadtools.library in 2.0 and Manx 5.0d?

Yep. Works works fine.  I'm using our own "generic" 2.0 includes,
linking with amiga.lib after c.lib and using my own 2.0 function
ptototypes that I make up from the autodocs as I need them. Same
with pragmas.

	lc [assorted compiler opts that I forget] program.c
	ln +q program.c -lc +l amiga.lib [debug.lib]
	
Again, I have not tried out many of the compiler's features nor all of the
libraries. What I _have_ done with it (a semi-major project) has been fine 
so far.

bj

>Kent Polk - Southwest Research Institute - kent@swrinde.nde.swri.edu

 -----------------------------------------------------------------------
 | Brian Jackson  Software Engineer, Commodore-Amiga Inc.  GEnie: B.J. |
 | bj@cbmvax.cbm.commodore.com    or  ...{uunet|rutgers}!cbmvax!bj     |
 | "Homer, I couldn't help overhear you warping Bart's mind."          |
 -----------------------------------------------------------------------

mndaily@ux.acs.umn.edu (--SeebS--) (12/23/90)

In article <1990Dec14.030337.11636@mtiame.mtia.oz> jep@mtiame.mtia.oz (Jesper Peterson) writes:
>Turning optimisation off causes a hung process instead of crash but other
>processes are unaffected.

Well, if you use -sn, 5.0d tends to *seriously* hose stack variables, including
pointers. Dunno about other "optimizations", but suffice it so say that none
of them appear to be optimal... Not sure if that helps...

>Jesper Peterson.

--SeebS--
-- 
mndaily is the Minnesota Daily, and does not speak for the U of M.
Linda Seebach does not speak for the Daily.
--SeebS-- does not speak for Linda.
Marcel Marceau speaks for no one.