"the input line is too long" bug caused by hpoussin's changes

[Colin Finck]

Hello everyone,

As most devs including me noticed this "the input line is too long" bug
after hpoussin's changes in r34187 to r34191, I did some research on it.
Unfortunately, it looks like it's unfixable if we keep on directly using ld
for linking (as introduced in these revisions) instead of calling the gcc
frontend.

First of all, the "length" of the cmd input line under Windows seems to be
highly affected by quotation marks. If you add a quotation mark to the
working linker command line before hpoussin's commits, it will also be
reported as being too long.
Previously, we didn't use quotation marks in the command line when linking
the binaries.
Now we have to do this because of the changed PROJECT_LFLAGS and
PROJECT_LPPFLAGS variables: They contain the path to i.e. libgcc and as this
path can contain spaces, it has to be put in quotation marks. Just passing
"libgcc.a" without a path doesn't work.
Passing "-lgcc" also doesn't work, because mingw32-ld only seems to search
for libraries in "mingw32/lib", not "lib/gcc/mingw32/4.1.3" as gcc
does.

I see no other solution than partly reverting hpoussin's changes and using
gcc for linking again.
If anyone sees another option, please comment or directly commit a fix.

Best regards,

Colin

[Yury Sidorov]

Hi,

make.exe on Windows has one strange feature (for Win9x 
compatibility?).
If command line in make file contains double quotes (") make.exe 
creates temp batch file and executes this command via batch file. In 
other cases a command is executed directly via CreateProcess.
IMO "the input line is too long" bug is caused by batch file 
limitations.
In most cases it can be fixed by replacing double quotes (") by single 
quotes (').

Yury Sidorov.

----- Original Message ----- 
From: "Colin Finck" <mail(a)colinfinck.de>
To: "'ReactOS Development List'" <ros-dev(a)reactos.org>
Sent: Monday, June 30, 2008 2:38 AM
Subject: [ros-dev] "the input line is too long" bug caused by 
hpoussin'schanges


>   Hello everyone,
>
>  As most devs including me noticed this "the input line is too long" 
>  bug
>  after hpoussin's changes in r34187 to r34191, I did some research on 
>  it.
>  Unfortunately, it looks like it's unfixable if we keep on directly 
>  using ld
>  for linking (as introduced in these revisions) instead of calling 
>  the gcc
>  frontend.
>
>  First of all, the "length" of the cmd input line under Windows seems 
>  to be
>  highly affected by quotation marks. If you add a quotation mark to 
>  the
>  working linker command line before hpoussin's commits, it will also 
>  be
>  reported as being too long.
>  Previously, we didn't use quotation marks in the command line when 
>  linking
>  the binaries.
>  Now we have to do this because of the changed PROJECT_LFLAGS and
>  PROJECT_LPPFLAGS variables: They contain the path to i.e. libgcc and 
>  as this
>  path can contain spaces, it has to be put in quotation marks. Just 
>  passing
>  "libgcc.a" without a path doesn't work.
>  Passing "-lgcc" also doesn't work, because mingw32-ld only seems to 
>  search
>  for libraries in "mingw32/lib", not "lib/gcc/mingw32/4.1.3" as gcc 
>  does.
>
>  I see no other solution than partly reverting hpoussin's changes and 
>  using
>  gcc for linking again.
>  If anyone sees another option, please comment or directly commit a 
>  fix.
>
>  Best regards,
>
>  Colin
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[KJK::Hyperion]

Colin Finck ha scritto:
>   Unfortunately, it looks like it's unfixable if we
> keep on directly using ld
>  for linking (as introduced in these revisions) instead of calling the gcc
>  frontend. 
ld supports response files, like Microsoft tools:

   @FILE                       Read options from FILE

(from ld --help)

>   Passing "-lgcc" also doesn't work,
> because mingw32-ld only seems to search
>  for libraries in "mingw32/lib", not "lib/gcc/mingw32/4.1.3" as gcc
> does. 
let's import libgcc then. It makes sense to me for our build environment
to be completely self-contained

[art yerkes]

On Mon, 30 Jun 2008 11:12:46 +0200
"KJK::Hyperion" <hackbunny(a)reactos.com> wrote:

>   Colin Finck ha scritto:
> >   Unfortunately, it looks like it's unfixable
> > if we keep on directly using ld
> >  for linking (as introduced in these revisions) instead of calling the gcc
> >  frontend. 
>  
>  ld supports response files, like Microsoft tools:
>  
>     @FILE                       Read options from FILE
>  
>  (from ld --help)
>  
> >   Passing "-lgcc" also doesn't work,
> > because mingw32-ld only seems to search
> >  for libraries in "mingw32/lib", not "lib/gcc/mingw32/4.1.3" as gcc
> > does. 
>  
>  let's import libgcc then. It makes sense to me for our build environment
>  to be completely self-contained 
I'd support that.  I think my position on importing dependencies has reversed
over the years, and I now favor including them.  Also, libgcc is small.
-- 
"Ask Bill why the string in function 9 is terminated by a dollar sign. Ask him,
because he can't answer. Only I know that".
- Gary Kildall

[Sarocet]

Colin Finck wrote:
>   Now we have to do this because of the changed
> PROJECT_LFLAGS and
>  PROJECT_LPPFLAGS variables: They contain the path to i.e. libgcc and as this
>  path can contain spaces, it has to be put in quotation marks. Just passing
>  "libgcc.a" without a path doesn't work.
>     
Othe people have already presented better solutions, just in case they 
somehow fail,  the usual hack^W fix
for workarounding spaces in Windows would be using GetShortPathName

Best regards