Discussion:
Current PCC broken on Ubuntu 12.04
Aharon Robbins
2014-09-16 17:58:58 UTC
Permalink
Hi.

Please cc me on replies, since I'm not on the list.

The current CVS is broken on Ubuntu 12.04 (64 bit):

$ cat hello.c
#include <stdio.h>

int main(int argc, char **argv)
{
printf("hello, world\n");
return 0;
}

$ pcc hello.c -o hello
ld: cannot find crt1.o: No such file or directory
ld: cannot find crti.o: No such file or directory
error: ld terminated with status 1

And indeed, there is no crt1.o in the libs installed from pcc-libs.

PCC used to work on Linux. I use it occasionally for compiling gawk.
It'd be nice to have this working again.

Thanks,

Arnold
Anders Magnusson
2014-09-16 18:14:58 UTC
Permalink
Post by Aharon Robbins
Hi.
Please cc me on replies, since I'm not on the list.
$ cat hello.c
#include <stdio.h>
int main(int argc, char **argv)
{
printf("hello, world\n");
return 0;
}
$ pcc hello.c -o hello
ld: cannot find crt1.o: No such file or directory
ld: cannot find crti.o: No such file or directory
error: ld terminated with status 1
My fault. I'll fix it in a few days.

-- Ragge
u***@aetey.se
2014-09-16 19:49:54 UTC
Permalink
Post by Anders Magnusson
Post by Aharon Robbins
Hi.
Please cc me on replies, since I'm not on the list.
$ cat hello.c
#include <stdio.h>
int main(int argc, char **argv)
{
printf("hello, world\n");
return 0;
}
$ pcc hello.c -o hello
ld: cannot find crt1.o: No such file or directory
ld: cannot find crti.o: No such file or directory
error: ld terminated with status 1
My fault. I'll fix it in a few days.
By the way, I think I can offer working pcc+musl toolchains for i386
and x86_64 (the same binaries as I am using) if there is any interest.

Prerequisites to use it:
- a generic Linux kernel on Intel (userland/distro is totally irrelevant
as long as the kernel is reasonably generic/full-featured)
- a Coda file system client (one time 2MB download, distro-independent)
- trust in my binaries (think carefully what kind of a guy I am)

To make it as clear as possible:
- this is for those who want to _run_/_use_ pcc not to build it
- no downloads besides the Coda installation, everything runs
directly from the global paths (and runs fast even if your network
is slow - no magic involved, learn how Coda works)

I create new instances corresponding to minor releases or major bugfixes
of pcc, without removing the previous ones, comparison runs become
really easy.

The entry point into a toolchain is a path like
/coda/<something>/pcc
which executable knows where its default includes and libraries reside
(on similarly looking global paths).

Thanks to musl's stable ABI you will be also able to produce dynamically
linked binaries suitable for running with _your_ instance of musl
(otherwise they will of course assume the loader from the globally
placed parent musl instance, to be runnable in the environment where
they are generated)

Note that my pcc instances respect PCC_DYNAMIC_LOADER so the adjustment
to a local musl instance is trivial.

Built statically linked binaries are of course independent of any extra
library resources or paths.

The above proposal implies some work to set up the access so I wonder
if there is any interest.

Rune
Aharon Robbins
2014-09-29 19:48:27 UTC
Permalink
Hi.

This is still broken. Is it supposed to be fixed yet?

Thanks,

Arnold
Date: Tue, 16 Sep 2014 20:14:58 +0200
Subject: Re: [Pcc] Current PCC broken on Ubuntu 12.04
Post by Aharon Robbins
Hi.
Please cc me on replies, since I'm not on the list.
$ cat hello.c
#include <stdio.h>
int main(int argc, char **argv)
{
printf("hello, world\n");
return 0;
}
$ pcc hello.c -o hello
ld: cannot find crt1.o: No such file or directory
ld: cannot find crti.o: No such file or directory
error: ld terminated with status 1
My fault. I'll fix it in a few days.
-- Ragge
Anders Magnusson
2014-09-29 19:52:03 UTC
Permalink
No, not yet, I got occupied with some other stuff. Hopefully soon...

