RFC: fcode-utils portability

[Andreas Färber]

Hello,

When compiling the FCode utils on Mac OS X v10.5 I got an error when  
stripping. A workaround was to run `make STRIP=:`, not stripping at all.

I now figured out that it's about the -s option: -s is short for -- 
strip-all in GNU strip but in Apple's strip -s references a text file  
with a list of symbols to preserve. I didn't spot an obvious  
equivalent to --strip-all.
http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPag...

Since the fcode-utils use pure Makefiles without prior art of platform- 
based decisions, I am wondering how to best supply a patch...

Should the hardcoded -s be moved to a new STRIPFLAGS variable or into  
STRIP itself?
And more important, how would we set either variable based on  
platform? Do we assume GNU make so that we can get the platform via $ 
(shell sh - c 'uname -s 2>/dev/null') or similar, as seen in Git?  
Creating a configure script seems like overkill for such a tiny fix.

Thanks,

Andreas

[Stefan Reinauer]

Andreas Färber schrieb:
> Hello,
>
> When compiling the FCode utils on Mac OS X v10.5 I got an error when 
> stripping. A workaround was to run `make STRIP=:`, not stripping at all.
>
> I now figured out that it's about the -s option: -s is short for 
> --strip-all in GNU strip but in Apple's strip -s references a text 
> file with a list of symbols to preserve. I didn't spot an obvious 
> equivalent to --strip-all.
> http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPag...
>
> Since the fcode-utils use pure Makefiles without prior art of 
> platform-based decisions, I am wondering how to best supply a patch...

Generally a unified diff (as created by svn diff) is preferred.
> Should the hardcoded -s be moved to a new STRIPFLAGS variable or into 
> STRIP itself?

I looked into the Makefile and there is no particular reason why to 
choose --strip-all at all. The savings are minimal, but it's only 
supported on GNU binutils. So I decided to drop it. Maybe we should just 
drop stripping the binaries completely. They're tiny anyways.

I checked in a trivial fix... please let me know if you still have 
problems...
> And more important, how would we set either variable based on 
> platform? Do we assume GNU make so that we can get the platform via 
> $(shell sh - c 'uname -s 2>/dev/null') or similar, as seen in Git? 
> Creating a configure script seems like overkill for such a tiny fix.

Yes, let's assume GNU make.

Best regards,
Stefan

[Andreas Färber]

Hello Stefan,

Thanks a lot!

Am 29.11.2009 um 14:57 schrieb Stefan Reinauer:
> Andreas Färber schrieb:
> > When compiling the FCode utils on Mac OS X v10.5 I got an error  
> > when stripping. [...]
> >
> > I now figured out that it's about the -s option: -s is short for -- 
> > strip-all in GNU strip but in Apple's strip -s references a text  
> > file with a list of symbols to preserve. I didn't spot an obvious  
> > equivalent to --strip-all.
> > http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPag...
> >
> > Since the fcode-utils use pure Makefiles without prior art of  
> > platform-based decisions, I am wondering how to best supply a  
> > patch...
>
> Generally a unified diff (as created by svn diff) is preferred.

Not what I meant! ;)
> I looked into the Makefile and there is no particular reason why to  
> choose --strip-all at all. The savings are minimal, but it's only  
> supported on GNU binutils. So I decided to drop it. Maybe we should  
> just drop stripping the binaries completely. They're tiny anyways.
>
> I checked in a trivial fix... please let me know if you still have  
> problems...

Builds fine now, but with -Wno-pointer-sign replaced by -Wextra it now  
spits loads of warnings.

Host compiler is: powerpc-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple  
Inc. build 5465)

Regards,

Andreas