public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: CreateProcess No such file or directory
       [not found] <CAGt5VgF4tzCJMmbpu-Bq7ySQHdA_HuwbaaYJX7WSD=D4Yp068A@mail.gmail.com>
@ 2022-09-20 16:18 ` Richard Earnshaw
       [not found]   ` <CAGt5VgGCvVm-2=gdv87XS8DNqLfu-KkcjqhrbQPHAA_vA9fOaw@mail.gmail.com>
  2022-09-22  6:44 ` LIU Hao
  1 sibling, 1 reply; 13+ messages in thread
From: Richard Earnshaw @ 2022-09-20 16:18 UTC (permalink / raw)
  To: mizo 91, gcc-help



On 20/09/2022 17:02, mizo 91 via Gcc-help wrote:
> Hello,
> 
> I'm having trouble compiling simple test program on windows 10 with long
> list of includes provided via '@response_file' argument
> 
> The full error is:
> 
> gcc.exe: fatal error: cannot execute
> 'C:/Tools/x86_64-12.2.0-release-win32-seh-rt_v10-rev0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/as.exe':
> CreateProcess: No such file or directory
> 
> compilation terminated.
> 
> Above path to the assembler program is valid therefore I don't understand
> what is the issue here?
> 
> You can try to recreate the problem by compiling simple main.c file with
> nothing in it but main function using command:
> gcc @includes.txt main.c
> 
> I assume it has something to do with windows 32k CreateProcess command
> length limitation? But isn't that the reason why respone files were
> invented?
> 
> Regards,
> Filip

I'm by no means a windows expert, but I wonder if this might be related 
to the length of the path to the assembler and that it's somehow getting 
truncated.

R.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* RE: CreateProcess No such file or directory
       [not found]   ` <CAGt5VgGCvVm-2=gdv87XS8DNqLfu-KkcjqhrbQPHAA_vA9fOaw@mail.gmail.com>
@ 2022-09-20 22:27     ` Tamar Christina
  0 siblings, 0 replies; 13+ messages in thread
From: Tamar Christina @ 2022-09-20 22:27 UTC (permalink / raw)
  To: mizo 91, Richard Earnshaw; +Cc: gcc-help

We'd mostly be guessing here, use strace or https://learn.microsoft.com/en-us/sysinternals/downloads/procmon to see which path is actually being accessed and why it failed.

Also check that you can run `as` correctly. This error can also happen if a dependency of `as.exe` isn't found during loading.

Cheers,
Tamar

> -----Original Message-----
> From: Gcc-help <gcc-help-bounces+tamar.christina=arm.com@gcc.gnu.org>
> On Behalf Of mizo 91 via Gcc-help
> Sent: Tuesday, September 20, 2022 1:17 PM
> To: Richard Earnshaw <Richard.Earnshaw@foss.arm.com>
> Cc: gcc-help@gcc.gnu.org
> Subject: Re: CreateProcess No such file or directory
> 
>  According to Microsoft docs path length limitation for windows is 256. In my
> case its 143 chars. I think the problem might be related to how gcc driver is
> passing along unmarshalled arguments to its subprograms like as.exe.
> Suprisingly this works correctly if I enforce gcc driver to use preprocessor only
> by adding -E flag
> 
> btw. I failed to previously mention that I'm using Mingw-W64 version
> provided kindly by niXman Binaries taken directly from official MinGW-W64
> builds:
> https://www.mingw-w64.org/downloads/#mingw-builds
> https://github.com/niXman/mingw-builds-binaries/releases
> 
> R.
> 
> wt., 20 wrz 2022 o 18:18 Richard Earnshaw
> <Richard.Earnshaw@foss.arm.com>
> napisał(a):
> 
> >
> >
> > On 20/09/2022 17:02, mizo 91 via Gcc-help wrote:
> > > Hello,
> > >
> > > I'm having trouble compiling simple test program on windows 10 with
> > > long list of includes provided via '@response_file' argument
> > >
> > > The full error is:
> > >
> > > gcc.exe: fatal error: cannot execute
> > >
> > 'C:/Tools/x86_64-12.2.0-release-win32-seh-rt_v10-
> rev0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-
> w64-mingw32/bin/as.exe':
> > > CreateProcess: No such file or directory
> > >
> > > compilation terminated.
> > >
> > > Above path to the assembler program is valid therefore I don't
> > > understand what is the issue here?
> > >
> > > You can try to recreate the problem by compiling simple main.c file
> > > with nothing in it but main function using command:
> > > gcc @includes.txt main.c
> > >
> > > I assume it has something to do with windows 32k CreateProcess
> > > command length limitation? But isn't that the reason why respone
> > > files were invented?
> > >
> > > Regards,
> > > Filip
> >
> > I'm by no means a windows expert, but I wonder if this might be
> > related to the length of the path to the assembler and that it's
> > somehow getting truncated.
> >
> > R.
> >

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: CreateProcess No such file or directory
       [not found] <CAGt5VgF4tzCJMmbpu-Bq7ySQHdA_HuwbaaYJX7WSD=D4Yp068A@mail.gmail.com>
  2022-09-20 16:18 ` CreateProcess No such file or directory Richard Earnshaw
