pcc and Fedora Linux

[Fred J. Tydeman]

Any idea when a current version of pcc will be released
as an official Fedora Linux software to install? The
one there now is dated 2011/12/16.

---
Fred J. Tydeman Tydeman Consulting
***@tybor.com Testing, numerics, programming
[phone] Vice-chair of PL22.11 (ANSI "C")
Sample C99+FPCE tests: http://www.tybor.com
Savers sleep well, investors eat well, spenders work forever.

[Anders Magnusson]

Post by Fred J. Tydeman
Any idea when a current version of pcc will be released
as an official Fedora Linux software to install? The
one there now is dated 2011/12/16.

I have a dream to branch for a new release after christmas.
I had hoped to be able to do so earlier but my daytime job has taken all
my time lately.

There are three targets that should be fully supported; i386, amd64 and vax.
The intention is to have a release that can compile both userland and
kernels on all BSDs and also a running Linux kernel; the latter is more
difficult for me since I do not have the experience to debug it (==
takes too much time).

-- Ragge

[Susi Lehtola]

On Sat, 01 Dec 2012 09:36:34 +0100

Post by Anders Magnusson

Post by Fred J. Tydeman
Any idea when a current version of pcc will be released
as an official Fedora Linux software to install? The
one there now is dated 2011/12/16.

I have a dream to branch for a new release after christmas.
I had hoped to be able to do so earlier but my daytime job has taken
all my time lately.
There are three targets that should be fully supported; i386, amd64
and vax. The intention is to have a release that can compile both
userland and kernels on all BSDs and also a running Linux kernel; the
latter is more difficult for me since I do not have the experience to
debug it (== takes too much time).

I'm the maintainer of the Fedora package.

I just tried to update to the newest cvs snapshot, but pcc fails to
recompile itself. The libs compile just fine, but pcc itself gives

$ ./configure
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for gcc... pcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run C
compiled programs. If you meant to cross compile, use `--host'.
See `config.log' for more details.

The relevant log entry is
configure:2888: checking whether the C compiler works
configure:2898: ./a.out
configure:2901: $? = 96
configure:2910: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.

However, the funny thing is that I can compile, e.g., hello world just
fine with pcc and run it as well...

[Susi Lehtola]

On Mon, 17 Dec 2012 09:49:19 +0000 (GMT)

Post by Susi Lehtola
I'm the maintainer of the Fedora package.
I just tried to update to the newest cvs snapshot, but pcc fails to
recompile itself. The libs compile just fine, but pcc itself gives
$ ./configure
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for gcc... pcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot
run C compiled programs. If you meant to cross compile, use
`--host'. See `config.log' for more details.
The relevant log entry is
configure:2888: checking whether the C compiler works
configure:2898: ./a.out
configure:2901: $? = 96
configure:2910: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.

can you find the source code that is used to compile the a.out test
program, and the command line that was used to do it?

configure:2803: checking for C compiler default output file name
configure:2830: pcc -g conftest.c >&5
configure:2833: $? = 0
configure:2871: result: a.out
configure:2888: checking whether the C compiler works
configure:2898: ./a.out
configure:2901: $? = 96
configure:2910: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.

[Susi Lehtola]

On Mon, 17 Dec 2012 23:05:54 +0000 (GMT)

Post by Susi Lehtola
configure:2803: checking for C compiler default output file name
configure:2830: pcc -g conftest.c >&5
configure:2833: $? = 0
configure:2871: result: a.out
configure:2888: checking whether the C compiler works
configure:2898: ./a.out
configure:2901: $? = 96
configure:2910: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.

well the source itself seems to be some definitions and an empty
main() here, but to be sure.. can you apply the attached patch
applied to configure, which will produce a file "saved.c" ?
and does that fail to run if you compile it manually?

Nope - the test program compiles and runs just fine.
However, it returns 96:
$ pcc -g backup.c
$ ./a.out
$ echo $?
96

With GCC it returns 0 as it should.

[Susi Lehtola]

On Wed, 19 Dec 2012 21:00:36 +0000 (GMT)