-- Ragge
Post by Aharon Robbins
Hi.
This is still broken. Is it supposed to be fixed yet?
Thanks,
Arnold
Date: Tue, 16 Sep 2014 20:14:58 +0200
Subject: Re: [Pcc] Current PCC broken on Ubuntu 12.04
Post by Aharon Robbins
Hi.
Please cc me on replies, since I'm not on the list.
$ cat hello.c
#include <stdio.h>
int main(int argc, char **argv)
{
printf("hello, world\n");
return 0;
}
$ pcc hello.c -o hello
ld: cannot find crt1.o: No such file or directory
ld: cannot find crti.o: No such file or directory
error: ld terminated with status 1
My fault. I'll fix it in a few days.
-- Ragge
_______________________________________________
Pcc mailing list
http://lists.ludd.ltu.se/cgi-bin/mailman/listinfo/pcc
Anders Magnusson
2014-09-30 09:01:54 UTC
Permalink
Post by Aharon Robbins
Hi.
This is still broken. Is it supposed to be fixed yet?
It is actually a little more intriguing than I first thought. I tried
it on Ubuntu 12.04 for x86.

crt1 is libc dependent and should not be provided by the compiler (which
it was before, causing other bugs, as discussed on this list earlier).
Usually it is placed in /usr/lib, but Ubuntu has it in
/usr/lib/i386-linux-gnu/ instead. Adding this to the lib search path works.

Second problem is that /usr/include/sys/ is also missing on Ubuntu,
instead the sys stuff is in /usr/include/i386-linux-gnu/sys/.
This means that this path must also be added as a system include path.

Anyone have any idea to solve this in a reasonable simple non-intrusive way?

-- Ragge
u***@aetey.se
2014-09-30 09:17:49 UTC
Permalink
crt1 is libc dependent and should not be provided by the compiler (which it
was before, causing other bugs, as discussed on this list earlier).
Usually it is placed in /usr/lib, but Ubuntu has it in
/usr/lib/i386-linux-gnu/ instead. Adding this to the lib search path works.
Second problem is that /usr/include/sys/ is also missing on Ubuntu, instead
the sys stuff is in /usr/include/i386-linux-gnu/sys/.
This means that this path must also be added as a system include path.
Anyone have any idea to solve this in a reasonable simple non-intrusive way?
CC="pcc -I.... -L...." ? :-)

A one-line wrapper would do as well I guess.

I see this as a distro-specific issue which should be solved or worked
around by the distro-specific packager. If you _are_ maintaining pcc
for Ubuntu, then you are the packager and have to care. Otherwise let
someone else take care of this.

If you are to act as a packager (which I do not think you should but may
be you like :) then please do not pollute upstream with distro-specific
details. Keep the different kinds of stuff well separated, this is
important in the long run.

Rune
Justin Cormack
2014-09-30 09:22:11 UTC
Permalink
Post by u***@aetey.se
crt1 is libc dependent and should not be provided by the compiler (which it
was before, causing other bugs, as discussed on this list earlier).
Usually it is placed in /usr/lib, but Ubuntu has it in
/usr/lib/i386-linux-gnu/ instead. Adding this to the lib search path works.
Second problem is that /usr/include/sys/ is also missing on Ubuntu, instead
the sys stuff is in /usr/include/i386-linux-gnu/sys/.
This means that this path must also be added as a system include path.
Anyone have any idea to solve this in a reasonable simple non-intrusive way?
CC="pcc -I.... -L...." ? :-)
A one-line wrapper would do as well I guess.
I see this as a distro-specific issue which should be solved or worked
around by the distro-specific packager. If you _are_ maintaining pcc
for Ubuntu, then you are the packager and have to care. Otherwise let
someone else take care of this.
If you are to act as a packager (which I do not think you should but may
be you like :) then please do not pollute upstream with distro-specific
details. Keep the different kinds of stuff well separated, this is
important in the long run.
It is not really that distro specific it is just new multiarch support. It
means they can ship cross compilers that are all defined to have their
headers and libs in the same place on host and target which is very useful.

You should be able to support it with the various sysroot options that gcc
and clang support.
Joerg Sonnenberger
2014-09-30 12:04:50 UTC
Permalink
Post by Justin Cormack
It is not really that distro specific it is just new multiarch support. It
means they can ship cross compilers that are all defined to have their
headers and libs in the same place on host and target which is very useful.
I disagree on the the useful part, but you are correct about it being
part of the multiarch support. I don't have a current checkout at hand,
but the correct fix is to add it to the list of system include path,
similar to what /usr/include gets. Library search path should be used
for crti.o IIRC.

Joerg
Anders Magnusson
2014-09-30 12:52:43 UTC
Permalink
Post by Joerg Sonnenberger
Post by Justin Cormack
It is not really that distro specific it is just new multiarch support. It
means they can ship cross compilers that are all defined to have their
headers and libs in the same place on host and target which is very useful.
I disagree on the the useful part, but you are correct about it being
part of the multiarch support. I don't have a current checkout at hand,
but the correct fix is to add it to the list of system include path,
similar to what /usr/include gets. Library search path should be used
for crti.o IIRC.
Ok, yep, I did that when testing.