@ 2022-09-22  6:44 ` LIU Hao
  2022-09-22  8:19   ` Jonathan Wakely
       [not found]   ` <CAGt5VgHdB_-iBy_3CSnexnu=0uLxV6D=w8c5k96tDawFw7oUnA@mail.gmail.com>
  1 sibling, 2 replies; 13+ messages in thread
From: LIU Hao @ 2022-09-22  6:44 UTC (permalink / raw)
  To: mizo 91, gcc-help


[-- Attachment #1.1: Type: text/plain, Size: 2029 bytes --]

在 2022/9/21 00:02, mizo 91 via Gcc-help 写道:
> Hello,
> 
> I'm having trouble compiling simple test program on windows 10 with long
> list of includes provided via '@response_file' argument
> 
> 

Greetings. mingw-w64 developer speaking.

As far as I can see, there are at least two issues about your report:


The first, obvious issue is that the error message is incorrect. The reason for that is, if we take 
a look at 'libiberty/pex-win32.c' we see the following:

   853   /* Create the child process.  */
   854   pid = win32_spawn (executable, (flags & PEX_SEARCH) != 0,
   855                      argv, env, dwCreationFlags, &si, &pi);
   856   if (pid == (pid_t) -1)
   857     pid = spawn_script (executable, argv, env, dwCreationFlags,
   858                         &si, &pi);
   859   if (pid == (pid_t) -1)
   860     {
   861       *err = ENOENT;
   862       *errmsg = "CreateProcess";
   863     }

We also notice this is the only place where `"CreateProcess"` appears as a sole part of an error 
message.

The cause of this issue is apparent: libiberty tries `win32_spawn`, and if for whatever reason it 
fails, it makes another attempt with `spawn_script`, and if it fails again, `*err` is always set to 
`ENOENT` i.e. `No such file or directory`, no matter why.


Since we are invoking 'as.exe' here, which is never a script, the first attempt must have failed. We 
can start 'gcc.exe' with a debugger. There are actually two calls to `CreateProcessA()`: one to 
'cc1.exe' and the other to 'as.exe'; the latter fails with `ERROR_INVALID_PARAMETER`.

So, the error happens, not because anything can't be found, but because the command line is too 
long. With your example, it contains a lot of `-include` arguments and takes ~44K characters, and is 
not valid. Windows only allows a single command line up to 32,767 characters, because the NT syscall 
uses a 16-bit length for a UTF-16 string which includes a null terminator.


-- 
Best regards,
LIU Hao

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: CreateProcess No such file or directory
  2022-09-22  6:44 ` LIU Hao
