Gcc/ld and long command lines (> 32k)

[Johan Holmberg]

Hi !

I tried to compile/link an application consisting of several hundred
C/C++ files. This gives quite a long command line when it is time
to link the application.

Windows seem to have a limit of 32k for the length of the command
line as given to to the system call 'CreateProcess'. I guess this is
a "hard" limit in Windows.

The length of my linker command line exceeds this 32k limit.

Is it possible to pass a list of filenames to ld
in some other way, to get around this limit ?

I know about the special "@filename" syntax in Cygwin, but there
seem to be two problems:

- it is no idea to give the special @filename argument to "gcc.exe",
since it is calling other exe-files and will have problems itself
to pass the file list on to these (ld, collect2, ...)

- I tried to specify "-Wl,@files.txt" to "gcc.exe", hoping that
"@files.txt" would be picked up by "ld.exe", but I got the error
message:
ld: @files.txt: No such file: No such file or directory

Is ld.exe not interpreting the special "@" like other
Cygwin programs ?


Am I missing some obvious way of doing what I want ?

/Johan Holmberg

[Larry Hall]

Post by Johan Holmberg
Hi !
I tried to compile/link an application consisting of several hundred
C/C++ files. This gives quite a long command line when it is time
to link the application.
Windows seem to have a limit of 32k for the length of the command
line as given to to the system call 'CreateProcess'. I guess this is
a "hard" limit in Windows.
The length of my linker command line exceeds this 32k limit.
Is it possible to pass a list of filenames to ld
in some other way, to get around this limit ?
since it is calling other exe-files and will have problems itself
to pass the file list on to these (ld, collect2, ...)
Cygwin programs ?
Am I missing some obvious way of doing what I want ?

Did you try this?

<http://cygwin.com/ml/cygwin/2004-03/msg01300.html>


--
Larry Hall http://www.rfk.com
RFK Partners, Inc. [phone] - RFK Office
838 Washington Street [phone] - FAX
Holliston, MA 01746

[Johan Holmberg]

Post by Christopher Faylor
...

Post by Peter A. Castro
The original post doesn't specify weither they are working inside
of or outside of a Cygwin environment, but from some of the

For some reason, I assumed they were running from make, where the

A short description of my enironment:

- the programs I'm building are C/C++ compilers

- I use GCC in Cygwin to get a "second opinion" from another compiler
than the one we use normally (Visual C++).

- I use Cons as my build tool (a Perl program).
I use ActiveState Perl (not Cygwin Perl).

So yes, I'm working "outside a Cygwin environment".

Post by Christopher Faylor
[...] Larry's pointer to another one of my messages should also
work around the problem by making cygwin use internal methods for
passing arguments.

I followed that link, and have tried to understand what "mount -X"
does. The option is mentioned in the "Cygwin User's Guide", but I
couldn't find all details about what the effect is.

Does it mean that Cygwin-binaries under such a mount-point pass
argc/argv to other Cygwin-binaries under the same mount-point via the
"internal method" allowing longer command lines than 32k ?
(can I find a description of this method somewhere ?)

Should I re-mount the bin-directory where "gcc.exe" is located with
the -X option ?

Several replies mentioned the possibility of making several
intermediate libraries. I'm well aware of that possibility.
But since I'm not interested in the "library functionality" of libraries,
any such partitioning seems artificial. I always want a *full linking*
where all object files are needed.

I guess I'll resort to that, but only if no other way
(like "mount -X") works for me.

/Johan Holmberg

[Christopher Faylor]

Post by Johan Holmberg
- the programs I'm building are C/C++ compilers
- I use GCC in Cygwin to get a "second opinion" from another compiler
than the one we use normally (Visual C++).
- I use Cons as my build tool (a Perl program).
I use ActiveState Perl (not Cygwin Perl).
So yes, I'm working "outside a Cygwin environment".

Ok, so, sorry, but I wasn't thinking clearly. The '-X' option to mount
only works when a cygwin programs which invoke another cygwin program.
If you have a normal windows program running a cygwin program, your only
option for a longer command line is (shudder) '@'.

cgf

[Peter A. Castro]

Post by Christopher Faylor

