Re: Wrappers don't transform @file syntax

[PHO <pho%cielonegro.org@localhost>]

On 2020-01-15 21:29, Joerg Sonnenberger wrote:
> On Wed, Jan 15, 2020 at 09:56:07AM +0900, PHO wrote:
>> On 2020-01-15 02:01, Joerg Sonnenberger wrote:
>>> On Fri, Jan 10, 2020 at 09:43:49PM +0900, PHO wrote:
>>>> I stumbled upon a problem where wrappers don't transform @file syntax
>>>> accepted by tools like gcc, ld, and ar. Missing dependencies went
>>>> unnoticed because GHC used it to link libraries and executables:
>>>
>>> More inconsistencies between old and new wrappers. Frankly, I would
>>> prefer to bail out on @ instead, especially since it is way to easy to
>>> hide it in various places.
>>
>> Well... bail out? Do you mean you think cwrappers shouldn't interpret
>> @file? If so I will patch GHC so that it won't use it, instead of
>> changing the behavior of cwrappers.
> 
> Yeah, I'm more inclined to not do anything about them. There is one
> valid use case for @file where expansion would seriously break things.
> It's a known workaround to argv size limits when dealing with many
> object files. The bigger question would be why GHC is using it in first
> place, especially for anything but list of object files.

Alright. It's apparently because Windows has significantly low limit on
the size of argv, compared to usual POSIX systems.

As a side note, I already tried patching GHC not to use it but it didn't
work because GHC itself needed to have several rpaths relative to
$ORIGIN. Those rpaths are removed during the "cleanup" phase of
cwrappers, regardless of whether R:$ORIGIN:$ORIGIN exists, so I decided
to just let it use @file :D

Thanks for your input anyway.