@ 2022-09-22  8:19   ` Jonathan Wakely
  2022-09-22  8:42     ` Jonathan Wakely
       [not found]   ` <CAGt5VgHdB_-iBy_3CSnexnu=0uLxV6D=w8c5k96tDawFw7oUnA@mail.gmail.com>
  1 sibling, 1 reply; 13+ messages in thread
From: Jonathan Wakely @ 2022-09-22  8:19 UTC (permalink / raw)
  To: LIU Hao; +Cc: mizo 91, gcc-help

On Thu, 22 Sept 2022 at 07:45, LIU Hao via Gcc-help
<gcc-help@gcc.gnu.org> wrote:
>
> 在 2022/9/21 00:02, mizo 91 via Gcc-help 写道:
> > Hello,
> >
> > I'm having trouble compiling simple test program on windows 10 with long
> > list of includes provided via '@response_file' argument
> >
> >
>
> Greetings. mingw-w64 developer speaking.
>
> As far as I can see, there are at least two issues about your report:
>
>
> The first, obvious issue is that the error message is incorrect. The reason for that is, if we take
> a look at 'libiberty/pex-win32.c' we see the following:
>
>    853   /* Create the child process.  */
>    854   pid = win32_spawn (executable, (flags & PEX_SEARCH) != 0,
>    855                      argv, env, dwCreationFlags, &si, &pi);
>    856   if (pid == (pid_t) -1)
>    857     pid = spawn_script (executable, argv, env, dwCreationFlags,
>    858                         &si, &pi);
>    859   if (pid == (pid_t) -1)
>    860     {
>    861       *err = ENOENT;
>    862       *errmsg = "CreateProcess";
>    863     }
>
> We also notice this is the only place where `"CreateProcess"` appears as a sole part of an error
> message.
>
> The cause of this issue is apparent: libiberty tries `win32_spawn`, and if for whatever reason it
> fails, it makes another attempt with `spawn_script`, and if it fails again, `*err` is always set to
> `ENOENT` i.e. `No such file or directory`, no matter why.

It seems to me that pex-win32.c should use GetLastError() (and maybe
FormatMessage) to get a Windows error code, rather than assuming
ENOENT.

Using C++ that would look something like:

std::string errmsg = "CreateProcess:" +
std::system_category().message(GetLastError());

Or maybe win32_spawn should call GetLastError() and convert that to an
errno value and store it in errno:

std::error_condition ec =
std::system_category().default_error_condition(GetLastError());
if (ec.category() == std::generic_category())
  errno = ec.value();
else
  errno = ENOENT; // or EINVAL might be better?

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: CreateProcess No such file or directory
  2022-09-22  8:19   ` Jonathan Wakely
@ 2022-09-22  8:42     ` Jonathan Wakely
  2022-09-22  9:48       ` LIU Hao
  0 siblings, 1 reply; 13+ messages in thread
From: Jonathan Wakely @ 2022-09-22  8:42 UTC (permalink / raw)
  To: LIU Hao; +Cc: mizo 91, gcc-help

On Thu, 22 Sept 2022 at 09:19, Jonathan Wakely wrote:
>
> On Thu, 22 Sept 2022 at 07:45, LIU Hao via Gcc-help
> <gcc-help@gcc.gnu.org> wrote:
> >
> > 在 2022/9/21 00:02, mizo 91 via Gcc-help 写道:
> > > Hello,
> > >
> > > I'm having trouble compiling simple test program on windows 10 with long
> > > list of includes provided via '@response_file' argument
> > >
> > >
> >
> > Greetings. mingw-w64 developer speaking.
> >
> > As far as I can see, there are at least two issues about your report:
> >
> >
> > The first, obvious issue is that the error message is incorrect. The reason for that is, if we take
> > a look at 'libiberty/pex-win32.c' we see the following:
> >
> >    853   /* Create the child process.  */
> >    854   pid = win32_spawn (executable, (flags & PEX_SEARCH) != 0,
> >    855                      argv, env, dwCreationFlags, &si, &pi);
> >    856   if (pid == (pid_t) -1)
> >    857     pid = spawn_script (executable, argv, env, dwCreationFlags,
> >    858                         &si, &pi);
> >    859   if (pid == (pid_t) -1)
> >    860     {
> >    861       *err = ENOENT;
> >    862       *errmsg = "CreateProcess";
> >    863     }
> >
> > We also notice this is the only place where `"CreateProcess"` appears as a sole part of an error
> > message.
> >
> > The cause of this issue is apparent: libiberty tries `win32_spawn`, and if for whatever reason it
> > fails, it makes another attempt with `spawn_script`, and if it fails again, `*err` is always set to
> > `ENOENT` i.e. `No such file or directory`, no matter why.
>
> It seems to me that pex-win32.c should use GetLastError() (and maybe
> FormatMessage) to get a Windows error code, rather than assuming
> ENOENT.
>
> Using C++ that would look something like:
>
> std::string errmsg = "CreateProcess:" +
> std::system_category().message(GetLastError());
>
> Or maybe win32_spawn should call GetLastError() and convert that to an
> errno value and store it in errno:
>
> std::error_condition ec =
> std::system_category().default_error_condition(GetLastError());
> if (ec.category() == std::generic_category())
>   errno = ec.value();
> else
>   errno = ENOENT; // or EINVAL might be better?