Post by Johan Holmberg
- the programs I'm building are C/C++ compilers
- I use GCC in Cygwin to get a "second opinion" from another compiler
than the one we use normally (Visual C++).
- I use Cons as my build tool (a Perl program).
I use ActiveState Perl (not Cygwin Perl).
So yes, I'm working "outside a Cygwin environment".

Ok, so, sorry, but I wasn't thinking clearly. The '-X' option to mount
only works when a cygwin programs which invoke another cygwin program.
If you have a normal windows program running a cygwin program, your only

Well, Chris, for better or worst, this "feature" does seem to work. I
did a quick test of this using an @file which is 81k long and it works!
You will need to remount both /usr/bin and /usr/lib with the "--system
--binary -X" options. Then put your list of objects into @file and run
gcc @file.
For the record, I still feel that a better practice is to do archiving of
object files and link with the library, but if this gets you going, this
time, more power to ya.

Post by Christopher Faylor
cgf

[Larry Hall]

Post by Peter A. Castro

Post by Christopher Faylor

Post by Johan Holmberg
- the programs I'm building are C/C++ compilers
- I use GCC in Cygwin to get a "second opinion" from another compiler
than the one we use normally (Visual C++).
- I use Cons as my build tool (a Perl program).
I use ActiveState Perl (not Cygwin Perl).
So yes, I'm working "outside a Cygwin environment".

Ok, so, sorry, but I wasn't thinking clearly. The '-X' option to mount
only works when a cygwin programs which invoke another cygwin program.
If you have a normal windows program running a cygwin program, your only

Well, Chris, for better or worst, this "feature" does seem to work. I
You will need to remount both /usr/bin and /usr/lib with the "--system
For the record, I still feel that a better practice is to do archiving of
object files and link with the library, but if this gets you going, this
time, more power to ya.

But wait. You're mixing advice (Chris's) it seems. He said @file would
be a solution if you were working outside of Cygwin shells and that
remounting with -X could be a solution if you were inside. So it sounds
like you tried both, and perhaps together, but it's unclear whether you
ran your tests from a Cygwin shell prompt, a Windows DOS prompt, or both.
Can you clarify what you tried and where?

Thanks,


--
Larry Hall http://www.rfk.com
RFK Partners, Inc. [phone] - RFK Office
838 Washington Street [phone] - FAX
Holliston, MA 01746

[Peter A. Castro]

Post by Larry Hall

Post by Peter A. Castro

Post by Christopher Faylor

Post by Johan Holmberg
- the programs I'm building are C/C++ compilers
- I use GCC in Cygwin to get a "second opinion" from another compiler
than the one we use normally (Visual C++).
- I use Cons as my build tool (a Perl program).
I use ActiveState Perl (not Cygwin Perl).
So yes, I'm working "outside a Cygwin environment".

Ok, so, sorry, but I wasn't thinking clearly. The '-X' option to mount
only works when a cygwin programs which invoke another cygwin program.
If you have a normal windows program running a cygwin program, your only

Well, Chris, for better or worst, this "feature" does seem to work. I
You will need to remount both /usr/bin and /usr/lib with the "--system
For the record, I still feel that a better practice is to do archiving of
object files and link with the library, but if this gets you going, this
time, more power to ya.

be a solution if you were working outside of Cygwin shells and that
remounting with -X could be a solution if you were inside. So it sounds
like you tried both, and perhaps together, but it's unclear whether you
ran your tests from a Cygwin shell prompt, a Windows DOS prompt, or both.
Can you clarify what you tried and where?

Hmmm... Ok, you are correct, I was ambiguous. To be clear:

I tried running gcc from a DOS Command Prompt, using the @file syntax and
having /usr/bin & /usr/lib mounted with "-X" and this worked. This is
the same way in which Johan would be running it, and so I kinda implied
this would work for him in the mode he currently works in. I didn't
bother doing this from within a Cygwin shell (bash, tcsh, zsh, etc)
because the @file syntax wouldn't work, and Johan specificically wanted
to be able to use this form.

Post by Larry Hall
Thanks,

[Johan Holmberg]

