Antoine Leca | 1 Jun 2011 09:47
Picon
Favicon

Re: Static linking and glibc

David Given wrote:
> Sorry for resurrecting a really ancient thread, but if people want a
> lightweight, simple libc, the ACK has one under a liberal license:
>
> http://tack.hg.sourceforge.net/hgweb/tack/tack/file/4bb0576863a4/lang/cem/libcc.ansi
>
> It's really old but seems to be complete and reasonably bug-free. It
> also works on bare metal fine.
By the way, this libc is really a '91 fork of the MINIX one (of "Linux
is obsolete" fame.) And another branch of the fork, the present-day
MINIX's libc, compiles fine with pcc and works (on MINIX, that is; but
it should not be difficult to target another Unix-like.) Licensing is
essentially the same.

Be aware however that MINIX is currently diverging from its old code
base, and is forecast to use NetBSD libc in the future.

I guess newlib is another option, too. http://sourceware.org/newlib
<http://sourceware.org/newlib/>
Not GPL'd unless your target is Linux, IIUC.

Antoine

Iain Hibbert | 7 Jun 2011 12:29

Re: CVS commit: pcc/cc/ccom

On Sat, 4 Jun 2011, Iain Hibbert wrote:

> Modified Files:
> 	pcc/cc/ccom: Makefile.in
>
> Log Message:
> - explicit build rules for all files

wrt this, it is possible to provide implicit rules for source files spread
over several directories, using the VPATH variable.  But, I didn't use it
because I don't really know how portable VPATH is...

For example, the much simplified Makefile attached works fine when VPATH
is supported, without needing to list file paths and build rules
explicitly

I have tested VPATH as working with GNU and NetBSD make, and it looks like
the other major BSDs and SunOS support it also, not sure about OpenSolaris
(I found the source tree layout incomprehensible, could not find make
sources :) and win32 is a different issue (I guess mingw provides gmake,
but other environments?)

So, the question is.. what should the target standard for PCC build be? I
found a comment (relating to GNU make) that since Makefiles are not
portable, you should just use a portable make.. is it acceptable to say
that people might have to upgrade their make in order to build pcc?

iain

(NB POSIX does not specify VPATH, nor any equivalent)
(Continue reading)

Szabolcs Nagy | 7 Jun 2011 13:38

Re: CVS commit: pcc/cc/ccom

* Iain Hibbert <plunky <at> rya-online.net> [2011-06-07 11:29:31 +0100]:
> So, the question is.. what should the target standard for PCC build be? I
> found a comment (relating to GNU make) that since Makefiles are not
> portable, you should just use a portable make.. is it acceptable to say
> that people might have to upgrade their make in order to build pcc?
> 

imho it's ok if it works with gnumake and bsdmake as well