I reported https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107007

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: CreateProcess No such file or directory
       [not found]   ` <CAGt5VgHdB_-iBy_3CSnexnu=0uLxV6D=w8c5k96tDawFw7oUnA@mail.gmail.com>
@ 2022-09-22  9:46     ` LIU Hao
       [not found]       ` <CAGt5VgEeUOTJFz2NGsqzVN0N+GoyBy8m-_+ytgdXckav89Syew@mail.gmail.com>
  0 siblings, 1 reply; 13+ messages in thread
From: LIU Hao @ 2022-09-22  9:46 UTC (permalink / raw)
  To: mizo 91, gcc-help


[-- Attachment #1.1: Type: text/plain, Size: 1204 bytes --]

在 2022/9/22 15:35, mizo 91 写道:
> Hello LIU Hao,
> 
> Thank you for your insight. In my understanding main purpouse of response file is to overcome 
> command too long issue(which can also happen on linux but is by magnitude less likely). I imagine if 
> my command is too long gcc driver should ensure that subprograms like assembler should have recieved 
> command arguments in the same way gcc did (which is through response file). Insted the assembler 
> process is spawned directly By CreateProcessA whith unwrapped arguments by the driver which is like 
> you said the reason for the error. Additionaly isnt -I flags required for preprocessor only? Why gcc 
> is trying to pass -I arguments to assembler program? Wouldnt you consider this gcc driver bug than?
> 
>

I doubt whether there is necessity to fix this 'bug', if it has to be a bug, after all. Normally a 
user is not expected to compose a command that comprises tens of thousands of characters. If they do 
then they are likely doing something wrong; they should have split such a source into multiple files 
to reduce dependencies and passed shorter command lines to build them.



-- 
Best regards,
LIU Hao

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: CreateProcess No such file or directory
  2022-09-22  8:42     ` Jonathan Wakely
@ 2022-09-22  9:48       ` LIU Hao
  0 siblings, 0 replies; 13+ messages in thread
From: LIU Hao @ 2022-09-22  9:48 UTC (permalink / raw)
  To: Jonathan Wakely; +Cc: mizo 91, gcc-help


[-- Attachment #1.1: Type: text/plain, Size: 327 bytes --]

在 2022/9/22 16:42, Jonathan Wakely 写道:
> 
> I reported https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107007

Thank you. It's much better than what we have now. I recall that I did encounter such cryptic errors 
some times before, due to misconfiguration. It would have helped a lot.


-- 
Best regards,
LIU Hao

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: CreateProcess No such file or directory
       [not found]       ` <CAGt5VgEeUOTJFz2NGsqzVN0N+GoyBy8m-_+ytgdXckav89Syew@mail.gmail.com>