Post by Ross Ridge
You can try using an implicit linker script. Create a file, call it
INPUT(obj1.o obj2.o obj3.o)
INPUT(obj4.o, obj5.o, obj6.o)
INPUT(obj7.o)
gcc -o foo.exe obj1.o obj2.o ... obj7.o -lbar -lbaz
gcc -o foo.exe my-ld-script -lbar -lbaz
Ross Ridge

Many thanks !
This was just the kind of thing I was looking for.

By tweaking my build tool, it will be an easy thing to switch to this
kind of command line automatically when the command line gets too long
(and generating a linker script "on the fly").

I actually printed out the LD manual ("Using ld") yesterday.
But I missed the way "linker scripts" could be specified, when I first
looked through the text.

Just to test it, I will probably also try the @filename feature to
gcc.exe together with the "mount -X" to make gcc.exe communicate with
collect2/ld via the cygwin-specific way of passing arc/argv.

Thanks a lot for all the helpful answers.

/Johan Holmberg

[Peter A. Castro]

Post by Johan Holmberg
Hi !
I tried to compile/link an application consisting of several hundred
C/C++ files. This gives quite a long command line when it is time
to link the application.

A smarter, more traditional, approach would be to change your makefile to
archive object files after they are compiled into a static-link library
and then link against that. Or, as part of your linking step, manually
archive some or all object files (enough to satisfy the command line
length limit issue) into a temporary library, link with it, then remove
it.

Post by Johan Holmberg
Windows seem to have a limit of 32k for the length of the command
line as given to to the system call 'CreateProcess'. I guess this is
a "hard" limit in Windows.
The length of my linker command line exceeds this 32k limit.
Is it possible to pass a list of filenames to ld
in some other way, to get around this limit ?

The @filename syntax is used by MS's linker (Visual C++/Studio). To my
knowledge gcc's linker doesn't support this syntax. Neither 'ld --help'
nor 'info ld' seem to present any options which support this syntax. Try
my suggestion above.

Post by Johan Holmberg
since it is calling other exe-files and will have problems itself
to pass the file list on to these (ld, collect2, ...)
Cygwin programs ?
Am I missing some obvious way of doing what I want ?
/Johan Holmberg

[Christopher Faylor]

Post by Peter A. Castro
knowledge gcc's linker doesn't support this syntax.

The cygwin DLL supports it (implemented over my gagged and thrashing body)
but only at a non-cygwin-shell command prompt, e.g.,

c:\>gcc -o foo @foo.blah

works

but

bash$ gcc -o foo @foo.blah

doesn't.

I would highly recommend against using this construct, however. It's better
to use traditional unix methods for working around this problem. Cygwin isn't
the only unix-like system out there with a measly amount of space set aside for
the command line.

cgf

[Dave Korn]

-----Original Message-----
From: cygwin-owner On Behalf Of Christopher Faylor
Sent: 08 April 2004 18:21
C++/Studio). To my

Post by Peter A. Castro
knowledge gcc's linker doesn't support this syntax.

The cygwin DLL supports it (implemented over my gagged and
thrashing body)
but only at a non-cygwin-shell command prompt, e.g.,
works
but
doesn't.

Yow. The *DLL* expands that? Eww. I understand why you had to be tied
down, that's soooo the wrong place for it. WRS implemented it into their
versions of the binutils, which seems like the right place for it. Maybe
getopts should understand it. Perhaps even bash. But putting it in the
DLL? <gag!>

Can I at least escape the @ sign if I really do want to pass "@word" as an
argv entry? I like to use parameters with an @ char prefixing them in my
own tools, and I don't want the parameter to suddenly be replaced by the
contents of a file that happens to have the same name....!

cheers,
DaveK

[Christopher Faylor]

Post by Dave Korn

-----Original Message-----
From: cygwin-owner On Behalf Of Christopher Faylor
Sent: 08 April 2004 18:21
C++/Studio). To my

Post by Peter A. Castro
knowledge gcc's linker doesn't support this syntax.

The cygwin DLL supports it (implemented over my gagged and
thrashing body)
but only at a non-cygwin-shell command prompt, e.g.,
works
but
doesn't.