The thing I was thinking about was how to make this "seamless" or so.
It would be possible to put it in autoconf (if ubuntu/i386 do something,
else if ubuntu/x86_64 something else, ...) but it is somewhat a special
case.
But maybe that is how it should be done...

-- Ragge
u***@aetey.se
2014-09-30 17:30:35 UTC
Permalink
Post by Anders Magnusson
Post by Joerg Sonnenberger
part of the multiarch support. I don't have a current checkout at hand,
but the correct fix is to add it to the list of system include path,
similar to what /usr/include gets. Library search path should be used
for crti.o IIRC.
Ok, yep, I did that when testing.
The thing I was thinking about was how to make this "seamless" or so.
It would be possible to put it in autoconf (if ubuntu/i386 do something,
else if ubuntu/x86_64 something else, ...) but it is somewhat a special
case.
It is this kind of stuff which I mean by a "distro-specific pollution"...
Post by Anders Magnusson
But maybe that is how it should be done...
No, if you ask me. :)

Imho this is a part of the "ubuntu-compatibility" or
"multiarch-compatibility" and should be kept well separated from "pcc".

The knowledge of where the resources are placed is only reliably available
to the distro-specific packager, not generally. Trying to keep knowledge
about all possible or "all relevant" distros and their mindsets as a part
of pcc will both take your time and be guaranteed to regularly fall
out-of sync.

On the other side if "multiarch" setup has an underlying standard (?)
you may wish to follow it - if there is indeed a standard of how to
implement "multiarch".

(I guess I achieve in my setup among others what multiarch does, but
in an extremely different way, so let's avoid confusing a goal with a
certain implementation of it).

Rune
Anders Magnusson
2014-10-03 13:35:18 UTC
Permalink
Post by u***@aetey.se
Post by Anders Magnusson
Post by Joerg Sonnenberger
part of the multiarch support. I don't have a current checkout at hand,
but the correct fix is to add it to the list of system include path,
similar to what /usr/include gets. Library search path should be used
for crti.o IIRC.
Ok, yep, I did that when testing.
The thing I was thinking about was how to make this "seamless" or so.
It would be possible to put it in autoconf (if ubuntu/i386 do something,
else if ubuntu/x86_64 something else, ...) but it is somewhat a special
case.
It is this kind of stuff which I mean by a "distro-specific pollution"...
Post by Anders Magnusson
But maybe that is how it should be done...
No, if you ask me. :)
Imho this is a part of the "ubuntu-compatibility" or
"multiarch-compatibility" and should be kept well separated from "pcc".
What I want is that anyone can fetch the tarball, unpack on their
favourite system,
configure, make and use pcc. It won't work to expect people to do a system-
specific package for each OS and architecture.

-- Ragge
u***@aetey.se
2014-10-03 14:08:42 UTC
Permalink
Post by u***@aetey.se
Imho this is a part of the "ubuntu-compatibility" or
"multiarch-compatibility" and should be kept well separated from "pcc".
What I want is that anyone can fetch the tarball, unpack on their favourite
system,
configure, make and use pcc. It won't work to expect people to do a system-
specific package for each OS and architecture.
But this is what you are doing, in a little more ambitious fashion :)
putting all of the various adjustments into a single package.

I always feel a pity of developers spending time on environment-specific
issues. There is of course nothing wrong with the goal.

Anyway, I'd care more about people having ppc "available" in contrast to
"compilable". How many of gcc users compile gcc?..

My 0.02 SEK

Rune
Anders Magnusson
2014-10-04 08:53:53 UTC
Permalink
Post by u***@aetey.se
Post by u***@aetey.se
Imho this is a part of the "ubuntu-compatibility" or
"multiarch-compatibility" and should be kept well separated from "pcc".
What I want is that anyone can fetch the tarball, unpack on their favourite
system,
configure, make and use pcc. It won't work to expect people to do a system-
specific package for each OS and architecture.
But this is what you are doing, in a little more ambitious fashion :)
putting all of the various adjustments into a single package.
Well, not really :-)

The ability to run "configure && make && make install" should be
possible for anyone on most target OSes.

The ability to do sort of "yum install pcc" is up to the OS/package
maintainers.
Post by u***@aetey.se
I always feel a pity of developers spending time on environment-specific
issues. There is of course nothing wrong with the goal.
Anyway, I'd care more about people having ppc "available" in contrast to
"compilable". How many of gcc users compile gcc?..
The poeple that wants to use the compiler should not need to learn the
distribution internals.
Hence the ability to just install the tarball.