the ugliest part of the build system is the autoconf generated
configure scirpt anyway
i'd replace it with a single make.config file that is included
into other makefiles so it can be edited by hand easily at one
place without having to rely on a complicated configure script
(and i wouldn't have to rerun configure all the time)

Joel Dahl | 7 Jun 2011 15:32
Picon
Favicon

Re: CVS commit: pcc/cc/ccom

On 07-06-2011 13:38, Szabolcs Nagy wrote:
> * Iain Hibbert <plunky <at> rya-online.net> [2011-06-07 11:29:31 +0100]:
> > So, the question is.. what should the target standard for PCC build be? I
> > found a comment (relating to GNU make) that since Makefiles are not
> > portable, you should just use a portable make.. is it acceptable to say
> > that people might have to upgrade their make in order to build pcc?
> > 
> 
> imho it's ok if it works with gnumake and bsdmake as well
> 
> the ugliest part of the build system is the autoconf generated
> configure scirpt anyway
> i'd replace it with a single make.config file that is included
> into other makefiles so it can be edited by hand easily at one
> place without having to rely on a complicated configure script
> (and i wouldn't have to rerun configure all the time)

+1 ...

--

-- 
Joel

Thorsten Glaser | 7 Jun 2011 20:29
Picon
Gravatar

Re: CVS commit: pcc/cc/ccom

Iain Hibbert dixit:

>because I don't really know how portable VPATH is...

It’s not, and it’s supposedly “broken” in several
widespread make implementations.

bye,
//mirabilos
--

-- 
22:59⎜<Vutral> glaub ich termkit is kompliziert | glabe nicht das man
damit schneller arbeitet | reizüberflutung │ wie windows │ alles evil
zuviel bilder │ wie ein spiel | 23:00⎜<Vutral> die meisten raffen auch
nicht mehr von windows | 23:01⎜<Vutral> bilderbücher sind ja auch nich
wirklich verbreitet als erwachsenen literatur	‣ who needs GUIs thus?

Antoine Leca | 8 Jun 2011 12:42
Picon
Favicon

what should the target standard for PCC build be? [Was: CVS commit: pcc/cc/ccom]

Iain Hibbert wrote:
> (NB POSIX does not specify VPATH, nor any equivalent)
And autoconf advertises *against* it,
http://www.gnu.org/s/hello/manual/autoconf/Make-Target-Lookup.html I do
not how when it was last revised though (some material in this manual
appears somewhat antiquated.)

> So, the question is.. what should the target standard for PCC build be? I
> found a comment (relating to GNU make) that since Makefiles are not
> portable, you should just use a portable make.. is it acceptable to say
> that people might have to upgrade their make in order to build pcc?
I believe this is the real question.
The availability of VPATH or any other "advanced" feature is not the
problem if you consider building pcc, since chances are a port of GNU
make will be more common for
[insert-your-preferred-obscure-platform-here] as host environment, than
the complete set of POSIX tools that autoconf require... In fact, once
you have the set of POSIX tools available, compiling GNU make is as easy
than running ./configure && ./build.sh, unless your host environment  do
not conform to GNU target standards (32-bit, flat address space, etc.
See http://www.gnu.org/prep/standards/html_node/CPU-Portability.html)...
in which case buidling pcc will probably prove difficult too ;-).

What is worrying me here are two things:
1) This is opening a can of worm. If you say, "if your make is so basic
it does not support VPATH then upgrade to GNU make", why would you not
say "if your make is so basic it does not support the include statement
[not .include] then upgrade to GNU make"? Then you'll say "if your make
is so basic it does not support the % place holder then upgrade to GNU
make"?... At the end, GNU make will end being an absolute requirement.
(Continue reading)

Michael Shalayeff | 8 Jun 2011 13:11
Gravatar

Re: what should the target standard for PCC build be? [Was: CVS commit: pcc/cc/ccom]

re
i think we should ask a question: what is the target audience for pcc?
i would say that a person that compiles/uses pcc is:
1. capable of reading/writing c code;
2. capable of reading/writing makefiles;
3. not a complete moron.

having these assumptions i would say that changing target
naming for pcc has absolutely zero purpose.
in fact autoconf makes even less sense in this context.
is it really possible that someone who is adopting pcc
for their own project be not able to hack a makefile
for their building procedure?
and for sure anyone inserting pcc in the source tree will
not use autoconf but write own makefiles.
this is a compiler! it is supposed to be used by programmers!
having this whole autoconf mumbo-jumbo makes it only harder
for someone to figure out what are the necessary options
and/or rules for building from sources.
besides that someone is suddenly _forced_ to use autoconf
just to be able to build a piece of software that requires
3-lines makefile on any bsd system to build.
cu

On Wed, Jun 08, 2011 at 12:42:57PM +0200, Antoine Leca wrote:
> Iain Hibbert wrote:
> > (NB POSIX does not specify VPATH, nor any equivalent)
> And autoconf advertises *against* it,
> http://www.gnu.org/s/hello/manual/autoconf/Make-Target-Lookup.html I do
> not how when it was last revised though (some material in this manual
(Continue reading)

Thorsten Glaser | 8 Jun 2011 14:58
Picon
Gravatar

Re: what should the target standard for PCC build be? [Was: CVS commit: pcc/cc/ccom]

Antoine Leca dixit:

>1) This is opening a can of worm. If you say, "if your make is so basic
>it does not support VPATH then upgrade to GNU make", why would you not

It’s not an upgrade, it’s a downgrade – GNU make is non-free.

bye,
//mirabilos
--

-- 
22:59⎜<Vutral> glaub ich termkit is kompliziert | glabe nicht das man
damit schneller arbeitet | reizüberflutung │ wie windows │ alles evil
zuviel bilder │ wie ein spiel | 23:00⎜<Vutral> die meisten raffen auch
nicht mehr von windows | 23:01⎜<Vutral> bilderbücher sind ja auch nich
wirklich verbreitet als erwachsenen literatur	‣ who needs GUIs thus?

Nelson H. F. Beebe | 8 Jun 2011 16:38
Picon
Favicon

make and VPATH

pcc, lcc, and tcc have the great virtue of being small portable C
compilers, whereas gcc, opencc, pathcc, pgcc, ... are behemoths that
take hours to build and frequently fail to build on most platforms.

Let's preserve portability by keeping the pcc build infrastructure as
simple a possible, and avoid using ANY features of extended make
implementations, like either GNU make, or some BSD makes.  It may take
a few minutes of extra editing work in the pcc Makefiles, but that
effort pays off hugely when it is built a thousands of end-user sites.

Hardware comes and goes, and sometimes gets resurrected as virtual
machines, but software lives a lot longer.  Cross-platform software
portability is therefore of extreme importance.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe <at> math.utah.edu  -
- 155 S 1400 E RM 233                       beebe <at> acm.org  beebe <at> computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

Iain Hibbert | 9 Jun 2011 20:01

Re: make and VPATH

On Wed, 8 Jun 2011, Nelson H. F. Beebe wrote:
> Let's preserve portability by keeping the pcc build infrastructure as
> simple a possible, and avoid using ANY features of extended make
> implementations, like either GNU make, or some BSD makes.

I do agree with this, but I thought I'd better check that people didn't
have strong opinions against such long winded simplifications..

On the matter of configuration, I also agree that autoconf can be somewhat
ugly and I'm looking at reducing some of the entanglements that have grown
there, but simplifying it so that you can just type 'make' and have a
system constructed may be difficult to do in a way that is less ugly than
autoconf..  one advantage of autoconf of course, is that people already
thought of a whole load of gotchas and how to work around them

iain


Gmane