Yow. The *DLL* expands that? Eww. I understand why you had to be
tied down, that's soooo the wrong place for it. WRS implemented it
into their versions of the binutils, which seems like the right place
for it. Maybe getopts should understand it. Perhaps even bash. But
putting it in the DLL? <gag!>

I think maybe DJGPP does things that way so there was precedent for it.

Post by Dave Korn
in my own tools, and I don't want the parameter to suddenly be replaced
by the contents of a file that happens to have the same name....!

Quoting the @ defeats it. Probably \@ does too. And, just using a
cygwin shell (ash, bash, tcsh, zsh) for everything bypasses that code
entirely.

cgf

[Peter A. Castro]

Post by Christopher Faylor

Post by Peter A. Castro
knowledge gcc's linker doesn't support this syntax.

The cygwin DLL supports it (implemented over my gagged and thrashing body)
but only at a non-cygwin-shell command prompt, e.g.,

Good Gravy!! Yikes!! *Tell me* this is a late April Fool's joke!! Please!!

Post by Christopher Faylor
works
but
doesn't.
I would highly recommend against using this construct, however. It's better
to use traditional unix methods for working around this problem. Cygwin isn't
the only unix-like system out there with a measly amount of space set aside for
the command line.

The original post doesn't specify weither they are working inside of or
outside of a Cygwin environment, but from some of the comments I kinda

Post by Christopher Faylor
Cygwin programs ?

Kinda makes me think he's running this from outside of any Cygwin shell.

But, my original suggestion, as well as your mention above, still stands:
use traditional unix methods, like static-link archive libraries.
Related to, but just as problematic, would be turning all of those object
files into a shared-library/DLL, which I encourage the original poster to
also consider if this program is ment to be run concurrently.

Post by Christopher Faylor
cgf

[Christopher Faylor]

Post by Christopher Faylor

Post by Peter A. Castro
knowledge gcc's linker doesn't support this syntax.

The cygwin DLL supports it (implemented over my gagged and thrashing
body) but only at a non-cygwin-shell command prompt, e.g.,

Good Gravy!! Yikes!! *Tell me* this is a late April Fool's joke!!
Please!!

Nope, it's true. I'm sure glad I added the "gagged and thrashing"
comment. :-)

Post by Christopher Faylor
works
but
doesn't.
I would highly recommend against using this construct, however. It's better
to use traditional unix methods for working around this problem. Cygwin isn't
the only unix-like system out there with a measly amount of space set aside for
the command line.

The original post doesn't specify weither they are working inside of or
outside of a Cygwin environment, but from some of the comments I kinda

For some reason, I assumed they were running from make, where the '@' wouldn't
be exercised. But you are right, that isn't clear.

Post by Christopher Faylor
Cygwin programs ?

Kinda makes me think he's running this from outside of any Cygwin shell.
use traditional unix methods, like static-link archive libraries.
Related to, but just as problematic, would be turning all of those object
files into a shared-library/DLL, which I encourage the original poster to
also consider if this program is ment to be run concurrently.

Right. Larry's pointer to another one of my messages should also work
around the problem by making cygwin use internal methods for passing
arguments. This might be enough to get things working but it is not
foolproof. Using the above techniques is a much better plan.

cgf

[Buchbinder, Barry (NIH/NIAID)]

This behavior is documented:
http://sources.redhat.com/cygwin/cygwin-ug-net/using-specialnames.html#AEN89
9

As for escaping @, experimenting with c:\cygwin\bin\echo will probably give
an answer.

-----Original Message-----
From: Dave Korn [mailto:***@artimi.com]
Sent: Thursday, April 08, 2004 1:45 PM
To: ***@cygwin.com
Subject: RE: Gcc/ld and long command lines (> 32k)

-----Original Message-----
From: cygwin-owner On Behalf Of Christopher Faylor
Sent: 08 April 2004 18:21
C++/Studio). To my

Post by Peter A. Castro
knowledge gcc's linker doesn't support this syntax.

The cygwin DLL supports it (implemented over my gagged and
thrashing body)
but only at a non-cygwin-shell command prompt, e.g.,
works
but
doesn't.