sorry been offline... what is the source, in the end, is it just
int main() { return 0; }
as it is here?
It is strange that a hello world program worked for you, but then does
that return an error also that we didn't detect?
also, is it the same without "-g" ?
I doubt that it is generating incorrect assembler though you could
compare the output of gcc against the pcc output to be sure.. most
likely I would think it would be the linked start/end files .. can
you show the output of "pcc -v" vs "gcc -v" ?

Well, the thing is that I naturally didn't check the return value of
the hello world program, which also turns out to be 96; the same
regardless of the presence of -g.

$ pcc -v hello.c
pcc 1.1.0.DEVEL 20121214 for x86_64-unknown-linux-gnu
Calling /usr/libexec/cpp -D_LP64 -D__LP64__ -D__amd64 -D__amd64__ -D__x86_64 -D__x86_64__ -D__ELF__ -D__linux__ -D__STDC_HOSTED__=1 -v -D__GNUC_STDC_INLINE__ -D__USER_LABEL_PREFIX__= -D__REGISTER_PREFIX__= -D__GNUC_PATCHLEVEL__=1 -D__GNUC_MINOR__=3 -D__GNUC__=4 -D__SIZEOF_WINT_T__=4 -D__PTRDIFF_TYPE__=long int -D__SIZE_TYPE__=unsigned long -D__WINT_TYPE__=unsigned int -D__WCHAR_MAX__=2147483647 -D__SIZEOF_WCHAR_T__=4 -D__WCHAR_TYPE__=int -D__STDC_ISO_10646__=200009L -D__LONG_LONG_MAX__=0x7fffffffffffffffLL -D__LONG_MAX__=0x7fffffffffffffffLL -D__INT_MAX__=0x7fffffff -D__SHRT_MAX__=32767 -D__SCHAR_MAX__=127 -D__VERSION__="pcc 1.1.0.DEVEL 20121214 for x86_64-unknown-linux-gnu" -D__PCC_MINORMINOR__=0 -D__PCC_MINOR__=1 -D__PCC__=1 -S /usr/include/pcc/ -S /usr/include -S /usr/lib64/pcc/x86_64-u
nknown-linux-gnu/1.1.0.DEVEL/include/ hello.c /tmp/ctm.Zq7QLY
PCC preprocessor version pcc 1.1.0.DEVEL 20121214 for x86_64-unknown-linux-gnu
Calling /usr/libexec/ccom -v /tmp/ctm.Zq7QLY /tmp/ctm.DiVMP5
ccom: pcc 1.1.0.DEVEL 20121214 for x86_64-unknown-linux-gnu
Calling /usr/bin/as -v /tmp/ctm.DiVMP5 -o /tmp/ctm.250oUc
GNU assembler version 2.23.51.0.1 (x86_64-redhat-linux) using BFD version version 2.23.51.0.1-3.fc18 20120806
Calling /usr/bin/ld -v -d -dynamic-linker /lib64/ld-linux-x86-64.so.2 -e _start /usr/lib64/pcc/x86_64-unknown-linux-gnu/1.1.0.DEVEL/lib/crt1.o /usr/lib64/pcc/x86_64-unknown-linux-gnu/1.1.0.DEVEL/lib/crti.o /usr/lib64/pcc/x86_64-unknown-linux-gnu/1.1.0.DEVEL/lib/crtbegin.o /tmp/ctm.250oUc -L/usr/lib64/pcc/x86_64-unknown-linux-gnu/1.1.0.DEVEL/lib/ -L/usr/lib64/ -lpcc -lc -lpcc /usr/lib64/pcc/x86_64-unknown-linux-gnu/1.1.0.DEVEL/lib/crtend.o /usr/lib64/pcc/x86_64-unknown-linux-gnu/1.1.0.DEVEL/lib/crtn.o
GNU ld version 2.23.51.0.1-3.fc18 20120806

