* -b vs -bundle @ 2005-07-31 19:06 Jack Howarth 2005-08-01 20:28 ` Geoff Keating 2005-08-04 4:30 ` James E Wilson 0 siblings, 2 replies; 10+ messages in thread From: Jack Howarth @ 2005-07-31 19:06 UTC (permalink / raw) To: geoffk; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: -b vs -bundle 2005-07-31 19:06 -b vs -bundle Jack Howarth @ 2005-08-01 20:28 ` Geoff Keating 2005-08-04 4:30 ` James E Wilson 1 sibling, 0 replies; 10+ messages in thread From: Geoff Keating @ 2005-08-01 20:28 UTC (permalink / raw) To: Jack Howarth; +Cc: gcc [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: -b vs -bundle 2005-07-31 19:06 -b vs -bundle Jack Howarth 2005-08-01 20:28 ` Geoff Keating @ 2005-08-04 4:30 ` James E Wilson 2005-08-04 12:44 ` Peter O'Gorman 1 sibling, 1 reply; 10+ messages in thread From: James E Wilson @ 2005-08-04 4:30 UTC (permalink / raw) To: Jack Howarth; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: -b vs -bundle 2005-08-04 4:30 ` James E Wilson @ 2005-08-04 12:44 ` Peter O'Gorman 2005-08-05 3:14 ` James E Wilson 0 siblings, 1 reply; 10+ messages in thread From: Peter O'Gorman @ 2005-08-04 12:44 UTC (permalink / raw) To: James E Wilson; +Cc: Jack Howarth, gcc, gcc-patches, Geoff Keating [-- 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; ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: -b vs -bundle 2005-08-04 12:44 ` Peter O'Gorman @ 2005-08-05 3:14 ` James E Wilson 2005-08-05 3:57 ` Peter O'Gorman 0 siblings, 1 reply; 10+ messages in thread From: James E Wilson @ 2005-08-05 3:14 UTC (permalink / raw) To: Peter O'Gorman; +Cc: Jack Howarth, gcc, gcc-patches, Geoff Keating 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: -b vs -bundle 2005-08-05 3:14 ` James E Wilson @ 2005-08-05 3:57 ` Peter O'Gorman 2005-08-07 2:42 ` James E Wilson 0 siblings, 1 reply; 10+ messages in thread From: Peter O'Gorman @ 2005-08-05 3:57 UTC (permalink / raw) To: James E Wilson; +Cc: Jack Howarth, gcc, gcc-patches, Geoff Keating [-- 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: -b vs -bundle 2005-08-05 3:57 ` Peter O'Gorman @ 2005-08-07 2:42 ` James E Wilson 0 siblings, 0 replies; 10+ messages in thread From: James E Wilson @ 2005-08-07 2:42 UTC (permalink / raw) To: Peter O'Gorman; +Cc: Jack Howarth, gcc, gcc-patches, Geoff Keating 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: -b vs -bundle @ 2005-08-01 20:47 Jack Howarth 2005-08-01 20:52 ` Geoff Keating 0 siblings, 1 reply; 10+ messages in thread From: Jack Howarth @ 2005-08-01 20:47 UTC (permalink / raw) To: geoffk, howarth; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: -b vs -bundle 2005-08-01 20:47 Jack Howarth @ 2005-08-01 20:52 ` Geoff Keating 0 siblings, 0 replies; 10+ messages in thread From: Geoff Keating @ 2005-08-01 20:52 UTC (permalink / raw) To: Jack Howarth; +Cc: gcc [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: -b vs -bundle @ 2005-08-01 21:27 Jack Howarth 0 siblings, 0 replies; 10+ messages in thread From: Jack Howarth @ 2005-08-01 21:27 UTC (permalink / raw) To: geoffk, howarth; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2005-08-07 2:42 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-07-31 19:06 -b vs -bundle Jack Howarth 2005-08-01 20:28 ` Geoff Keating 2005-08-04 4:30 ` James E Wilson 2005-08-04 12:44 ` Peter O'Gorman 2005-08-05 3:14 ` James E Wilson 2005-08-05 3:57 ` Peter O'Gorman 2005-08-07 2:42 ` James E Wilson 2005-08-01 20:47 Jack Howarth 2005-08-01 20:52 ` Geoff Keating 2005-08-01 21:27 Jack Howarth
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).