Yow. The *DLL* expands that? Eww. I understand why you had to be tied
down, that's soooo the wrong place for it. WRS implemented it into their
versions of the binutils, which seems like the right place for it. Maybe
getopts should understand it. Perhaps even bash. But putting it in the
DLL? <gag!>

Can I at least escape the @ sign if I really do want to pass "@word" as an
argv entry? I like to use parameters with an @ char prefixing them in my
own tools, and I don't want the parameter to suddenly be replaced by the
contents of a file that happens to have the same name....!

cheers,
DaveK

[Ross Ridge]

Post by Johan Holmberg
Several replies mentioned the possibility of making several
intermediate libraries. I'm well aware of that possibility. But since
I'm not interested in the "library functionality" of libraries, any such
partitioning seems artificial. I always want a *full linking* where all
object files are needed.

You can try using an implicit linker script. Create a file, call it
something like "my-ld-script", with lines like the following:

INPUT(obj1.o obj2.o obj3.o)
INPUT(obj4.o, obj5.o, obj6.o)
INPUT(obj7.o)

And then instead of linking with a command that looks something like this:

gcc -o foo.exe obj1.o obj2.o ... obj7.o -lbar -lbaz

Use something like this:

gcc -o foo.exe my-ld-script -lbar -lbaz

Ross Ridge

[Buchbinder, Barry (NIH/NIAID)]

For the record, the immediate parent can be a DOS/Windows program that is
itself called by a Cygwin program (in this example, bash).

/tmp> wc t
1 11850 404970 t
/tmp> /bin/echo @t
@t
/tmp> /bin/echo @t | wc
1 1 3
/tmp> $(cygpath -u ${COMSPEC}) /c $(cygpath -w /bin/echo) @t | wc
1 11850 404970

But the handling of quotes is likely to be ugly.

-----Original Message-----
From: Larry Hall
Sent: Friday, April 09, 2004 9:18 AM
To: Peter A. Castro; ***@cygwin.com
Subject: Re: Gcc/ld and long command lines (> 32k)

Post by Peter A. Castro

Post by Christopher Faylor

Post by Johan Holmberg
- the programs I'm building are C/C++ compilers
- I use GCC in Cygwin to get a "second opinion" from another compiler
than the one we use normally (Visual C++).
- I use Cons as my build tool (a Perl program).
I use ActiveState Perl (not Cygwin Perl).
So yes, I'm working "outside a Cygwin environment".

Ok, so, sorry, but I wasn't thinking clearly. The '-X' option to mount
only works when a cygwin programs which invoke another cygwin program.
If you have a normal windows program running a cygwin program, your only

Well, Chris, for better or worst, this "feature" does seem to work. I
You will need to remount both /usr/bin and /usr/lib with the "--system
For the record, I still feel that a better practice is to do archiving of
object files and link with the library, but if this gets you going, this
time, more power to ya.

But wait. You're mixing advice (Chris's) it seems. He said @file would
be a solution if you were working outside of Cygwin shells and that
remounting with -X could be a solution if you were inside. So it sounds
like you tried both, and perhaps together, but it's unclear whether you
ran your tests from a Cygwin shell prompt, a Windows DOS prompt, or both.
Can you clarify what you tried and where?

Thanks,

--
Larry Hall http://www.rfk.com
RFK Partners, Inc. [phone] - RFK Office
838 Washington Street [phone] - FAX
Holliston, MA 01746

[Larry Hall]