And I cannot agree more that I would preferably not deal with the
distributions issues, but this
is the way it is right now.

-- Ragge

a***@skeeve.com
2014-09-30 14:09:50 UTC
Permalink
Post by Anders Magnusson
Post by Aharon Robbins
Hi.
This is still broken. Is it supposed to be fixed yet?
It is actually a little more intriguing than I first thought. I tried
it on Ubuntu 12.04 for x86.
crt1 is libc dependent and should not be provided by the compiler (which
it was before, causing other bugs, as discussed on this list earlier).
Usually it is placed in /usr/lib, but Ubuntu has it in
/usr/lib/i386-linux-gnu/ instead. Adding this to the lib search path works.
Second problem is that /usr/include/sys/ is also missing on Ubuntu,
instead the sys stuff is in /usr/include/i386-linux-gnu/sys/.
This means that this path must also be added as a system include path.
Anyone have any idea to solve this in a reasonable simple non-intrusive way?
The issue is similar for x86_64 Ubuntu (and I think other Linux/GLIBC
systems) but with a different name for the directory. (x86_64 instead
of i386 in both cases).

Maybe have configure check for these paths and build up a macro
definition for the /usr/lib and /usr/include paths that it writes to a .h
file?

You can't avoid the mess, but doing it that way puts the hairy stuff into
configure/configure.ac instead of in the C code...

Just a thought,

Arnold
David Given
2014-10-02 22:17:11 UTC
Permalink
On 30.09.2014 16:09, ***@skeeve.com wrote:
[...]
Post by a***@skeeve.com
The issue is similar for x86_64 Ubuntu (and I think other Linux/GLIBC
systems) but with a different name for the directory. (x86_64 instead
of i386 in both cases).
This is a Debian thing, so any Linux system that's based on Debian will
be laid out like this. And it's not just i386 vs amd64; there's a whole
bunch of architectures which use multiarch. I have a system with armel
and armhf binaries, for example. Plus there's emulation...

[...]
Post by a***@skeeve.com
You can't avoid the mess, but doing it that way puts the hairy stuff into
configure/configure.ac instead of in the C code...
There should already be macros for doing this. Somewhere.
--
┌───  ───── http://www.cowlark.com ─────
│ "Blue is beautiful... blue is best...
│ I'm blue! I'm beautiful! I'm best!"
│ --- _Dougal and the Blue Cat_
Anders Magnusson
2014-10-03 13:36:56 UTC
Permalink
Post by David Given
[...]
Post by a***@skeeve.com
The issue is similar for x86_64 Ubuntu (and I think other Linux/GLIBC
systems) but with a different name for the directory. (x86_64 instead
of i386 in both cases).
This is a Debian thing, so any Linux system that's based on Debian will
be laid out like this. And it's not just i386 vs amd64; there's a whole
bunch of architectures which use multiarch. I have a system with armel
and armhf binaries, for example. Plus there's emulation...
[...]
Post by a***@skeeve.com
You can't avoid the mess, but doing it that way puts the hairy stuff into
configure/configure.ac instead of in the C code...
There should already be macros for doing this. Somewhere.
Most likely if debian is using this structure everywhere.
Hm, that means I have to jump into autoconf...

-- Ragge
Thorsten Glaser
2014-10-03 13:44:40 UTC
Permalink
Post by Anders Magnusson
Most likely if debian is using this structure everywhere.
Yes.
Post by Anders Magnusson
Hm, that means I have to jump into autoconf...
No. Can it wait a few more days? Maybe I can send it on
the weekend. Busy right now.

bye,
//mirabilos
--
<ch> you introduced a merge commit │<mika> % g rebase -i HEAD^^
<mika> sorry, no idea and rebasing just fscked │<mika> Segmentation
<ch> should have cloned into a clean repo │ fault (core dumped)
<ch> if I rebase that now, it's really ugh │<mika:#grml> wuahhhhhh
Anders Magnusson
2014-10-03 14:02:47 UTC
Permalink
Post by Thorsten Glaser
Post by Anders Magnusson
Most likely if debian is using this structure everywhere.
Yes.
Post by Anders Magnusson
Hm, that means I have to jump into autoconf...
No. Can it wait a few more days? Maybe I can send it on
the weekend. Busy right now.
Have it been waiting for some year now, it can as well wait a few more
days :-)
I'll wait for your solution recommendation.

-- Ragge
Loading...