Package Details: pcc 1.1.0-1

Git Clone URL: https://aur.archlinux.org/pcc.git (read-only, click to copy)
Package Base: pcc
Description: A Portable C Compiler
Upstream URL: http://pcc.ludd.ltu.se/
Keywords: compiler lightweight portable
Licenses: custom:BSD
Submitter: andreas_baumann
Maintainer: edh
Last Packager: edh
Votes: 19
Popularity: 0.000002
First Submitted: 2009-03-13 10:02 (UTC)
Last Updated: 2020-09-15 09:23 (UTC)

Latest Comments

edh commented on 2020-09-15 09:23 (UTC)

@Elronnd

Thanks for the hint. Fixed!

Elronnd commented on 2020-09-14 01:35 (UTC)

Needs to be built with CFLAGS=-fcommon.

newbthenewbd commented on 2019-09-25 12:06 (UTC)

The package seems to be affected by this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1551537

The published workaround of using the -D__float128="long double" option makes it successfully compile, albeit not without a warning.

edh commented on 2019-07-10 12:32 (UTC)

Dropped i686 support as a response.

@cbb It was not some random gist! It was a patch by the previous AUR maintainer hosted on GitHub. Unfortunately, he seem to have deleted it.

cbb commented on 2019-07-10 11:36 (UTC)

This package is now broken because the patch file is no longer online. I suspected this would happen when I read the PKGBUILD, even before I tried to install it. Making a package depend on some random Gist is just asking for it...

edh commented on 2017-07-02 12:31 (UTC)

@andreas_baumann I added your patch to the package. Thanks for working on this.

andreas_baumann commented on 2017-07-02 11:56 (UTC) (edited on 2017-07-02 11:57 (UTC) by andreas_baumann)

@edh: very good point you are making here about maintainance on AUR. :-) So I added a patch here: https://github.com/andreasbaumann/arch/tree/master/adapted/pcc Note: the CVS/current version is already fixed (differently). This patch is only a backport for the 1.1.0 release of pcc.

edh commented on 2017-07-02 11:05 (UTC) (edited on 2017-07-02 11:05 (UTC) by edh)

@andreas_baumann Since you are already in contact with the developer, I would recommend you to send the patch to him. There would be no patching required at all if it would be merged. Btw. it would not make sense to split the AUR by architecture. Hence maintainers may or may not keep support for old architectures in the AUR depending on their workload.

andreas_baumann commented on 2017-07-02 08:07 (UTC) (edited on 2017-07-02 08:08 (UTC) by andreas_baumann)

Found it. But as ArchLinux drops 32-bit, it's debatable whether we should patch this package here. I don't know what the plans are for ArchLinux32 and the AUR? Will there be an AUR for 32-bit additionally, then the patch can go there.

andreas_baumann commented on 2017-07-02 07:45 (UTC)

I can confirm that I can compile the package without any problems on 64-bit. I tried a second compilation in an Arch32 environment, and this one fails again. So the error must be somewhere there.. I'm digging. :-)

andreas_baumann commented on 2017-07-02 07:41 (UTC) (edited on 2017-07-02 08:12 (UTC) by andreas_baumann)

I opened a discusion with the author in http://pcc.ludd.ltu.se/jira/browse/PCC-584

andreas_baumann commented on 2017-07-02 07:26 (UTC)

mmh. really strange. My output looks like this: https://gist.github.com/andreasbaumann/674b3f83695ceabf341334d2601b8425 The only difference I can see is the CPU architecture (and yes, the /bin instead of /usr/bin). Diffing the code of cc.c I see: 1.1.0 version: #ifndef DEFLIBDIRS /* default library search paths */ #ifdef MULTIARCH_PATH #define DEFLIBDIRS { "/usr/lib/", 0 } #else #define DEFLIBDIRS { "/usr/lib/", "/usr/lib/" MULTIARCH_PATH "/", 0 } #endif #endif current CVS version: #ifndef LIBDIR #define LIBDIR "/usr/lib/" #endif #ifndef DEFLIBDIRS /* default library search paths */ #ifdef MULTIARCH_PATH #define DEFLIBDIRS { LIBDIR, LIBDIR MULTIARCH_PATH "/", 0 } #else #define DEFLIBDIRS { LIBDIR, 0 } #endif #endif The 1.1.0 version is clearly wrong in my brain and cannot possibly work without creating a compilation error. :-)

edh commented on 2017-07-01 17:19 (UTC)

@andreas_baumann In the container I am using the default parameters from /etc/makepkg.conf and my configure output looks like this: https://gist.github.com/Edenhofer/1db77d8e4ac7ec84d5a7dd001775dd6a . However I do compile on an 64-bit machine (see the above output). Since this package does not require any dependencies from multilib, it should be irrelevant whether I have it enable or not. Nevertheless in order to answer your question: No, the container does not contain any packages from multilib.

andreas_baumann commented on 2017-07-01 16:57 (UTC)

What does the output of configure say? Using Multi-Arch path ............ (no) Are you compiling on a 64-bit machine? With or without multilib installed. I'm building on a 32-bit machine.

edh commented on 2017-07-01 16:44 (UTC)

@andreas_baumann Sorry, but I can not reproduce your error messages in a clean chroot. Furthermore the compiler is working as expected for me. P.S.: It is not necessary to comment and flag the package as out-of-date. One action is sufficient.

andreas_baumann commented on 2017-07-01 15:35 (UTC) (edited on 2017-07-01 17:55 (UTC) by andreas_baumann)

Fails with: ./cc.c:212:47: error: expected '}' before 'MULTIARCH_PATH' #define DEFLIBDIRS { "/usr/lib/", "/usr/lib/" MULTIARCH_PATH "/", 0 } ^ ./cc.c:230:22: note: in expansion of macro 'DEFLIBDIRS' char *deflibdirs[] = DEFLIBDIRS; ^~~~~~~~~~

edh commented on 2015-03-22 17:38 (UTC)

Version 1.1.0 is out! I fixed minor inconsistencies and tested the package on three different machines.

shaurz commented on 2012-12-15 17:34 (UTC)

I currently get the following output: ld: cannot find /usr/lib64/crt1.o: No such file or directory I guess it needs patching to look in /usr/lib

andreas_baumann commented on 2011-10-05 17:12 (UTC)

Actually, I recommend using pcc-libs-cvs and pcc-cvs. I currently don't get a running hello world using pcc 1.0.0 :-)

andreas_baumann commented on 2011-10-05 16:33 (UTC)

Mmh. Sorry for the late answer, can't reproduce. Can you paste the error message you get?

kfgz commented on 2011-04-09 13:35 (UTC)

You need to unset LDFLAGS because it doesn't compile.