Re: -b vs -bundle

Re: -b vs -bundle

[Jack Howarth]

Geoff,
   What I don't understand is how Apple's compiler can parse the
-bundle as the first argument and the gnu gcc compiler can't. 
Shouldn't the same mechanism Apple uses to allow this to work
be backportable into gnu gcc?
         Jack

Re: -b vs -bundle

[Geoff Keating]

[-- Attachment #1: Type: text/plain, Size: 618 bytes --]


On 01/08/2005, at 1:44 PM, Jack Howarth wrote:

> Geoff,
>    What I don't understand is how Apple's compiler can parse the
> -bundle as the first argument and the gnu gcc compiler can't.
> Shouldn't the same mechanism Apple uses to allow this to work
> be backportable into gnu gcc?

No.  There's lots of stuff in Apple's compiler that isn't written  
portably enough to work in GNU GCC.

My suggestion, if you're interested in fixing this, is to read

http://gcc.gnu.org/ml/gcc-patches/2002-12/msg00736.html

and fix the problems I mentioned there in the patch that Devang  
submitted, and submit a fixed version.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2410 bytes --]

Re: -b vs -bundle

[Jack Howarth]

Geoff,
   The problem is that I haven't ever submitted any paperwork so
anything I touch will be tainted. If you could post a revised patch
that applies to gcc main trunk, I'll test it locally and confirm
that it works.
          Jack

-b vs -bundle

[Jack Howarth]

      In compiling xplor-nih under the gcc/g++ of 4.1 branch instead
of Apple's gcc/g++ 4.0 compilers from Xcode 2.1, I noticed that the
gnu gcc compiler doesn't gracefully handle the -bundle flag. On Apple's
compiler I can have a Makefile entry like...

createSharedModule = $(CXX) -bundle  \
        -flat_namespace -undefined suppress $^ -o $@

and it compiles the shared module without error. However I see the
error...

g++-4 -bundle -flat_namespace -undefined suppress _xplorWrap.o libswigpy-xplor.dylib -o _xplorWrap.so -L/Users/howarth/Desktop/xplor-nih-2.11.2.1/bin.Darwin_8/ -lcommon -lnmrPot -lintVar -lvmd -lpy  -lswigpy-xplor \
             -lcrypto -L/Users/howarth/Desktop/xplor-nih-2.11.2.1/bin.Darwin_8/
g++-4: couldn't run 'undle-gcc-4.1.0': No such file or directory

with the gnu gcc compiler. I noticed that you rejected a proposed patch
a few years ago...

http://gcc.gnu.org/ml/gcc-patches/2002-12/msg00655.html
http://gcc.gnu.org/ml/gcc-patches/2002-10/msg01961.html

Could you revisit this issue and see if something could be done for 4.0
and 4.1 branch? I would think that either the compiler should require the
-b flag to have a space before the machine name. Alternatively if the
gnu gcc compiler mustn't allow -bundle to be the first argument passed
to the compiler, it should at least treat that as a defined error rather
than producing the cryptic one it does now. Thanks in advance for looking
at this again.
                    Jack

Re: -b vs -bundle

[Geoff Keating]