@ 2022-09-22 16:04         ` LIU Hao
       [not found]           ` <CAGt5VgEKzro0uo5qQaqPZLc=Fpcw4_sLYC_-CFyGxYGWSmqAtg@mail.gmail.com>
  2022-09-23 17:14         ` David Brown
  1 sibling, 1 reply; 13+ messages in thread
From: LIU Hao @ 2022-09-22 16:04 UTC (permalink / raw)
  To: mizo 91; +Cc: gcc-help


[-- Attachment #1.1: Type: text/plain, Size: 2778 bytes --]

在 2022-09-22 22:55, mizo 91 写道:
> Hi LIU Hao,
> 
> Following that logic, let's just get rid of response file feature while we are at it. Why encourage 
> bad programming practices? Why maintain something that doesn't even work properly?
> 
> I think this topic is very underrated and many people working with large codebases have problems 
> because of it.
> 

Such limits exist because the Windows NT syscall passes command lines via the `UNICODE_STRING` 
struct, which stores the string length as the number of bytes as an `unsigned short`. The maximum 
number of UTF-16 code units is consequently 0xFFFF / 2 = 32767.

There isn't "something that doesn't even work properly". It's just the system limit. On Linux we 
have a much larger limit (usually a few MiBs) but there is still one. Given an arbitrary repository, 
checked out at an arbitrary directory, with an arbitrary number of submodules, then it's likely that 
the limit will be hit sooner or later.


> For example, let's say I have a project structure of over 100+ modules. Each module uses internal 
> headers from other modules. It's much easier to maintain a single global "include directories" list 
> than to do it on a per-module basis. Because if something changes in one module I would have to 
> rewrite configuraiton for all 100 modules as well. If I'm not mistaken Eclise CDT is using this kind 
> of project configuration approach.
> 
> Additionaly projects may rely on macro definitions to provide configuration values through the 
> command line. And for large codebases, there could be hundreds of such macros. This alone can easily 
> bring the length of compile command closer to this limit. Of course, you can define these macros in 
> the header and add them as another dependency, but this is just a workaround, not a solution.
> 

I think I have to disagree here. Response files are there to work around the 8-KiB limit of command 
lines in CMD, but it cannot work around system limits. Using a 'config.h' of macros is widely known, 
accepted and preferred, rather than passing a lot of macros via command line. Similarly, if there 
are too many object files to link, a convenience library or incremental linking with `ld -r` will 
usually solve the issue. If you don't want to do these by tampering with build systems, xargs may 
help. There are a lot of mature solutions for keeping away from system limits, but generally we 
assume our users know what they're doing.


> I'm sure there are many different kinds of codebase configurations that will rely on this feature. 
> And the people adopting these codebases would hit a brick wall.
> 
> So yeah this is definitely a 'BUG'. Big one in my opinion.
> 
>
-- 
Best regards,
LIU Hao


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: CreateProcess No such file or directory
       [not found]       ` <CAGt5VgEeUOTJFz2NGsqzVN0N+GoyBy8m-_+ytgdXckav89Syew@mail.gmail.com>
  2022-09-22 16:04         ` LIU Hao
@ 2022-09-23 17:14         ` David Brown
  1 sibling, 0 replies; 13+ messages in thread
From: David Brown @ 2022-09-23 17:14 UTC (permalink / raw)
  To: mizo 91, LIU Hao; +Cc: gcc-help

On 22/09/2022 16:55, mizo 91 via Gcc-help wrote:
> Hi LIU Hao,
> 
> Following that logic, let's just get rid of response file feature while we
> are at it. Why encourage bad programming practices? Why maintain something
> that doesn't even work properly?
> 
> I think this topic is very underrated and many people working with large
> codebases have problems because of it.
> 
> For example, let's say I have a project structure of over 100+ modules.
> Each module uses internal headers from other modules. It's much easier to
> maintain a single global "include directories" list than to do it on a
> per-module basis. Because if something changes in one module I would have
> to rewrite configuraiton for all 100 modules as well. If I'm not mistaken
> Eclise CDT is using this kind of project configuration approach.
> 
> Additionaly projects may rely on macro definitions to provide configuration
> values through the command line. And for large codebases, there could be
> hundreds of such macros. This alone can easily bring the length of compile
> command closer to this limit. Of course, you can define these macros in the
> header and add them as another dependency, but this is just a workaround,
> not a solution.
> 
> I'm sure there are many different kinds of codebase configurations that
> will rely on this feature. And the people adopting these codebases would
> hit a brick wall.
> 
> So yeah this is definitely a 'BUG'. Big one in my opinion.
> 
> Kind Regards,
> Filip
> 

This all sounds like a very questionable way to organise your project. 
(I hesitate to say "wrong", because people have good reasons for 
organising projects in different ways, and sometimes it's just down to 
personal preferences.  But if I were given charge of this project as you 
describe it, I'd say it's wrong and must be changed.)

I would say that if you are listing a large number of include 
directories in the include search path, you are doing things wrong. 
This is especially true when you have code from different places and 
different modules - you are just asking for trouble when there are 
filename clashes between parts.  It is much better to put the directory 
explicitly in the #include statements.  Alternatively, you can have 
indirect inclusions - have a single directory "modules_includes" that 
has an include file for each module.  Those include files have nothing 
but an include directive with the real module public include file, 
including the directory.  This "modules_include" might then go on your 
compiler include path, but I'd not do that either.

