[m-rev.] for review [juliensf]: Avoid command line buffer limits

Julien Fischer juliensf at csse.unimelb.edu.au
Tue Oct 7 12:05:01 AEDT 2008

On Tue, 7 Oct 2008, Peter Ross wrote:

> On Tue, Oct 7, 2008 at 2:51 AM, Julien Fischer
> <juliensf at csse.unimelb.edu.au> wrote:
>> On Mon, 6 Oct 2008, Peter Ross wrote:
>>> Estimated hours taken: 4
>>> Branches: main
>>> Windows has a command line length limit, and I have started to hit
>>> it when using a MinGW version of the compiler, so use files to
>>> pass argument lists which are potentially very long to programs.
>>> compiler/compile_target_code.m:
>>>        Make all calls to mkinit use -f to pass the list
>>>        of files to process.
>>>        For linking use the @file syntax to pass all the
>>>        arguments to a command as when linking we
>>>        can have very long lists of object files.
>> Shouldn't you be checking that the linker actually accepts the @file
>> syntax, e.g. in the configure script.  GNU ld does, but I'm not sure
>> that the MacOS X one does -- I had a quick look at the man page but
>> couldn't see anything about it.  You have an XXX regarding this
>> above support_at_file - hardcoding it as `yes' is probably going
>> to break some systems.
> For the moment can I just add the bool option
> --restricted-command-line
> which will default to no, and if yes then uses @file syntax.
> There are some more changes needed because we use gcc to link and gcc
> then builds a very long command line internally to call collect2 which
> causes a failure.

That's fine by me.  Presumably the command line length limit on Windows
also affects the MSVC Mercury port?  And I would guess that Microsoft's
linker doesn't support @files?

mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au

More information about the reviews mailing list