Figuring out gcc options...
Sync
why many people out there have been suggesting to create a wrapper
"gcc" shell script that passes the desired config changes in on the
command line and ignore the specs file usage entirely...
I'm using gcc 4.0.0 on AIX, from the IBM toolbox. We're trying to
move some stuff from xlC to gcc. Under xlC we are using the
chars=signed default option. This was done originally as the code
was ported from a legacy environment where signed chars was native.
After some digging I find that the way to change the default char
handling behavior in gcc is to add -fsigned-char to the specs file. I
locate a note on the web that indicates the location of the specs file
is in the same directory as the cc1 file, and that can be found with a
command line option to gcc. However, there is no specs file in that
directory. Later I find that "gcc -v" will tell me what it's using as
a specs file, and it returns "using built-in specs." I then find that
-dumpspecs will output the specs, so I create a specs file in the cc1
directory using "gcc -dumpspecs" to produce it. So far, I haven't
edited the file at all, I'm just trying to get gcc to use the darn
thing. However, "gcc -v" still says "using built-in specs."
I then resort to using a wrapper script named "gcc" calling
"gcc.bin" (renamed from the originally installed gcc) and use the
following:
/opt/freeware/bin/gcc.bin -specs=/opt/freeware/libexec/gcc/powerpc-ibm-
aix5.1.0.0/4.0.0 $*
In an attempt to get it to pay attention to the specs file. But now
when I run "gcc -v" I get the following:
Using built-in specs.
Reading specs from /opt/freeware/libexec/gcc/powerpc-ibm-
aix5.1.0.0/4.0.0
gcc.bin: specs file malformed after 3 characters
Note, that this specs file is the file PRODUCED by "gcc -dumpspecs"
and hasn't yet been edited. Apparently, the format produced by -
dumpspecs is NOT in specs file format!
And interestingly, if I completely null out the specs file, I STILL
get the same response-- malformed after 3 chars.
And the gnu online docs for specs is not much help at this point:
<http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Spec-Files.html>
So, just how do you put together a specs file that works with gcc?
And do I have to wrapper gcc with a script to use it if it insists on
"using built-in specs"? Somehow I rather doubt that wrappering the
binary is what the gcc developers had in mind WRT the specs file...
--
Sync
Larry Smith
Hmm I may be wrong, but...
As I remember, the spec file is used to build gcc
(when gcc itself is compiled); it is not used when
gcc runs.
Just read the 'man' & 'info' pages for gcc, and set
the appropriate flags into CFLAGS in the "Makefile"
for your application (or on the command line if
you are manually invoking gcc).
We always set CFLAGS, CPPFLAGS, CXXFLAGS, etc in
our project Makefile to ensure that the same
options are in affect on all of the platforms
upon which we build our app (Linux, AIX, Solaris).
Paul Pluzhnikov
> After spending some time struggling with a gcc "specs" file, I can see
> why many people out there have been suggesting to create a wrapper
> "gcc" shell script that passes the desired config changes in on the
> command line and ignore the specs file usage entirely...
The 'specs' file is *not* intended to be modified by end-users.
And you don't need a 'wrapper' shell script. What you need is
a proper Makefile, which will pass all the desired options on
command line.
> I then resort to using a wrapper script named "gcc" calling
> "gcc.bin" (renamed from the originally installed gcc) and use the
> following:
>
> /opt/freeware/bin/gcc.bin -specs=/opt/freeware/libexec/gcc/powerpc-ibm-aix5.1.0.0/4.0.0 $*
The '-specs=' is supposed to point gcc to a specs *file*, not to
the directory in which it resides.
You are making another common novice mistake here.
Never ever use '$*' in your shell scripts, use "$@" instead (do
include quotes).
The proper "wrapper" is:
#!/bin/sh
exec /opt/freeware/bin/gcc.bin \
-specs=/opt/freeware/libexec/gcc/powerpc-ibm-aix5.1.0.0/4.0.0/specs "$@"
> gcc.bin: specs file malformed after 3 characters
>
> Note, that this specs file is the file PRODUCED by "gcc -dumpspecs"
> and hasn't yet been edited. Apparently, the format produced by -
> dumpspecs is NOT in specs file format!
You've come to the wrong conclusion. The output from 'gcc -dumpspecs'
*is* in perfectly acceptable format.
> And interestingly, if I completely null out the specs file, I STILL
> get the same response-- malformed after 3 chars.
PEBKAC.
> So, just how do you put together a specs file that works with gcc?
You don't. It is very unusual to need to modify specs at all.
I have a feeling that you don't know/use make. If so, I *strongly*
advise you to rectify that, and forget about the "wrapper" idea.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
Paul Pluzhnikov
> As I remember, the spec file is used to build gcc
> (when gcc itself is compiled); it is not used when
> gcc runs.
The inverse is true: whenever gcc runs, it uses either built-in
specs, or a specs file in one of its installation directories.
Syncopator
> Sync <kd...@hotmail.com> writes:
> And you don't need a 'wrapper' shell script. What you need is
> a proper Makefile, which will pass all the desired options on
> command line.
No, I have dozens of "proper Makefiles." As I said, all developed on
a system where chars = signed was native. What I need is to make gcc
default to it like was done with xlC via /etc/xlC.cfg. It appeared
that the "specs" file was gcc's equivalent to xlC.cfg.
> You've come to the wrong conclusion. The output from 'gcc -dumpspecs'
> *is* in perfectly acceptable format.
Thanks, that was a dumb oversight on my part...
> > So, just how do you put together a specs file that works with gcc?
>
> You don't. It is very unusual to need to modify specs at all.
How unusual is it to need gcc to default to chars = signed?
> I have a feeling that you don't know/use make. If so, I *strongly*
> advise you to rectify that, and forget about the "wrapper" idea.
No I do know how to use make-- but this project has dozens of
makefiles and thousands of source files all of which were written on a
system where chars = signed was the default. Configuring xlC to
default to that behavior was the approach we took when porting to AIX,
it seems perfectly reasonable to do the same when moving to gcc.
Fortunately, you have identified the gaffe's I was making, and
clarified that in order to modify specs I need to wrapper gcc because
unlike what it says in this faq about it:
http://www.gnu.org/software/gcc/faq.html
a specs file in "the same directory that contains cc1" does NOT
automatically get utilized, it needs to be explicitly specified on the
command line.
However, while I've now been able to make a custom specs file work
given your tips, I've also found that simply setting 'export CC="gcc -
fsigned-char"' also gets the job done, and IMHO is preferrable to
wrappering gcc...
--
Sync
Paul Pluzhnikov
>> And you don't need a 'wrapper' shell script. What you need is
>> a proper Makefile, which will pass all the desired options on
>> command line.
>
> No, I have dozens of "proper Makefiles."
If it is difficult to add '-fsigned-chars' to CFLAGS in a *single*
place and have that setting take effect everywhere, then your
Makefiles aren't proper.
You may need to use more powerful make (such as GNU make),
and also read this: http://miller.emu.id.au/pmiller/books/rmch/
> As I said, all developed on
> a system where chars = signed was native. What I need is to make gcc
> default to it like was done with xlC via /etc/xlC.cfg. It appeared
> that the "specs" file was gcc's equivalent to xlC.cfg.
Modifying compiler configuration to do "non-standard" compilation is
(IMHO) much worse than adding a command-line switch: with command
line I can *see* that chars are signed; with 'specs' modification
I can't (and wouldn't even know that something non-standard is
happening).
Also, you'll have to remember to update specs every time you switch
to a new version of gcc.
> How unusual is it to need gcc to default to chars = signed?
Not very. But this is easily achieved on command line, and if
it's difficult to modify command line, then you have a broken
build system.
> Fortunately, you have identified the gaffe's I was making, and
> clarified that in order to modify specs I need to wrapper gcc
I didn't say that; and it's incorrect.
> a specs file in "the same directory that contains cc1" does NOT
> automatically get utilized, it needs to be explicitly specified on the
> command line.
The first part of the statement above is true, but the second is false.
My gcc-4.0.0, built on Linux/x86_64 with --prefix=/usr/local/gcc-4.0.0
contains 'cc1' in
/usr/local/gcc-4.0.0/libexec/gcc/x86_64-unknown-linux-gnu/4.0.0
and does not look for 'specs' in that location.
But it *does* look for 'specs' in the following locations:
/usr/local/gcc-4.0.0/lib/gcc/x86_64-unknown-linux-gnu/4.0.0/specs
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.0.0/specs
/usr/local/gcc-4.0.0/x86_64-unknown-linux-gnu/lib/x86_64-unknown-linux-gnu/4.0.0/specs
/usr/local/gcc-4.0.0/x86_64-unknown-linux-gnu/lib/specs
/usr/local/gcc-4.0.0/lib/gcc/x86_64-unknown-linux-gnu/specs
and putting 'specs' into any one of these directories removes the
need for a wrapper script.
> However, while I've now been able to make a custom specs file work
> given your tips, I've also found that simply setting 'export CC="gcc -
> fsigned-char"' also gets the job done, and IMHO is preferrable to
> wrappering gcc...
This is better than modifying 'specs', but this isn't really
a preferred solution, because now your build depends on environment,
and sooner or later you'll build something with 'CC' not exported,
and then spend hours or days trying to find out why this build
fails in mysterious ways, while another build from the same source
works fine.
Ideally, you simply get sources from your revision control system,
cd into top-level directory, and get a complete and consistent
build regardless of PATH, CC, or any other environment variable.
Lionel B
> Syncopator <synco...@gmail.com> writes:
>
>>> And you don't need a 'wrapper' shell script. What you need is a proper
>>> Makefile, which will pass all the desired options on command line.
>>
>> No, I have dozens of "proper Makefiles."
>
> If it is difficult to add '-fsigned-chars' to CFLAGS in a *single* place
> and have that setting take effect everywhere, then your Makefiles aren't
> proper.
I generally have a Makefile.proj (say) at the root of some project tree
containing project-specific options: e.g.
CFLAGS += -fsigned-chars
and then insure that it is included in all higher level Makefiles (that's
pretty standard, I think - and how difficult can it be to implement for
"dozens" of Makefiles?). Then you can *see* what options you're invoking
gcc with.
--
Lionel B
Andrew Haley
> How unusual is it to need gcc to default to chars = signed?
It's not, but changing it bt hacking the specfile is're doing it the
wrong way. The right way to do it is a target macro,
DEFAULT_SIGNED_CHAR. It's documented in the gcc internals manual.
It's usually defined in the target config dir
(e.g. gcc/config/i386/i386.h):
/* Define this as 1 if `char' should by default be signed; else as 0. */
#define DEFAULT_SIGNED_CHAR 1
It's not usual to change the deafult in the compiler because the
signedness of characters is part of the system ABI.
Andrew.
Sync
wrote:
This would be much better. We do have a common include file that
contains platform dependent defines and this would be the perfect
place for this sort of thing. However, it does not appear that this
works on the AIX version I've got-- EVERYTHING in the AIX version is
installed in /opt/freeware, there's no /usr/lib/gcc* nor /usr/local/
gcc* anything, and I did a find/grep on the entire tree looking for
anything that might contain the string DEFAULT_SIGNED_CHAR which came
up empty. I tried a simple program to test it and did an undef/
define of it but continued to get unsigned chars. So while I'd be
happy to do it this way, it doesn't appear to be supported on the IBM
Toolbox for Linux apps gcc v4.0.0. The gcc internals manual indicates
its defined in machine.h, but there is no machine.h or config.h
anywhere on my system. The manual does claim to apply to gcc 4.3.0,
and what I've got is 4.0.0 so I presume this is a relatlvely new
feature.
For now, I'll stick with what IBM is distributing. I WAS able to find
a directory where gcc WILL use a specs file without having to wrapper
it, and so far that's the approach I'm using. The directory on for
the AIX toolbox gcc is opt/freeware/lib/gcc/powerpc-ibm-
aix5.1.0.0/4.0.0/
if anyone's interested.
WRT "incorrect" makefiles, that's irrelevant as that's the way they
are-- for one thing, there are top level make files that run other
makefiles, and module makefiles, and they can be run independently--
in order for module makefiles to be compiled independently their
CFLAGS would have to either be set in the makefile or inherited from
the enviroment. I didn't design this setup, its nearly 20 years old,
and that's what we have-- build environment CFLAGS settings weren't
utilized, instead each independently buildable makefile has its own
CFLAGS definition. I can't get too worried about it as they've been
working fine like that for decades-- in short, it ain't broke.
When moving from an original AT&T Unix to AIX, it was found that the
chars=signed differed, and that xlC provided a compiler configuration
to change this default behavior. A subsequent move to SCO Unix I
believe didn't even require this as it already defaulted to
chars=signed, though I'm not positive about that. Suffice it to say,
a simple build test on our sco development box also shows that chars
are signed.
This codebase as I said is nearing 20 years old, and there's virtually
noone still here who was around at that time-- the application is very
stable and hasn't been rebuilt for ANY platform in a good 10 years.
It's been running on hundreds of AIX and SCO systems in that time,
surviving virtually unchanged through updates from AIX 3.2.4 through
AIX 5.2, and several SCO Openserver versions up to 5.0.7. However,
as the future availability of SCO is in question, and in any event
5.0.7 has been supplanted by 6, we've been looking toward a move to
Linux as an alternative. The less we have to change the codebase the
better, as it's large, the expertise on it no longer exists, and we
still need the source tree to build successfully on AIX and SCO.
Configuring new platform build conditions to model original conditions
is by no means an unreasonable or uncommon approach to porting, and is
usually less effort, disagreements about the elegance of it
notwithstanding.
--
Sync
Paul Pluzhnikov
> On Jan 10, 1:37 pm, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>>
>> It's not, but changing it bt hacking the specfile is're doing it the
>> wrong way. The right way to do it is a target macro,
>> DEFAULT_SIGNED_CHAR. It's documented in the gcc internals manual.
You missed an important step: after changing this macro, rebuild 'gcc'.
Since OP didn't even build his own 'gcc', but used a binary version
from elsewhere, and since this is even more work than simply adding
'-fsigned-chars', I somehow doubt that this is "the right way to
do it".
> This would be much better. We do have a common include file that
> contains platform dependent defines and this would be the perfect
> place for this sort of thing. However, it does not appear that this
> works on the AIX version
See above.
> I've got-- EVERYTHING in the AIX version is
> installed in /opt/freeware, there's no /usr/lib/gcc* nor /usr/local/
> gcc* anything, and I did a find/grep on the entire tree looking for
> anything that might contain the string DEFAULT_SIGNED_CHAR which came
> up empty.
There is a difference between what's installed in /opt/freeware,
and the source for gcc itself:
cd gcc-4.0.2; find . -type f | xargs grep -l DEFAULT_SIGNED_CHAR
...
./gcc/FSFChangeLog.10
./gcc/doc/tm.texi
./gcc/doc/gccint.info
./gcc/opts.c
./gcc/config/alpha/alpha.h
./gcc/config/alpha/unicosmk.h
./gcc/config/arc/arc.h
./gcc/config/arm/arm.h
...
> I tried a simple program to test it and did an undef/
> define of it but continued to get unsigned chars.
Naturally.
> WRT "incorrect" makefiles, ... in short, it ain't broke.
It *is* broken if you can't easily add a single flag to all of them.
If you aren't doing any maintenance on that software, then this
breakage is ok. But you are about to start major maintenance,
and it is not unreasonable to fix things that will make subsequent
porting easier.
Since you are about to port to Linux, expect many more changes that
you'll need to apply to all of the Makefiles. You can fix them now,
or you can fix them later, or you can edit each and every one of
them every time you discover that you need yet another change.
Sync
thing pleases or shocks me without my knowing the reason, and yet it shocks
me for that reason which I only discover afterwards." But I believe, not
that it shocked him for the reasons which were found afterwards, but that
these reasons were only found because it shocked him.
277. The heart has its reasons, which reason does not know. We feel it in a
thousand things. I say that the heart naturally loves the Universal Being,
and also itself naturally, according as it gives itself to them; and it
hardens itself against one or the other at its will. You have rejected the
one and kept the other. Is it by reason that you love yourself?
278. It is the heart which experiences God, and not the reason. This, then,
is faith: God felt by the heart, not by the reason.
Faith is a gift of God; do not believe that we said it was a gift of
reasoning. Other religions do not say this of their faith. They only give
reasoning in order to arrive at it, and yet it does not bring them to it.
279. Faith is a gift of God; do not believe that we said it was a gift of
reasoning. Other religions do not say this of their faith. They only gave
reasoning in order to arrive at it, and yet it does not bring them to it.
280. The knowledge of God is very far from the love of Him.
281. Heart, instinct, principles.
282. We know truth, not only by the reason, but also by the heart, and it is
in this last way that we know first principles; and reason, which has no
part in it, tries in vain to impugn them. The sceptics, who have only this
for their object, labour to no purpose. We know that we do not dream, and,
however impossible it is for us to prove it by reason, this inability
demonstrates only the weakness of our reason, but not, as they affirm, the
uncertainty of all our knowledge
Lionel B
man, because it is against his will. And although we bring it on ourselves,
it is nevertheless against our will that we sneeze. It is not in view of the
act itself; it is for another end. And thus it is not a proof of the
weakness of man and of his slavery under that action.
It is not disgraceful for man to yield to pain, and it is disgraceful to
yield to pleasure. This is not because pain comes to us from without, and we
ourselves seek pleasure; for it is possible to seek pain, and yield to it
purposely, without this kind of baseness. Whence comes it, then, that reason
thinks it honourable to succumb under stress of pain, and disgraceful to
yield to the attack of pleasure? It is because pain does not tempt and
attract us. It is we ourselves who choose it voluntarily, and will it to
prevail over us. So that we are masters of the situation; and in this man
yields to himself. But in pleasure it is man who yields to pleasure. Now
only mastery and sovereignty bring
Andrew Haley
"All things change and succeed each other." You are mistaken; there is...
228. Objection of atheists: "But we have no light."
229. This is what I see and what troubles me. I look on all sides, and I see
only darkness everywhere. Nature presents to me nothing which is not matter
of doubt and concern. If I saw nothing there which revealed a Divinity, I
would come to a negative conclusion; if I saw everywhere the signs of a
Creator, I would remain peacefully in faith. But, seeing too much to deny
and too little to be sure, I am in a state to be pitied; wherefore I have a
hundred times wished that if a God maintains Nature, she should testify to
Him unequivocally, and that, if the signs she gives are deceptive, she
should suppress them altogether; that she should say everything or nothing,
that I might see which cause I ought to follow. Whereas in my present state,
ignorant of what I am or of what I ought to do, I know neither my condition
nor my duty. My heart inclines wholly to know where is the true good, in
order to follow it; nothing would be too dear to me for eternity.
I envy those whom I see living in the faith with such carelessness and who
make such a bad use of a gift of which it seems to me I would make such a
different use.
230. It is incomprehensible that God should exist, and it is
incomprehensible that He should not exist; that the soul should be joined to
the body, and that we should have no soul; that the world should be created,
and that it should not be created, etc.; that original sin should be, and
that it should not be.
231. Do you believe it to be impossible that God is