Re: revised patch for glib compilation on cygwin with POSIX runtime

[Gary V . Vaughan]

Hi Tor,

On Thu, 15 Feb 2001, Tor Lillqvist wrote:
> Gary V. Vaughan writes:
>  > About four months ago is when it *was* working!  Unfortunately it has
>  > bitrotted a little since then.  I will work on fixing win32 DLL
>  > building in libtool as soon as I have my glib patch for wrapping
>  > libltdl ready.
>
> Actually the current CVS libtool does seem to be able to produce mingw
> DLLs. (Using cygwin make, shell etc, of course, with just the compiler
> and binutils being the mingw ones.) There are some issues, however...

Cool!

>   1) The search for dependent libraries, in libglib's case
>   -lwsock32. Should libtool also look for non-libtool libraries
>   (corresponding to static or import libraries, without .la files)?
>   Should it even also look for linked-to DLLs directly, as the newest
>   ld does?
>
>   Or, should libtool use 'pass_all' as deplibs_check_method for mingw,
>   and let the compiler/linker look for the libraries. The
>   compiler/linker is the final authority where to find the libs, anyway.

I think that this is two separate issues:  pass_all is used to note that a 
particular architecture can link static libraries into shared libraries, and 
controls whether libtool examines dependent libraries before linking them.  

If libtool doesn't already find non-libtool libraries on mingw, then that is 
a bug.  libtool works with non-libtool libraries on the other architectures 
to which it has been ported.  Patches gratefully accepted (I think this 
should be quite straight forward).

>   2) If we don't use pass_all, we need to convert PATH entries to the
>   corresponding short names using cygpath -w -s and cygpath -u, to
>   handle PATH entries with spaces in them, which is very common on
>   Win32. (For instance, my $PATH on cygwin contains
>       /cygpath/c/Program Files/Common Files/GNU
>   which needs to be turned into
>       /cygdrive/c/PROGRA~1/COMMON~1/GNU)
>   Alternatively, make libtool cope with the spaces, which probably is
> harder.

Agreed.  On all counts.

>   3) libtool should be able to use a pre-existing .def file
>   (hand-written or otherwise generated), in case one doesn't want to
>   export everything. OTOH, if some library can export everything on
>   Unix, doing it on Win32 probably won't cause any harm, either.

Seems fair enough to me.

>   4) libtool should be taught to generate MS import libs, too, if
>   lib.exe (or actually link.exe) is available.

Not so sure about this one.  But if you can come up with a clean patch that 
doesn't perturb any of the other ports, I'd certainly be happy to evaluate it.

>   5) Are .la files really useful for mingw-compiled DLLs, the users of
>   which might as well be using MSVC? They contain hardcoded path to the
>   directory for the installed DLL, but we *do not* want to fix that at
>   build time. Don't produce that line to the .la file, and don't look
>   for it?
>
>   Contrary to Unix, on Win32 I imagine that the scenario will/should
>   be that a *user* of a library just downloads a pre-built package
>   with the DLLs, headers and import libs and unzips them somwehere in
>   a directory prefix of his own choice. He is not interested in
>   rebuilding that library himself, nor does he want to install the
>   import libs and headers in some fixed location decided by the person
>   who built the package.

Yup.  However this is a very basic assumption in the way libtool works.  It 
might be tough to teach libtool to work otherwise.

> What do you think about these? (Yes, I am volunteering to implement
> some of the new features if necessary.)

Great!  There are some submission guidelines on the libtool homepage, and we 
might need a copyright assignment if your changes are moderately large.

Cheers,
        Gary.
-- 
  ___              _   ___   __              _         mailto: address@hidden
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       address@hidden
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                  gpg public key:
http://www.oranda.demon.co.uk           http://www.oranda.demon.co.uk/key.asc