$ gcc -v hello.c
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-t
une=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC)
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/cc1 -quiet -v hello.c -quiet -dumpbase hello.c -mtune=generic -march=x86-64 -auxbase hello -version -o /tmp/ccAOYyjC.s
GNU C (GCC) version 4.7.2 20121109 (Red Hat 4.7.2-8) (x86_64-redhat-linux)
compiled by GNU C version 4.7.2 20121109 (Red Hat 4.7.2-8), GMP version 5.0.5, MPFR version 3.1.1, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/4.7.2/include-fixed"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/include
/usr/local/include
/usr/include
End of search list.
GNU C (GCC) version 4.7.2 20121109 (Red Hat 4.7.2-8) (x86_64-redhat-linux)
compiled by GNU C version 4.7.2 20121109 (Red Hat 4.7.2-8), GMP version 5.0.5, MPFR version 3.1.1, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 71c7e38131c41f2b53aef8c65e624722
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
as -v --64 -o /tmp/ccWDGq03.o /tmp/ccAOYyjC.s
GNU assembler version 2.23.51.0.1 (x86_64-redhat-linux) using BFD version version 2.23.51.0.1-3.fc18 20120806
COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/:/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/4.7.2/:/usr/lib/gcc/x86_64-redhat-linux/
LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/4.7.2/:/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/collect2 --build-id
--no-add-needed --eh-frame-hdr --hash-style=gnu -m elf_x86_64
-dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.7.2/crtbegin.o
-L/usr/lib/gcc/x86_64-redhat-linux/4.7.2
-L/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../.. /tmp/ccWDGq03.o
-lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed /usr/lib/gcc/x86_64-redhat-linux/4.7.2/crtend.o /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crtn.o

[marco caminati]

Is there an updated pcc sources mirror available?

[Susi Lehtola]

On Fri, 21 Dec 2012 10:19:55 +0000 (GMT)

I am suspecting something that the pcc-libs start/end files does not
do that the system (or gcc) provided ones do, but that (gnu?) libc
relies on, or something that the libgcc or libgcc_s are supposed to
provide, which pcc does not link
I note that the pcc-built binary uses crt files from
/usr/lib64/pcc/x86_64-unknown-linux-gnu/1.1.0.DEVEL/lib
whereas the gcc-built binary is using the files from
/usr/lib64
which are presumably the gcc versions?
does it make any difference if you don't have pcc-libs installed? (I
think this will mean that the system-provided crtfiles will be used,
instead)

Doesn't look like it. If I don't install pcc-libs, then it fails to
find standard include files or libpcc.

If I do install it, but get rid of all the crt files and replace them
with gcc's crtbegin.o and crtend.o, the return code works as it should.

[i***@lavabit.com]

Post by Susi Lehtola
On Fri, 21 Dec 2012 10:19:55 +0000 (GMT)

I am suspecting something that the pcc-libs start/end files does not
do that the system (or gcc) provided ones do, but that (gnu?) libc
relies on, or something that the libgcc or libgcc_s are supposed to
provide, which pcc does not link
I note that the pcc-built binary uses crt files from
/usr/lib64/pcc/x86_64-unknown-linux-gnu/1.1.0.DEVEL/lib
whereas the gcc-built binary is using the files from
/usr/lib64
which are presumably the gcc versions?
does it make any difference if you don't have pcc-libs installed? (I
think this will mean that the system-provided crtfiles will be used,
instead)

Doesn't look like it. If I don't install pcc-libs, then it fails to
find standard include files or libpcc.
If I do install it, but get rid of all the crt files and replace them
with gcc's crtbegin.o and crtend.o, the return code works as it should.

And if you compile pcc-libs with gcc?

[Susi Lehtola]

On Mon, 7 Jan 2013 21:03:40 -0800 (PST)

Post by i***@lavabit.com

Post by Susi Lehtola
Doesn't look like it. If I don't install pcc-libs, then it fails to
find standard include files or libpcc.
If I do install it, but get rid of all the crt files and replace
them with gcc's crtbegin.o and crtend.o, the return code works as
it should.

And if you compile pcc-libs with gcc?

pcc-libs and pcc ARE compiled with gcc.