[-- Attachment #1: Type: text/plain, Size: 1813 bytes --]


On 31/07/2005, at 12:03 PM, Jack Howarth wrote:


>       In compiling xplor-nih under the gcc/g++ of 4.1 branch instead
> of Apple's gcc/g++ 4.0 compilers from Xcode 2.1, I noticed that the
> gnu gcc compiler doesn't gracefully handle the -bundle flag. On  
> Apple's
> compiler I can have a Makefile entry like...
>
> createSharedModule = $(CXX) -bundle  \
>         -flat_namespace -undefined suppress $^ -o $@
>
> and it compiles the shared module without error. However I see the
> error...
>
> g++-4 -bundle -flat_namespace -undefined suppress _xplorWrap.o  
> libswigpy-xplor.dylib -o _xplorWrap.so -L/Users/howarth/Desktop/ 
> xplor-nih-2.11.2.1/bin.Darwin_8/ -lcommon -lnmrPot -lintVar -lvmd - 
> lpy  -lswigpy-xplor \
>              -lcrypto -L/Users/howarth/Desktop/xplor-nih-2.11.2.1/ 
> bin.Darwin_8/
> g++-4: couldn't run 'undle-gcc-4.1.0': No such file or directory
>
> with the gnu gcc compiler. I noticed that you rejected a proposed  
> patch
> a few years ago...
>
> http://gcc.gnu.org/ml/gcc-patches/2002-12/msg00655.html
> http://gcc.gnu.org/ml/gcc-patches/2002-10/msg01961.html
>
> Could you revisit this issue and see if something could be done for  
> 4.0
> and 4.1 branch? I would think that either the compiler should  
> require the
> -b flag to have a space before the machine name. Alternatively if the
> gnu gcc compiler mustn't allow -bundle to be the first argument passed
> to the compiler, it should at least treat that as a defined error  
> rather
> than producing the cryptic one it does now. Thanks in advance for  
> looking
> at this again.
>

Hi Jack,

I believe everything I said back then is still valid.  See especially  
<http://gcc.gnu.org/ml/gcc-patches/2002-12/msg00693.html>.

I don't think we can require -b to have a space; that would break  
existing scripts.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2410 bytes --]

Re: -b vs -bundle

[James E Wilson]

Jack Howarth wrote:
>       In compiling xplor-nih under the gcc/g++ of 4.1 branch instead
> of Apple's gcc/g++ 4.0 compilers from Xcode 2.1, I noticed that the
> gnu gcc compiler doesn't gracefully handle the -bundle flag. On Apple's
> compiler I can have a Makefile entry like...

This is PR 21366.

You can always work around this by using -Wl,-bundle, which is the FSF 
solution to handling linker flags.  Or don't put -bundle first on the 
command line.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: -b vs -bundle

