-b vs -bundle

[Geoff Keating]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2410 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20050801/e8c5c9c7/attachment.p7s>