Is it possible to get the source for qcc? I see the source is available
for binutils, etc. from cvs.qnx.com; can I get qcc there as well? Or
somewhere else?
Thx…
These are my opinions—Nortel Networks takes no responsibility for them.
%% “Paul D. Smith” <pausmith@nortelnetworks.com> writes:
pds> Is it possible to get the source for qcc?
Does anyone have any comments on this? Colin?
I’ve tried for over an hour to come up with some invocation of the
ntoppc-gcc program that will emulate qcc, but I can’t make it work. I
can see, using qcc -v, how qcc is invoking the various sub-programs and
I’m trying to invoke gcc in such a way that it gets the same flags, or
at least close enough so that my code compiles and links correctly, but
I’ve had absolutely no luck so far… 
One main problem is that I can’t use the default install directory for
the QNX tools, so I need to set QNX_HOST and QNX_TARGET. qcc sees those
values and modifies the subprocess invocation properly, but I can’t find
any invocation to mimic what it does from the gcc command line.
Help help help!
These are my opinions—Nortel Networks takes no responsibility for them.
Can you post the output of qcc -v please? What errors are you getting?
Configuration files for qcc are found in %QNX_HOST%\etc\qcc
Cheers,
-Brian
–
+===============================+
Brian K. Hlady
OEM Support Rep
QNX Software Systems, Ltd.
bhlady@qnx.com
+===============================+
“Paul D. Smith” <pausmith@nortelnetworks.com> wrote in message
news:p5ads2f02u.fsf@lemming.engeast.baynetworks.com…
%% “Paul D. Smith” <> pausmith@nortelnetworks.com> > writes:
pds> Is it possible to get the source for qcc?
Does anyone have any comments on this? Colin?
I’ve tried for over an hour to come up with some invocation of the
ntoppc-gcc program that will emulate qcc, but I can’t make it work. I
can see, using qcc -v, how qcc is invoking the various sub-programs and
I’m trying to invoke gcc in such a way that it gets the same flags, or
at least close enough so that my code compiles and links correctly, but
I’ve had absolutely no luck so far… >One main problem is that I can’t use the default install directory for
the QNX tools, so I need to set QNX_HOST and QNX_TARGET. qcc sees those
values and modifies the subprocess invocation properly, but I can’t find
any invocation to mimic what it does from the gcc command line.
Help help help!–
Paul D. Smith <> pausmith@nortelnetworks.com> > HASMAT–HA Software Mthds &
Tools
“Please remain calm…I may be mad, but I am a professional.” --Mad
Scientist
These are my opinions—Nortel Networks takes no responsibility for
them.
%% “Brian K. Hlady” <bhlady@qnx.com> writes:
bkh> Can you post the output of qcc -v please? What errors are you
bkh> getting? Configuration files for qcc are found in
bkh> %QNX_HOST%\etc\qcc
Hi Brian; let me reiterate so it’s clear: qcc does work, just fine.
It’s not a problem with qcc at all.
The “problem” is that I can’t convince standard ntoppc-gcc to work
correctly; it invokes the preprocessor (especially) with a different set
of flags than qcc does and that set of flags doesn’t work properly
(mainly the -isystem flag has the wrong path and I can’t work out a way
to get ntoppc-gcc to use the right values, in the right order).
I need to be able to create our build tools from source for various
reasons, and since I can’t figure out how to get the build to succeed
without using the qcc front-end the simplest thing for me would be to
get the source to it. Failing that I’ll have to come up with a
home-grown replacement unless I can figure out how to tweak ntoppc-gcc.
I actually talked to our account contact at QNX and I think things are
moving along via that route so hopefully I should be all set shortly.
Thanks for the reply!
These are my opinions—Nortel Networks takes no responsibility for them.
Hi, Paul.
gcc has a ‘specs’ file that does the same thing as our qcc conf files do,
basically defines how each stage of compiling will happen. If you run
‘ntoppc-gdb -dumpspecs’ you will see a list of the specs file that gcc
is using, either a builtin or an actual file.
If you redirect that output to another file ‘ntoppc-gcc -dumpspecs > specs.paul’
then you can edit the file and change it to do what you want. Then you can
invoke gcc as ‘ntoppc-gcc -specs=/path_to/specs.paul’, and you should see
your changes.
I have included a snippit from the gcc source that explains the specs file
format.
Hope this helps.
Regards,
GP
From gcc/gcc.c:
/* Specs are strings containing lines, each of which (if not blank)
is made up of a program name, and arguments separated by spaces.
The program name must be exact and start from root, since no path
is searched and it is unreliable to depend on the current working directory.
Redirection of input or output is not supported; the subprograms must
accept filenames saying what files to read and write.
In addition, the specs can contain %-sequences to substitute variable text
or for conditional text. Here is a table of all defined %-sequences.
Note that spaces are not generated automatically around the results of
expanding these sequences; therefore, you can concatenate them together
or with constant text in a single argument.
%% substitute one % into the program name or argument.
%i substitute the name of the input file being processed.
%b substitute the basename of the input file being processed.
This is the substring up to (and not including) the last period
and not including the directory.
%gSUFFIX
substitute a file name that has suffix SUFFIX and is chosen
once per compilation, and mark the argument a la %d. To reduce
exposure to denial-of-service attacks, the file name is now
chosen in a way that is hard to predict even when previously
chosen file names are known. For example, %g.s ... %g.o ... %g.s' might turn into ccUVUUAU.s ccXYAXZ12.o ccUVUUAU.s’. SUFFIX matches
the regexp "[.A-Za-z]" or the special string “%O”, which is
treated exactly as if %O had been pre-processed. Previously, %g
was simply substituted with a file name chosen once per compilation,
without regard to any appended suffix (which was therefore treated
just like ordinary text), making such attacks more likely to succeed.
%uSUFFIX
like %g, but generates a new temporary file name even if %uSUFFIX
was already seen.
%USUFFIX
substitutes the last file name generated with %uSUFFIX, generating a
new one if there is no such last file name. In the absence of any
%uSUFFIX, this is just like %gSUFFIX, except they don’t share
the same suffix “space”, so %g.s ... %U.s ... %g.s ... %U.s' would involve the generation of two distinct file names, one for each %g.s’ and another for each %U.s'. Previously, %U was simply substituted with a file name chosen for the previous %u, without regard to any appended suffix. %d marks the argument containing or following the %d as a temporary file name, so that that file will be deleted if CC exits successfully. Unlike %g, this contributes no text to the argument. %w marks the argument containing or following the %w as the "output file" of this compilation. This puts the argument into the sequence of arguments that %o will substitute later. %W{...} like %{...} but mark last argument supplied within as a file to be deleted on failure. %o substitutes the names of all the output files, with spaces automatically placed around them. You should write spaces around the %o as well or the results are undefined. %o is for use in the specs for running the linker. Input files whose names have no recognized suffix are not compiled at all, but they are included among the output files, so they will be linked. %O substitutes the suffix for object files. Note that this is handled specially when it immediately follows %g, %u, or %U, because of the need for those to form complete file names. The handling is such that %O is treated exactly as if it had already been substituted, except that %g, %u, and %U do not currently support additional SUFFIX characters following %O as they would following, for example, .o’.
%p substitutes the standard macro predefinitions for the
current target machine. Use this when running cpp.
%P like %p, but puts __' before and after the name of each macro. (Except macros that already have __.) This is for ANSI C. %I Substitute a -iprefix option made from GCC_EXEC_PREFIX. %s current argument is the name of a library or startup file of some sort. Search for that file in a standard list of directories and substitute the full name found. %eSTR Print STR as an error message. STR is terminated by a newline. Use this when inconsistent options are detected. %x{OPTION} Accumulate an option for %X. %X Output the accumulated linker options specified by compilations. %Y Output the accumulated assembler options specified by compilations. %Z Output the accumulated preprocessor options specified by compilations. %v1 Substitute the major version number of GCC. (For version 2.5.n, this is 2.) %v2 Substitute the minor version number of GCC. (For version 2.5.n, this is 5.) %a process ASM_SPEC as a spec. This allows config.h to specify part of the spec for running as. %A process ASM_FINAL_SPEC as a spec. A capital A is actually used here. This can be used to run a post-processor after the assembler has done its job. %D Dump out a -L option for each directory in startfile_prefixes. If multilib_dir is set, extra entries are generated with it affixed. %l process LINK_SPEC as a spec. %L process LIB_SPEC as a spec. %G process LIBGCC_SPEC as a spec. %S process STARTFILE_SPEC as a spec. A capital S is actually used here. %E process ENDFILE_SPEC as a spec. A capital E is actually used here. %c process SIGNED_CHAR_SPEC as a spec. %C process CPP_SPEC as a spec. A capital C is actually used here. %1 process CC1_SPEC as a spec. %2 process CC1PLUS_SPEC as a spec. %| output "-" if the input for the current command is coming from a pipe. %* substitute the variable part of a matched option. (See below.) Note that each comma in the substituted string is replaced by a single space. %{S} substitutes the -S switch, if that switch was given to CC. If that switch was not specified, this substitutes nothing. Here S is a metasyntactic variable. %{S*} substitutes all the switches specified to CC whose names start with -S. This is used for -o, -D, -I, etc; switches that take arguments. CC considers -o foo’ as being one switch whose
name starts with o'. %{o*} would substitute this text, including the space; thus, two arguments would be generated. %{^S*} likewise, but don't put a blank between a switch and any args. %{S*:X} substitutes X if one or more switches whose names start with -S are specified to CC. Note that the tail part of the -S option (i.e. the part matched by the ‘) will be substituted for each
occurrence of %* within X.
%{S:X} substitutes X, but only if the -S switch was given to CC.
%{!S:X} substitutes X, but only if the -S switch was NOT given to CC.
%{|S:X} like %{S:X}, but if no S switch, substitute -'. %{|!S:X} like %{!S:X}, but if there is an S switch, substitute -’.
%{.S:X} substitutes X, but only if processing a file with suffix S.
%{!.S:X} substitutes X, but only if NOT processing a file with suffix S.
%{S|P:X} substitutes X if either -S or -P was given to CC. This may be
combined with ! and . as above binding stronger than the OR.
%(Spec) processes a specification defined in a specs file as *Spec:
%[Spec] as above, but put __ around -D arguments
The conditional text X in a %{S:X} or %{!S:X} construct may contain
other nested % constructs or spaces, or even newlines. They are
processed as usual, as described above.
The -O, -f, -m, and -W switches are handled specifically in these
constructs. If another value of -O or the negated form of a -f, -m, or
-W switch is found later in the command line, the earlier switch
value is ignored, except with {S*} where S is just one letter; this
passes all matching options.
The character | at the beginning of the predicate text is used to indicate
that a command should be piped to the following command, but only if -pipe
is specified.
Note that it is built into CC which switches take arguments and which
do not. You might think it would be useful to generalize this to
allow each compiler’s spec to say which switches take arguments. But
this cannot be done in a consistent fashion. CC cannot even decide
which input files have been specified without knowing which switches
take arguments, and it must know which input files to compile in order
to tell which compilers to run.
CC also knows implicitly that arguments starting in `-l’ are to be
treated as compiler output files, and passed to the linker in their
proper position among the other output files. */
Paul D. Smith <pausmith@nortelnetworks.com> wrote:
%% “Brian K. Hlady” <> bhlady@qnx.com> > writes:
bkh> Can you post the output of qcc -v please? What errors are you
bkh> getting? Configuration files for qcc are found in
bkh> %QNX_HOST%\etc\qccHi Brian; let me reiterate so it’s clear: qcc does work, just fine.
It’s not a problem with qcc at all.The “problem” is that I can’t convince standard ntoppc-gcc to work
correctly; it invokes the preprocessor (especially) with a different set
of flags than qcc does and that set of flags doesn’t work properly
(mainly the -isystem flag has the wrong path and I can’t work out a way
to get ntoppc-gcc to use the right values, in the right order).I need to be able to create our build tools from source for various
reasons, and since I can’t figure out how to get the build to succeed
without using the qcc front-end the simplest thing for me would be to
get the source to it. Failing that I’ll have to come up with a
home-grown replacement unless I can figure out how to tweak ntoppc-gcc.I actually talked to our account contact at QNX and I think things are
moving along via that route so hopefully I should be all set shortly.
Thanks for the reply!–
Paul D. Smith <> pausmith@nortelnetworks.com> > HASMAT–HA Software Mthds & Tools
“Please remain calm…I may be mad, but I am a professional.” --Mad ScientistThese are my opinions—Nortel Networks takes no responsibility for them.
Ah. Interesting. Thanks for the pointer.
OK, using this I was able to get closer to identical output as qcc
gives, although there are still differences in some output files.
There is one major thing missing though: qcc changes the values of some
of the flags it uses (like -idirafter, etc.) based on environment
variables like QNX_TARGET. I need that capability as well, but specs
files are static. Also, the only way I can get gcc to find the right
versions of the compiler components is to use the -B option, but that
also adds unwanted flags, like -isystem, so some of the components.
Maybe there’s something I’m missing about the specs files; I’ll see if I
can find more docs on the web or in the source.
These are my opinions—Nortel Networks takes no responsibility for them.
Paul D. Smith <pausmith@nortelnetworks.com> wrote:
Ah. Interesting. Thanks for the pointer.
OK, using this I was able to get closer to identical output as qcc
gives, although there are still differences in some output files.There is one major thing missing though: qcc changes the values of some
of the flags it uses (like -idirafter, etc.) based on environment
variables like QNX_TARGET. I need that capability as well, but specs
files are static. Also, the only way I can get gcc to find the right
versions of the compiler components is to use the -B option, but that
also adds unwanted flags, like -isystem, so some of the components.Maybe there’s something I’m missing about the specs files; I’ll see if I
can find more docs on the web or in the source.
I don’t think you’re missing anything. The specs files are hardwired to defaults
that may not be what you want. One of the benefits of using qcc.
Cheers.
GP
–
Paul D. Smith <> pausmith@nortelnetworks.com> > HASMAT–HA Software Mthds & Tools
“Please remain calm…I may be mad, but I am a professional.” --Mad ScientistThese are my opinions—Nortel Networks takes no responsibility for them.
%% Graeme Peterson <gp@qnx.com> writes:
gp> I don’t think you’re missing anything. The specs files are
gp> hardwired to defaults that may not be what you want. One of the
gp> benefits of using qcc.
Yes, I like it; where do I find the Linux version? 
These are my opinions—Nortel Networks takes no responsibility for them.