libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get install


From: Dave Korn
Subject: Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.
Date: Mon, 17 Aug 2009 00:57:58 +0100
User-agent: Thunderbird 2.0.0.17 (Windows/20080914)

Roumen Petrov wrote:
> Dave Korn wrote:
>> Roumen Petrov wrote:
>>> I think that processing of '..' in a path is too naive. It will fail to
>>> produce correct results on filesystems with links.
>>
>>   this function implements 'abspath', not 'realpath',
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> and given that we can't assume any of the directories even exist when
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> we have to do this at link time, before installation, 
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> You may test you function with following example:

  No thanks, I don't think I'll bother.  I understand perfectly well what the
problem is with symlinks, but what you seem to overlook is that there is no
possible way of knowing whether any path component will be a real directory or
a symlink *before it is even created*.

> Sure.
> Currently for gcc 4.4.0 (target i486-mingw32 build ${ARCH}-pc-linux) non
> prefixed binaries from <PREFIX>/<TARGET>/bin don't work for me. As
> example gcc can't find cc1. May be is same issue.

  Yes, like I told you, the whole of GNU autotools and configure and
everything assumes that you won't be messing around with symlinks in your
$prefix structure like this.  What you are doing is unsupported.

> To resolve issue I use following additional links:
> # cd $PREFIX
> # l ./i486-mingw32/lib/gcc
> lrwxrwxrwx 1 XXXX ./i486-mingw32/lib/gcc -> ../../lib/gcc/
> # l ./i486-mingw32/libexec
> lrwxrwxrwx 1 XXXX ./i486-mingw32/libexec -> ../libexec/
> 
> 
>>   So I don't think this is likely to cause any problem except in really
>> bizarre corner-cases where someone's already trying something dubious,
>> is it?
> 
> So to me function like XX_abspath has to work.

  Since what you want is impossible in the general case, I'm not going to put
any effort into making your system work.  If you want to implement this
entirely new feature, you will have to patch autoconf, automake, gcc, libtool,
and everything else yourself.

    cheers,
      DaveK





reply via email to

[Prev in Thread] Current Thread [Next in Thread]