Right. I think that goes along with the notion that the '@' stuff is
enabled for Cygwin processes invoked from non-Cygwin ones. But perhaps
I was unclear about what I was looking for. Peter's response seemed to
indicate that he tried *both* the suggested mount option and the '@file'
option simultaneously. It also wasn't clear whether he was using the
'@file' option as invoked by a Windows process (perhaps even as a variant
of Barry's example below) or whether he tried it from a Cygwin process
(directly). Ditto for the mount option. I think Peter was trying to
indicate that these options work but it's a little confusing given that
Chris's previous statements say that '@file' should be a solution for
Windows processes and the mount option should be a solution for Cygwin
processes. It's unclear whether Peter is confirming or refuting any
part or parts of Chris' statement. That's what I was hoping to get some
clarification on.

Larry

Post by Buchbinder, Barry (NIH/NIAID)
For the record, the immediate parent can be a DOS/Windows program that is
itself called by a Cygwin program (in this example, bash).
/tmp> wc t
1 11850 404970 t
@t
1 1 3
1 11850 404970
But the handling of quotes is likely to be ugly.
-----Original Message-----
From: Larry Hall
Sent: Friday, April 09, 2004 9:18 AM
Subject: Re: Gcc/ld and long command lines (> 32k)

Post by Peter A. Castro

Post by Christopher Faylor

Post by Johan Holmberg
- the programs I'm building are C/C++ compilers
- I use GCC in Cygwin to get a "second opinion" from another compiler
than the one we use normally (Visual C++).
- I use Cons as my build tool (a Perl program).
I use ActiveState Perl (not Cygwin Perl).
So yes, I'm working "outside a Cygwin environment".

Ok, so, sorry, but I wasn't thinking clearly. The '-X' option to mount
only works when a cygwin programs which invoke another cygwin program.
If you have a normal windows program running a cygwin program, your only

Well, Chris, for better or worst, this "feature" does seem to work. I
You will need to remount both /usr/bin and /usr/lib with the "--system
For the record, I still feel that a better practice is to do archiving of
object files and link with the library, but if this gets you going, this
time, more power to ya.

be a solution if you were working outside of Cygwin shells and that
remounting with -X could be a solution if you were inside. So it sounds
like you tried both, and perhaps together, but it's unclear whether you
ran your tests from a Cygwin shell prompt, a Windows DOS prompt, or both.
Can you clarify what you tried and where?
Thanks,
--
Larry Hall http://www.rfk.com
RFK Partners, Inc. [phone] - RFK Office
838 Washington Street [phone] - FAX
Holliston, MA 01746
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/

[Christopher Faylor]

Post by Larry Hall
enabled for Cygwin processes invoked from non-Cygwin ones. But perhaps
I was unclear about what I was looking for. Peter's response seemed to
option simultaneously. It also wasn't clear whether he was using the
of Barry's example below) or whether he tried it from a Cygwin process
(directly). Ditto for the mount option. I think Peter was trying to
indicate that these options work but it's a little confusing given that
Windows processes and the mount option should be a solution for Cygwin
processes. It's unclear whether Peter is confirming or refuting any
part or parts of Chris' statement. That's what I was hoping to get some
clarification on.

I think both Peter and the OP thought this through more than I had --
once you use '@' with the gcc command line, there is still further
argument passing going on between gcc and its (cygwin) subprocesses.

So, to bypass the 32K limit, you do need to use '@' for the initial
command line to gcc and any program that gcc calls needs to be mounted
with -X.

cgf

[Peter A. Castro]

On Fri, 9 Apr 2004, Larry Hall wrote:

Hi Larry,

Post by Larry Hall
enabled for Cygwin processes invoked from non-Cygwin ones. But perhaps
I was unclear about what I was looking for. Peter's response seemed to
option simultaneously. It also wasn't clear whether he was using the
of Barry's example below) or whether he tried it from a Cygwin process
(directly). Ditto for the mount option. I think Peter was trying to
indicate that these options work but it's a little confusing given that
Windows processes and the mount option should be a solution for Cygwin
processes. It's unclear whether Peter is confirming or refuting any
part or parts of Chris' statement. That's what I was hoping to get some
clarification on.

I've already responded with a more clear explaination, but I felt
compelled to respond here as well. I was making a mental leap in my
other email. Johan's original email questioned about the "-X" mount
option possibly being useful, and Chris's email talked about @file being
only useable from a non-Cygwin invocation. I tied the two together and
they worked. This is what Johan had originally asked about (both -X and
@file), and, from that context, I was responding. Sorry if it was a
little inarticulate by arrived at a conclusion without supplying my
work-sheet as proof :). For Johan's configuration, this combination
should work for him. I hadn't tried any other combinations because it
was uninteresting with respect to Johan's configuration. If it didn't
work, I would have experimented further, but it did and I didn't :)

Post by Larry Hall
Larry

