From nobody Sun Dec 14 10:48:09 1997 X-From-Line: JoopvandeWege@mococo.nl Wed Dec 03 04:15:19 1997 Return-Path: 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 ; 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 ; Tue, 02 Dec 1997 14:06:15 +0100 Date: Tue, 02 Dec 1997 14:06:15 +0100 Message-ID: From: Joop van de Wege To: Gordon Matzigkeit 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 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: 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 ; 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 ; Fri, 12 Dec 1997 14:48:06 +0100 Date: Fri, 12 Dec 1997 14:48:06 +0100 Message-ID: From: Joop van de Wege To: Gordon Matzigkeit Cc: gg@ninemoons.com Subject: Re: AmigaOS libtool port In-Reply-To: <86zpm8qm6o.fsf@trick.profitpress.com> References: <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 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