RE: IBM OS/390 z/OS

[Howard Chu]

Hi again. This is a followon to my earlier post, giving DLL support for IBM
OS/390 (z/OS). I realize that this patch isn't going to go anywhere, I'm just
posting it here in the hopes that it will be archived and potentially be
useful for the next poor sap who needs it.

This patch is against a libtool-1.4.3 script. I tried to do the right thing
re: adding tests and such to libtool.m4 and ltdl.m4 in libtool 1.5 but trying
to get a working suite of autotools on z/OS has proved to be more effort than
I have the patience for, so this is what works for me.

When used in conjunction with my previous post of patches to libltdl, you get
pretty much complete dynamic loading functionality on z/OS. It's good enough
to build OpenLDAP with shared libraries and dynamically loaded backends,
anyway, which is the problem I had to solve here...

To answer my questions from June -
  (1) I added commands to $archive_cmds to copy the libfoo.x side deck to the
proper place.
  (2) I listed libfoo.x last in $library_names_spec, so libtool will use the
side deck as it must when linking an object with a shared library.

I also ignored the versioning question, as well as not requiring a "lib"
prefix for DLLs.

The script doesn't stand alone. It also requires the compiler to be invoked
with specific flags, which I omit from the libtool script because I use them
everywhere else in my build environment. That is, rather than run "c89"
directly, I in voke the compiler via a "ccx" script which contains:

        #! /bin/sh
        exec
/bin/c89 -Wc,xplink,nocsect,exportall,langlvl\(EXTENDED\) -D_ALL_SOURCE -Wl,x
plink $*

It's important that all code be generated with the XPLINK option; mixing
XPLINK with non-XPLINK will at least slow performance, and at most fail
miserably. So I make sure to set CC=ccx before building anything, whether it
uses libtool or not. (OpenSSL, for example, doesn't use libtool, but I need
all of these libraries to work with each other.)

As always, the full description of how to build is on the OpenLDAP
FAQ-o-Matic
http://www.openldap.org/faq/index.cgi?file=719

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden
>  Behalf Of
> Howard Chu
> Sent: Friday, June 13, 2003 12:07 AM
> To: 'Robert Boehne'
> Cc: address@hidden
> Subject: RE: IBM OS/390 z/OS
>
>
> > -----Original Message-----
> > From: Robert Boehne [mailto:address@hidden
>
> > Howard,
> >
> > Libtool 1.4.3 is quite different than 1.5 and the current
> > CVS.  Please rework this
> > patch to apply against CVS and let us know how a testsuite run goes.
> >
> > Thanks,
> >
> > Robert
>
> That's turning out to be quite a lot more effort. I could use
> some advice...
>
> When given the -Wl,DLL flag to create a shared object, the
> compiler/linker
> creates a "definition side deck" file which is the moral
> equivalent of a
> Windows import library. I haven't looked at the Windows support, but
> presumably it can be handled in the same way. In particular,
> you cannot link
> a shared library using "-lfoo", you must use the definition
> side deck. The
> file is always created in the current working directory,
> using the target
> object file name, with a suffix of ".x".
>
> Libtool throws its stuff into a .libs subdirectory by
> default. So I need help
> with this:
>   1) is there a macro or somesuch that tells libtool that one of its
> necessary files is in the CWD, and to move it into .libs?
> (I.e., move the
> generated .x file into the .libs directory for me.)
>   2) how do I tell libtool that in order to link against
> libfoo.dll I really
> have to use the fully qualified path to libfoo.x instead?
>
> By the way, config.guess says this platform is
> "i370-ibm-openedition" and so
> $host_os is set to "openedition" which doesn't seem all that
> distinctive to
> me. I'm using that for all the platform-specific case
> statements, but perhaps
> config.guess could be changed to give something clearer...
>
> Also, in looking at other DLLs supplied with the OS, I don't see any
> convention for appending version numbers to the suffixes. The
> DLLs also lack
> a "lib" prefix. Any thoughts on whether to try to impose a
> version name
> scheme on this?
>
> > Howard Chu wrote:
> >
> > > This is a diff against libltdl from libtool 1.4.3 to
> > support dynamic loading
> > > on IBM OS/390. It's obviously of limited use, as I haven't
> > got configure
> > > detecting all the things it needs to know yet. I'm
> > currently using this with
> > > a manually edited libtool script to generate shared
> > libraries. (blech...)
> > > Since I saw the patches/discussion go by about controlling
> > which languages
> > > libtool detects, I figure it won't be too long before we
> > can get the C
> > > compiler fully supported in this environment, while
> > ignoring C++, Fortran,
> > > etc...
>
>   -- Howard Chu
>   Chief Architect, Symas Corp.       Director, Highland Sun
>   http://www.symas.com               http://highlandsun.com/hyc
>   Symas: Premier OpenSource Development and Support
>
>
>
> _______________________________________________
> Libtool-patches mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/libtool-patches

libdif.txt
Description: Text document