RE: IBM OS/390 z/OS

[Howard Chu]

> -----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