Post by Buchbinder, Barry (NIH/NIAID)
For the record, the immediate parent can be a DOS/Windows program that is
itself called by a Cygwin program (in this example, bash).
/tmp> wc t
1 11850 404970 t
@t
1 1 3
1 11850 404970
But the handling of quotes is likely to be ugly.
-----Original Message-----
From: Larry Hall
Sent: Friday, April 09, 2004 9:18 AM
Subject: Re: Gcc/ld and long command lines (> 32k)

Post by Peter A. Castro

Post by Christopher Faylor

Post by Johan Holmberg
- the programs I'm building are C/C++ compilers
- I use GCC in Cygwin to get a "second opinion" from another compiler
than the one we use normally (Visual C++).
- I use Cons as my build tool (a Perl program).
I use ActiveState Perl (not Cygwin Perl).
So yes, I'm working "outside a Cygwin environment".

Ok, so, sorry, but I wasn't thinking clearly. The '-X' option to mount
only works when a cygwin programs which invoke another cygwin program.
If you have a normal windows program running a cygwin program, your only

Well, Chris, for better or worst, this "feature" does seem to work. I
You will need to remount both /usr/bin and /usr/lib with the "--system
For the record, I still feel that a better practice is to do archiving of
object files and link with the library, but if this gets you going, this
time, more power to ya.

be a solution if you were working outside of Cygwin shells and that
remounting with -X could be a solution if you were inside. So it sounds
like you tried both, and perhaps together, but it's unclear whether you
ran your tests from a Cygwin shell prompt, a Windows DOS prompt, or both.
Can you clarify what you tried and where?
Thanks,
--
Larry Hall http://www.rfk.com
RFK Partners, Inc. [phone] - RFK Office
838 Washington Street [phone] - FAX
Holliston, MA 01746
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/

--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/

[Larry Hall]

Post by Peter A. Castro
Hi Larry,

Post by Larry Hall
enabled for Cygwin processes invoked from non-Cygwin ones. But perhaps
I was unclear about what I was looking for. Peter's response seemed to
option simultaneously. It also wasn't clear whether he was using the
of Barry's example below) or whether he tried it from a Cygwin process
(directly). Ditto for the mount option. I think Peter was trying to
indicate that these options work but it's a little confusing given that
Windows processes and the mount option should be a solution for Cygwin
processes. It's unclear whether Peter is confirming or refuting any
part or parts of Chris' statement. That's what I was hoping to get some
clarification on.

I've already responded with a more clear explaination, but I felt
compelled to respond here as well. I was making a mental leap in my
other email. Johan's original email questioned about the "-X" mount
only useable from a non-Cygwin invocation. I tied the two together and
they worked. This is what Johan had originally asked about (both -X and
@file), and, from that context, I was responding. Sorry if it was a
little inarticulate by arrived at a conclusion without supplying my
work-sheet as proof :). For Johan's configuration, this combination
should work for him. I hadn't tried any other combinations because it
was uninteresting with respect to Johan's configuration. If it didn't
work, I would have experimented further, but it did and I didn't :)

Great, thanks Peter. I'm clear now. :-)


--
Larry Hall http://www.rfk.com
RFK Partners, Inc. [phone] - RFK Office
838 Washington Street [phone] - FAX
Holliston, MA 01746

[Larry Hall]

Post by Christopher Faylor

Post by Larry Hall
enabled for Cygwin processes invoked from non-Cygwin ones. But perhaps
I was unclear about what I was looking for. Peter's response seemed to
option simultaneously. It also wasn't clear whether he was using the
of Barry's example below) or whether he tried it from a Cygwin process
(directly). Ditto for the mount option. I think Peter was trying to
indicate that these options work but it's a little confusing given that
Windows processes and the mount option should be a solution for Cygwin
processes. It's unclear whether Peter is confirming or refuting any
part or parts of Chris' statement. That's what I was hoping to get some
clarification on.

I think both Peter and the OP thought this through more than I had --
argument passing going on between gcc and its (cygwin) subprocesses.
command line to gcc and any program that gcc calls needs to be mounted
with -X.

Ah, OK. Yeah that makes sense now.

Thanks,


--
Larry Hall http://www.rfk.com
RFK Partners, Inc. [phone] - RFK Office
838 Washington Street [phone] - FAX
Holliston, MA 01746