That way you can easily include the files you want, and not accidentally 
include private headers that are internal to modules.  It is much easier 
to find what you want, and much easier to read the source code.  When 
you see "#include "modules_include/foo.h" ", or "foo/public.h" 
(depending on which solution you use) in the source code, you know it is 
the public interface for the module "foo".  You don't have to wonder 
which of the hundred directories it might be in or what module it is.

Yes, Eclipse CDT likes to make huge include paths.  (At least, that is 
my experience using many embedded toolchain packages based on Eclipse.) 
  It is a PITA.  It also has a painfully inefficient build system by 
default.  It's okay for tiny test projects - for anything serious, you 
want a different project organisation and a different build system 
(make, or whatever you like).  This has the extra advantage of making 
Eclipse CDT much faster and more convenient when you use it as an editor 
and IDE.


Regarding the #define macros, put them all in a single header.  If it 
makes life easier, use the gcc option "-imacros <file>" to include it 
for all compilations.  A file of defines is simpler to read, edit, 
comment, change and maintain than a list of "-D..." options passed to 
the compiler.  It also gives you more flexibility, such as using 
conditional compilation to allow some macros to depend on others.


Of course I don't know your project at all, and don't know how realistic 
these suggestions are, but hopefully you'll find them helpful.

David

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: CreateProcess No such file or directory
       [not found]           ` <CAGt5VgEKzro0uo5qQaqPZLc=Fpcw4_sLYC_-CFyGxYGWSmqAtg@mail.gmail.com>
@ 2022-09-23 17:40             ` Xi Ruoyao
       [not found]               ` <CAGt5VgFzXJkvFg333ZgH-GDKKCudSWRdKPFvf5Fh16d=eK1pQg@mail.gmail.com>
  0 siblings, 1 reply; 13+ messages in thread
From: Xi Ruoyao @ 2022-09-23 17:40 UTC (permalink / raw)
  To: mizo 91, LIU Hao; +Cc: gcc-help

On Thu, 2022-09-22 at 18:50 +0200, mizo 91 via Gcc-help wrote:

> Additionaly isnt -I flags required for preprocessor only? Why gcc is
> trying to pass -I arguments to assembler program? Wouldnt you consider this
> gcc driver bug than?

From GNU assembler manual:

    -I dir
      Add directory dir to the search list for ".include" directives.

So -I flags may be for preprocessor, or for assembler.

> Ok, if indeed this is a system limitation that cannot be avoided then why
> is the clang compiler not having this problem?

Because clang emits an object file without invoking an assembler.  This
is a difference in the fundamental design of the two compilers, and you
can't change it just for some looooooong command line.

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: CreateProcess No such file or directory
       [not found]               ` <CAGt5VgFzXJkvFg333ZgH-GDKKCudSWRdKPFvf5Fh16d=eK1pQg@mail.gmail.com>
@ 2022-09-24  5:13                 ` Xi Ruoyao
       [not found]                   ` <CAGt5VgFTLteAH1QyVn_7r2wHJab57enY3vrUMWU8UFi-D14msA@mail.gmail.com>
  0 siblings, 1 reply; 13+ messages in thread
From: Xi Ruoyao @ 2022-09-24  5:13 UTC (permalink / raw)
  To: mizo 91; +Cc: LIU Hao, gcc-help

On Fri, 2022-09-23 at 23:11 +0200, mizo 91 wrote:
> > From GNU assembler manual:
> > 
> >     -I dir
> >       Add directory dir to the search list for ".include"
> > directives.
> > 
> > So -I flags may be for preprocessor, or for assembler.
>  
> I'm not calling the assembler. Im calling gcc. Check what gcc manual
> have to say about it.