[Peter O'Gorman]

[-- Attachment #1: Type: text/plain, Size: 2182 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James E Wilson wrote:
| Jack Howarth wrote:
|
|>       In compiling xplor-nih under the gcc/g++ of 4.1 branch instead
|> of Apple's gcc/g++ 4.0 compilers from Xcode 2.1, I noticed that the
|> gnu gcc compiler doesn't gracefully handle the -bundle flag. On Apple's
|> compiler I can have a Makefile entry like...
|
|
| This is PR 21366.
|
| You can always work around this by using -Wl,-bundle, which is the FSF
| solution to handling linker flags.  Or don't put -bundle first on the
| command line.

This is based very much on the work done previously by Geoff and Devang.

If this is okay, could the approver please commit, I do not have write access.

"Tested" as follows:
imac% ./xgcc -v
Using built-in specs.
Target: powerpc-apple-darwin8.2.0
Configured with: ../configure --enable-languages=c
Thread model: posix
gcc version 4.1.0 20050804 (experimental)
imac% ./xgcc -V4.0
xgcc: couldn't run './powerpc-apple-darwin8.2.0-gcc-4.0': No such file or
directory
imac% ./xgcc -V4.0 -bhello
xgcc: couldn't run './powerpc-apple-darwin8.2.0-gcc-4.0': No such file or
directory
imac% ./xgcc -V4.0 -bhello-there
xgcc: couldn't run './hello-there-gcc-4.0': No such file or directory
imac% ./xgcc -bhello-there
xgcc: couldn't run './hello-there-gcc-4.1.0': No such file or directory
imac% ./xgcc -bhello-there -V4.0
xgcc: couldn't run './hello-there-gcc-4.0': No such file or directory
imac% ./xgcc -bhello -V4.0
xgcc: '-V' must come at the start of the command line
imac% ./xgcc -V4.0 -bob
xgcc: couldn't run './powerpc-apple-darwin8.2.0-gcc-4.0': No such file or
directory
imac% ./xgcc  -bob
xgcc: unrecognized option '-bob'
xgcc: no input files
imac% ./xgcc  -bob-most
xgcc: couldn't run './ob-most-gcc-4.1.0': No such file or directory
imac% ./xgcc  why -bob-most
xgcc: '-b' must come at the start of the command line


Thanks,
Peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)

iQCVAwUBQvINDbiDAg3OZTLPAQIkEQP+JNU3mHlOX5ZB0XXXltg7q+N8a9KX8N+o
TOsB3F2iJVjpWKEDWA1waJrmFeWSkdeozgRlcfU4QwAqGe5TiHlqFBSRGS2YPAwa
ag6NWDXdTP+FNyNGSwYud44CBH2+BakdoyPuR95VKP5bLoqu7KDVgKfJmRXyqM+o
R6aj4pthQRc=
=C9Iw
-----END PGP SIGNATURE-----

[-- Attachment #2: dash-b-arg-needs-a-dash.patch --]
[-- Type: text/plain, Size: 1682 bytes --]

2005-08-04  Peter O'Gorman  <peter@pogma.com>

	PR 21366
	* gcc.c (process_command): Check the argument to -b has a dash.

Index: gcc/gcc.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/gcc.c,v
retrieving revision 1.469
diff -u -3 -p -u -r1.469 gcc.c
--- gcc/gcc.c	3 Aug 2005 23:35:06 -0000	1.469
+++ gcc/gcc.c	4 Aug 2005 12:35:05 -0000
@@ -3175,9 +3175,12 @@ process_command (int argc, const char **
     }
 
   /* If there is a -V or -b option (or both), process it now, before
-     trying to interpret the rest of the command line.  */
+     trying to interpret the rest of the command line. 
+     Use heuristic that all copnfiguration names must have at least
+     one dash '-'. This allows us to pass options starting with -b.  */
   if (argc > 1 && argv[1][0] == '-'
-      && (argv[1][1] == 'V' || argv[1][1] == 'b'))
+      && (argv[1][1] == 'V' || 
+	 ((argv[1][1] == 'b') && (NULL != strchr(argv[1] + 2,'-')))))
     {
       const char *new_version = DEFAULT_TARGET_VERSION;
       const char *new_machine = DEFAULT_TARGET_MACHINE;
@@ -3187,7 +3190,8 @@ process_command (int argc, const char **
       int baselen;
 
       while (argc > 1 && argv[1][0] == '-'
-	     && (argv[1][1] == 'V' || argv[1][1] == 'b'))
+	     && (argv[1][1] == 'V' ||
+		((argv[1][1] == 'b') && ( NULL != strchr(argv[1] + 2,'-')))))
 	{
 	  char opt = argv[1][1];
 	  const char *arg;
@@ -3608,6 +3612,7 @@ warranty; not even for MERCHANTABILITY o
 	  switch (c)
 	    {
 	    case 'b':
+	      if (NULL == strchr(argv[i] + 2, '-')) break;
 	    case 'V':
 	      fatal ("'-%c' must come at the start of the command line", c);
 	      break;

Re: -b vs -bundle

[James E Wilson]

On Thu, 2005-08-04 at 05:41, Peter O'Gorman wrote:
> +     trying to interpret the rest of the command line. 
> +     Use heuristic that all copnfiguration names must have at least
> +     one dash '-'. This allows us to pass options starting with -b.  */

There is a typo here copnfiguration->configuration.

There are a number of valid configurations that do not contain a hyphen,
though they are not commonly used.  For instance configuring for
--target=mips will give you a mips-elf toolchain that will install a
mips-gcc executable.  I think it is reasonable to discourage use of such
ambiguous target names here.  It helps that -b is also not commonly
used.

However, we do need to document this restriction.  In fact, if you look
at the docs for the -b option, it gives an example that will no longer
work.  (It is also an obsolete configuration.)  So the docs need to be
updated to mention that the machine name must contain a hyphen, and to
use a more reasonable target, like arm-elf perhaps.

While we are at it, we could perhaps fix the -V docs to mention a
realistic gcc version number too.  2.0 is a little too old to be useful.

This revised patch does appear to fix the only complaint that Geoff had
with the original patch.  I think it is OK with the typo fixed and the
addition of a doc change.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: -b vs -bundle

[Peter O'Gorman]

[-- Attachment #1: Type: text/plain, Size: 227 bytes --]

James E Wilson wrote:

> This revised patch does appear to fix the only complaint that Geoff had
> with the original patch.  I think it is OK with the typo fixed and the
> addition of a doc change.

OK, done.
Thank you.

Peter

[-- Attachment #2: dash-b-arg-needs-a-dash-2.patch --]
[-- Type: text/plain, Size: 3056 bytes --]

2005-08-??  Peter O'Gorman  <peter@pogma.com>

	PR 21366
	* gcc.c (process_command): Check the argument to -b has a dash.
	* doc/invoke.texi: Update -b and -V docs.

Index: gcc/gcc.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/gcc.c,v
retrieving revision 1.469
diff -u -3 -p -u -r1.469 gcc.c
--- gcc/gcc.c	3 Aug 2005 23:35:06 -0000	1.469
+++ gcc/gcc.c	5 Aug 2005 03:54:08 -0000
@@ -3175,9 +3175,12 @@ process_command (int argc, const char **
     }
 
   /* If there is a -V or -b option (or both), process it now, before
-     trying to interpret the rest of the command line.  */
+     trying to interpret the rest of the command line. 
+     Use heuristic that all configuration names must have at least
+     one dash '-'. This allows us to pass options starting with -b.  */
   if (argc > 1 && argv[1][0] == '-'
-      && (argv[1][1] == 'V' || argv[1][1] == 'b'))
+      && (argv[1][1] == 'V' || 
+	 ((argv[1][1] == 'b') && (NULL != strchr(argv[1] + 2,'-')))))
     {
       const char *new_version = DEFAULT_TARGET_VERSION;
       const char *new_machine = DEFAULT_TARGET_MACHINE;
@@ -3187,7 +3190,8 @@ process_command (int argc, const char **
       int baselen;
 
       while (argc > 1 && argv[1][0] == '-'
-	     && (argv[1][1] == 'V' || argv[1][1] == 'b'))
+	     && (argv[1][1] == 'V' ||
+		((argv[1][1] == 'b') && ( NULL != strchr(argv[1] + 2,'-')))))
 	{
 	  char opt = argv[1][1];
 	  const char *arg;
@@ -3608,6 +3612,7 @@ warranty; not even for MERCHANTABILITY o
 	  switch (c)
 	    {
 	    case 'b':
+	      if (NULL == strchr(argv[i] + 2, '-')) break;
 	    case 'V':
 	      fatal ("'-%c' must come at the start of the command line", c);
 	      break;
Index: gcc/doc/invoke.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/invoke.texi,v
retrieving revision 1.664
diff -u -3 -p -u -r1.664 invoke.texi
--- gcc/doc/invoke.texi	3 Aug 2005 16:35:10 -0000	1.664
+++ gcc/doc/invoke.texi	5 Aug 2005 03:54:14 -0000
@@ -6943,14 +6943,16 @@ The argument @var{machine} specifies the
 The value to use for @var{machine} is the same as was specified as the
 machine type when configuring GCC as a cross-compiler.  For
 example, if a cross-compiler was configured with @samp{configure
-i386v}, meaning to compile for an 80386 running System V, then you
-would specify @option{-b i386v} to run that cross compiler.
+arm-elf}, meaning to compile for an arm processor with elf binaries,
+then you would specify @option{-b arm-elf} to run that cross compiler.
+Because there are other options beginning with @option{-b}, the
+configuration must contain a hyphen. 
 
 @item -V @var{version}
 @opindex V
 The argument @var{version} specifies which version of GCC to run.
 This is useful when multiple versions are installed.  For example,
-@var{version} might be @samp{2.0}, meaning to run GCC version 2.0.
+@var{version} might be @samp{4.0}, meaning to run GCC version 4.0.
 @end table
 
 The @option{-V} and @option{-b} options work by running the

Re: -b vs -bundle

[James E Wilson]

On Thu, 2005-08-04 at 20:54, Peter O'Gorman wrote:
> 2005-08-??  Peter O'Gorman  <peter@pogma.com>
> 	PR 21366
> 	* gcc.c (process_command): Check the argument to -b has a dash.
> 	* doc/invoke.texi: Update -b and -V docs.

I checked in the patch.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com