Re: Wrappers don't transform @file syntax

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Wed, Jan 15, 2020 at 10:51:42PM +0900, PHO wrote:
> 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.

Please do not use $ORIGIN. It's a constant source of issues.

Joerg