mail/amiga

From nobody Sun Dec 14 10:48:09 1997
X-From-Line: JoopvandeWege@mococo.nl Wed Dec 03 04:15:19 1997
Return-Path: <JoopvandeWege@mococo.nl>
Delivered-To: gord@trick.profitpress.com
Received: (qmail 1795 invoked from network); 3 Dec 1997 04:15:16 -0000
Received: from localhost (HELO bambam.m-tech.ab.ca) (127.0.0.1)
  by localhost with SMTP; 3 Dec 1997 04:15:16 -0000
Received: from mcc-server.mococo.nl (mail.mococo.nl [195.193.4.2]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with SMTP id GAA28567 for <gord@m-tech.ab.ca>; Tue, 2 Dec 1997 06:06:47 -0700
Received: from laptop.mococo.nl (unverified [195.193.4.9]) by mcc-server.mococo.nl
 (EMWAC SMTPRS 0.83) with SMTP id <B0000011089@mcc-server.mococo.nl>;
 Tue, 02 Dec 1997 14:06:15 +0100
Date: Tue, 02 Dec 1997 14:06:15 +0100
Message-ID: <B0000011089@mcc-server.mococo.nl>
From: Joop van de Wege <JoopvandeWege@mococo.nl>
To: Gordon Matzigkeit <gord@m-tech.ab.ca>
Subject: Re: AmigaOS libtool port
In-Reply-To: <86oh339y7g.fsf@trick.profitpress.com>
References: <86oh339y7g.fsf@trick.profitpress.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver 1.23
Xref: trick.profitpress.com mail.libtool:816
Lines: 177
X-Gnus-Article-Number: 1   Mon Nov  2 17:16:02 1998



On 29 Nov 1997 14:39:31 -0700
Gordon Matzigkeit <gord@m-tech.ab.ca> wrote:

> Hi!
> 
> libtool-1.0g contains some preliminary AmigaOS support.  It is a
> little different than the patches you sent me, simply because I
> modified libtool slightly so that it would better accomodate your
> changes.
> 
> Here are what I consider to be some unresolved issues:
> 
> * I have attempted to automatically generate $objdir/a2ixlibrary.data,
> just as the OS/2 port does with $objdir/$libname.def.  It currently
> looks like this:
> 
> #define NAME $libname
> #define LIBRARY_ID 1
> #define VERSION $major
> #define REVISION $revision
> 
> So, for libhello.la in the libtool distribution, this would make an
> a2ixlibrary.data that looks like:
> 
> #define NAME libhello
> #define LIBRARY_ID 1
> #define VERSION 2
> #define REVISION 12
> 
> Is that alright?  My concerns are for the NAME definition, and the
> LIBRARY_ID, as I don't know what is valid, or what they are used
> for.
I have done this also but removed it because there are indeed two
problem. The NAME should be 'hello' but this can be solved but the
second issue is not so easy. LIBRARY_ID is a uniquely assign number
which needs to be different for each .ixlibrary build. The developer of
the ixlibrary is maintaining a database of which numbers are assign to
which library. Everything below 10 can be used for locally build
libraries, thats why I used 1.
So it is specific to the Amiga but it looks like overkill to me to
include the whole list into Libtool (about 50 entries right now).

> 
> * What does `assign libs: SOMEDIR [add|remove]' do, exactly?  Is it
> something like `ldconfig'?  If so, then we should do something cleaner
> than in your current patch: it doesn't belong in archive_cmds or
> finish_cmds, it belongs in the generated executable wrapper.
Yes, it does something like ldconfig. I followed that thread about it
and its very similar but also has some differences.
LIBS: is a logical directory where all libraries are, but that doesn't
mean that they reside physically in the same directory on disk.
It is a way of telling the OS where to look when a program requests a
library, something along these lines:
main()
{
	GfxBase=OpenLibrary("graphics.library",37L);
	HelloBase=OpenLibrary("libhello.ixlibrary",3L);
}

Graphics.library is in ROM and will just have its open count incremented
but nothing else will happen. libhello.ixlibrary is loaded from disk if
it isn't already in memory, but one needs to tell the system where to
load it from. It will look in SYS:libs (another logical device (normally
the boot partition ~= /usr ) containing a libs directory) but it is
possible to add directories to this logical assignment with 'assign',
like this:
assign SOMEDIR LIBS: add
or remove them like this:
assign SOMEDIR LIBS: remove
SOMEDIR is composed of DRIVE+DIRECTORY (absolute) or DIRECTORY
(relative) from where the assign is executed.
The reason I used the assignment was because 'make check' didn't work
correctly because libhello.ixlibrary is generated in .libs which is not
where 'hell' is started from. The system looks in the current directory
for .libraries but I'm not sure about .ixlibraries. The alternative was
to install them first before 'make check'. Bad idea.
The assignment is not placed into a config file or so. The next reboot
will destroy it, no ld.so.conf.

Probably you're now more confused then ever :)


> * I suspect you don't know what I mean by `hardcoding' a library
> directory, so I've interpreted your patch, and come up with hardcode_*
> settings that I believe will work.  We need to test that, during the
> next release.
I have already merged most things into lt-1.0h but I'm short on freetime
this week. I hope to have a couple of hours but it could be that I can
do only some work during the weekend.


> * Could you please tell me more about the AmigaOS requirements?  Some
> of your patch is impossible for me to decipher, because I have no idea
> what you want to accomplish, and I don't think you're taking full
> advantage of libtool's internal conventions.
> 
> In plain language, what are the answers to the following questions:
> 
> * What exactly are `$libname_ixlibrary.a', `$libname.ixlibrary', and
> `$libname.a'?  Is `$libname.a' the same file and installed in the same
> place when building static libraries?
Just in case I don't manage to make this clear. Have a look at the
readme of the following archive (and maybe the rest of it aswell:
ftp://ftp.ninemoons.com/pub/geekgadgets/971125/amiga-src/a2ixlibrary-2.0-src.tgz
(35Kb)

Dynamic libraries on the Amiga (in short)
first compile all object with the following additional CFLAGS:
-resident32 -malways-restore-a4 (these are the safest, -resident and
-m...restore.. can also be use but then certain limitations and
restrictions are  imposed)
AR and RANLIB these into libNAME.a (-->$libname.a)
run a2ixlibrary on libNAME.a --> $libname_ixlibrary.a and $libname.ixlibrary
where _ixlibrary.a contains stubs and .ixlibrary contains the real code.
(NAME.h and NAME.x are also generated and automatically installed by
a2ixlibrary and are used by collect2)
libNAME.a can be discarded after running a2ixlibrary.
libNAME_ixlibrary.a gets installed in /usr/lib together with all the
other linker libraries.
libNAME.ixlibrary should be installed somewhere in a directory belonging
to LIBS: There is a subdirectory in /gg where the gnu-tools are
installed called sys/libs which should be used for this, prevents
cluttering the main libs directories.

Static libraries on the Amiga:
compile all objects with the CFLAGS of your choice
AR and RANLIB these into libNAME.a
install in /usr/lib
done.

> 
> * How are each of them generated?
> 
> * Where do they need to be installed?
Answered above, I hope.
> 
> * `shlibpath_var' is the name of the runtime library search path
> environment variable.  On Linux, it is `LD_LIBRARY_PATH'.  So, if you
> install libhello.so in /home/gord/lib, binaries won't be able to
> execute unless you set `LD_LIBRARY_PATH=/home/gord/lib' before running
> them.  Is there an equivalent variable under AmigaOS?
Assign LIBS: home:gord/lib add
Nope, ':' is NOT a typo. The root directory is ':' on the amiga and 
cd / means move up one level, cd : means move to root.
There is a unix emulation library, ixemul.library, which handles things
like cd .. and cd / when one is using programs linked against it.
Thats why almost, if not all gnu tools are available for the Amiga and
they also work like on Unix. These leads to difficulties when mixing
'native' Amiga programs and ixemul.library linked ones. The path
differences are most prominent.

Somewhere in my patches I use a native program 'assign' inside ksh.
Further I have the gnu-tools installed under the 'gg' directory and
reference them in ksh using /gg.
Libtool libraries end up in /gg/lib (libNAME_ixlibrary.a, libNAME.a) and
the dynamic library ends up in /gg/sys/libs (libNAME.ixlibrary)
The system finds these because of the following statement:
assign LIBS: gg:sys/libs add
But some people like to specify --prefix=/local when configuring
packages and they also want the dynamic library to appear under
/local/sys/libs and thats why I have the sed substitution in postinstall_cmds
(?). Those people are responsible that they have an assignment that
tells the system to look into the proper directory for .ixlibraries.

> Thanks!
No thanks, hope this clears up a lot of things. If not, ask me and I'll
try to clarify things.

Joop

----
Joop van de Wege (JoopvandeWege@mail.mococo.nl)
Mobile Computing Consultants
+31 (0) 318 553292

From nobody Sun Dec 14 10:48:13 1997
X-From-Line: JoopvandeWege@mococo.nl Sat Dec 13 03:05:34 1997
Return-Path: <JoopvandeWege@mococo.nl>
Delivered-To: gord@trick.profitpress.com
Received: (qmail 11049 invoked from network); 13 Dec 1997 03:05:32 -0000
Received: from localhost (HELO bambam.m-tech.ab.ca) (127.0.0.1)
  by localhost with SMTP; 13 Dec 1997 03:05:32 -0000
Received: from mcc-server.mococo.nl (mail.mococo.nl [195.193.4.2]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with SMTP id GAA11738 for <gord@m-tech.ab.ca>; Fri, 12 Dec 1997 06:47:52 -0700
Received: from laptop.mococo.nl (unverified [195.193.4.9]) by mcc-server.mococo.nl
 (EMWAC SMTPRS 0.83) with SMTP id <B0000011567@mcc-server.mococo.nl>;
 Fri, 12 Dec 1997 14:48:06 +0100
Date: Fri, 12 Dec 1997 14:48:06 +0100
Message-ID: <B0000011567@mcc-server.mococo.nl>
From: Joop van de Wege <JoopvandeWege@mococo.nl>
To: Gordon Matzigkeit <gord@m-tech.ab.ca>
Cc: gg@ninemoons.com
Subject: Re: AmigaOS libtool port
In-Reply-To: <86zpm8qm6o.fsf@trick.profitpress.com>
References: <B0000011089@mcc-server.mococo.nl> <86zpm8qm6o.fsf@trick.profitpress.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver 1.23
Xref: trick.profitpress.com mail.libtool:868
Lines: 111
X-Gnus-Article-Number: 2   Mon Nov  2 17:16:02 1998



On 11 Dec 1997 02:11:11 -0700
Gordon Matzigkeit <gord@m-tech.ab.ca> wrote:

> Hi!
> 
> >>>>> Joop van de Wege writes:
> 
>  >> Is that alright?  My concerns are for the NAME definition, and the
>  >> LIBRARY_ID, as I don't know what is valid, or what they are used
>  >> for.
> 
>  JvdW> I have done this also but removed it because there are indeed
>  JvdW> two problem. The NAME should be 'hello' but this can be solved
>  JvdW> but the second issue is not so easy. LIBRARY_ID is a uniquely
>  JvdW> assign number which needs to be different for each .ixlibrary
>  JvdW> build. The developer of the ixlibrary is maintaining a database
>  JvdW> of which numbers are assign to which library. Everything below
>  JvdW> 10 can be used for locally build libraries, thats why I used 1.
>  JvdW> So it is specific to the Amiga but it looks like overkill to me
>  JvdW> to include the whole list into Libtool (about 50 entries right
>  JvdW> now).
> 
> I suggest that the ixlibrary maintainer come up with a hash function
> that will map library names to numbers, so that if the LIBRARY_ID is
> not specified, it will be automatically generated by this hash
> function.
> 
> If two hashed library codes conflict, then libtool will still have to
> provide a way for maintainers to specify the correct LIBRARY_ID.
> 
> However, the current design of ixlibrary is not good because it means
> installing two libtool libraries will *always* cause a conflict,
> unless both package maintainers cared enough to be assigned a
> LIBRARY_ID.
The current situation is that all packages on ftp.ninemoons.com are
under CVS (amiga specific code added) and that for each snapshot Amiga
specific patches are applied to the baseline sources, whether they
originate from FSF or someplace else doesn't matter.
This means that for each library which can be turned into a *.ixlibrary
an a2ixlibrary.data{.in} exists.

It would be nice if the LIBRARY_ID's could be maintained in one location
and that location being libtool. On the other hand lots of people might
have objections against such a special treatment to the Amiga.
It might mean a lot of code just to support on platform.

> 
> When I accepted the patches for the AmigaOS shared libraries, I was
> not aware of this limitation.  You are basically telling me that there
> is no way for me to automatically generate correct shared libraries on
> AmigaOS.
No, unless I start digging into the a2ixlibrary source to see if I can
find a way to automate things. The problem is in the fact that the ID is
hardcoded into the library (like paths on some other platforms) and the
ID must be unique, making distribution of binaries almost impossible.


> Unless this issue can be resolved, I think I should remove the AmigaOS
> support, because it will cause more problems than it solves.  Shared
> libraries, IMO, are not worth the time and effort of every maintainer
> having to register with the AmigaOS ixlibrary project.
Libtool can still be a package useful for the Amiga but it will get the
same treatment as all others, keep a baseline and apply patches when
needed.

> 
>  JvdW> Somewhere in my patches I use a native program 'assign' inside
>  JvdW> ksh.  Further I have the gnu-tools installed under the 'gg'
>  JvdW> directory and reference them in ksh using /gg.  Libtool
>  JvdW> libraries end up in /gg/lib (libNAME_ixlibrary.a, libNAME.a)
>  JvdW> and the dynamic library ends up in /gg/sys/libs
>  JvdW> (libNAME.ixlibrary)
> 
>  JvdW> But some
>  JvdW> people like to specify --prefix=/local when configuring
>  JvdW> packages and they also want the dynamic library to appear under
>  JvdW> /local/sys/libs and thats why I have the sed substitution in
>  JvdW> postinstall_cmds (?). Those people are responsible that they
>  JvdW> have an assignment that tells the system to look into the
>  JvdW> proper directory for .ixlibraries.
> 
> This is a problem.  Why do dynamic libraries have to go into a
> separate directory?
This way it doesn't clutter a directory where no executables belong in.
It is also historical and because the Amiga isn't a real Unix machine.
It uses ixemul.library for its unix emulation, something like cygwin32.dll

> sys/libs sounds like a violation of the GNU directory conventions,
> which is a problem.  It means that even GNU packages will not install
> binaries according to their own conventions. :(
> 
> It seems to me to be much better if we just put everything into
> libdir.  Can this work?
Yes, it can.

I'll forward this reply to some relevant Amiga mailinglists to see if
people are willing to change things.

Joop

PS:
Please comment on this, Fred, Hans?

----

Joop van de Wege (JoopvandeWege@mail.mococo.nl)
Mobile Computing Consultants
+31 (0) 318 553292