The problem is it's common to use "gcc -c foo.s" instead of "as foo.s -o
foo.o" in the building system of the packages.  It can ensure the
assembler used for both C files and assembly files the same one.  If you
suddenly stop to pass -I options to the assembler, you can break the
building process of existing packages.
-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: CreateProcess No such file or directory
       [not found]                   ` <CAGt5VgFTLteAH1QyVn_7r2wHJab57enY3vrUMWU8UFi-D14msA@mail.gmail.com>
@ 2022-09-24  9:51                     ` Xi Ruoyao
  2022-09-24 10:20                       ` Jonathan Wakely
  0 siblings, 1 reply; 13+ messages in thread
From: Xi Ruoyao @ 2022-09-24  9:51 UTC (permalink / raw)
  To: mizo 91; +Cc: LIU Hao, gcc-help

On Sat, 2022-09-24 at 11:28 +0200, mizo 91 wrote:
> You are right that changing this behavior would have serious
> consequences. But wouldn't you agree that gcc could somehow
> distinguish whether the input files is of *.c or *.s source kind
> , and then decide if it should pass -I to the assembler or the
> preprocessor or  both? That would be more in line with what I would
> expect after reading the documentation. Passing -I to the assembler
> when invoking the command 'gcc -c source.c' seems unnecessary.

Even with .c files it's still legal to use ".include" directives in
inline assembly.

The only rational thing to do is creating a file containing the options
for the assembler, then pass it to the assembler with @FILE.  As @FILE
is not supported by non-GNU (and, maybe, old GNU) assemblers, the
feature cannot be the default and we need to add a new option "-use-
cmdfile-for-as" (or some better name).

If someone really cares about this he/she can make a patch and send it
to gcc-patches@gcc.gnu.org.
-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: CreateProcess No such file or directory
  2022-09-24  9:51                     ` Xi Ruoyao
@ 2022-09-24 10:20                       ` Jonathan Wakely
  0 siblings, 0 replies; 13+ messages in thread
From: Jonathan Wakely @ 2022-09-24 10:20 UTC (permalink / raw)
  To: Xi Ruoyao; +Cc: mizo 91, gcc-help

On Sat, 24 Sept 2022 at 10:52, Xi Ruoyao wrote:
> The only rational thing to do is creating a file containing the options
> for the assembler, then pass it to the assembler with @FILE.  As @FILE
> is not supported by non-GNU (and, maybe, old GNU) assemblers, the
> feature cannot be the default and we need to add a new option "-use-
> cmdfile-for-as" (or some better name).

The configure process can check whether it's supported, or just assume
it's supported when --with-gnu-as is in effect.

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2022-09-24 10:21 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CAGt5VgF4tzCJMmbpu-Bq7ySQHdA_HuwbaaYJX7WSD=D4Yp068A@mail.gmail.com>
2022-09-20 16:18 ` CreateProcess No such file or directory Richard Earnshaw
     [not found]   ` <CAGt5VgGCvVm-2=gdv87XS8DNqLfu-KkcjqhrbQPHAA_vA9fOaw@mail.gmail.com>
2022-09-20 22:27     ` Tamar Christina
2022-09-22  6:44 ` LIU Hao
2022-09-22  8:19   ` Jonathan Wakely
2022-09-22  8:42     ` Jonathan Wakely
2022-09-22  9:48       ` LIU Hao
     [not found]   ` <CAGt5VgHdB_-iBy_3CSnexnu=0uLxV6D=w8c5k96tDawFw7oUnA@mail.gmail.com>
2022-09-22  9:46     ` LIU Hao
     [not found]       ` <CAGt5VgEeUOTJFz2NGsqzVN0N+GoyBy8m-_+ytgdXckav89Syew@mail.gmail.com>
2022-09-22 16:04         ` LIU Hao
     [not found]           ` <CAGt5VgEKzro0uo5qQaqPZLc=Fpcw4_sLYC_-CFyGxYGWSmqAtg@mail.gmail.com>
2022-09-23 17:40             ` Xi Ruoyao
     [not found]               ` <CAGt5VgFzXJkvFg333ZgH-GDKKCudSWRdKPFvf5Fh16d=eK1pQg@mail.gmail.com>
2022-09-24  5:13                 ` Xi Ruoyao
     [not found]                   ` <CAGt5VgFTLteAH1QyVn_7r2wHJab57enY3vrUMWU8UFi-D14msA@mail.gmail.com>
2022-09-24  9:51                     ` Xi Ruoyao
2022-09-24 10:20                       ` Jonathan Wakely
2022-09-23 17:14         ` David Brown

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).