tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] using pcc to build tcc


From: u-tcc-uepj
Subject: Re: [Tinycc-devel] using pcc to build tcc
Date: Sat, 16 Apr 2016 10:50:30 +0200

Hello Michael and Sergey,

On Fri, Apr 15, 2016 at 06:54:55PM +0200, Michael Matz wrote:
> On Fri, 15 Apr 2016, Sergey Korshunoff wrote:
> > pcc -o i386-tcc tcc.c -DONE_SOURCE -DTCC_TARGET_I386 -I.  -Wall -g -O0 -lm 
> > -ldl
> > /tmp/ctm.Uao6qA: In function `set_pages_executable':
> > tccrun.c:238: undefined reference to `__clear_cache'
> > error: ld terminated with status 1
> > 
> > But it is OK if we add lib/libtcc1.c
> 
> That might break when building with other compilers again, because 
> libtcc1.c is the support routines for tcc, not for pcc or for e.g. GCC.  
> So if pcc doesn't provide a __clear_cache implementation then it, and only 
> it needs to be implemented by something in tcc.
> 
> So, the implementation of __clear_cache (and only it!) needs to be 
> provided by tcc itself, but only when compiling with pcc.  I.e. some file 

__clear_cache() or the lack of it is not pcc-specific at all, actually
it is gcc-specific by definition and gcc-version-specific too.

> splitting would be in order.

For the record,

tcc 0.9.26 (not the mob) bootstraps fine by pcc-1.2.0.DEVEL-20160413
on Linux ia32 with musl.

The result is the same as when bootstrapping (in both cases 3-pass)
via gcc-5.2.0.

This discussion made me look at the commit
5ee097fce9dee7eb4dc782c5d6bce75c01243d63
"allow to compile tcc by pcc"
Regretfully, I do not see a point with any of the changes.

1. "addr_t vs int" looks hardly pcc-specific, regardless whether
it is "right" or "wrong". It belongs elsewhere, in a different kind
of commit, if any.

(Could it be the case that the problem it seems to solve stems from
a particular build environment rather than from pcc? Or that non-pcc
builds hid a bug which the seyko's pcc-toolchain uncovered?)

2. the change to "#if defined(__linux__)" is both unnecessary
(CC="pcc -D__linux" does the job without polluting the tcc source)
and in the first hand wrong, replacing an unreliable hack with another one.

Actually the check is needed for a flag "we are building tcc to be used
to build for linux" (like TCC_TARGET_OS_LINUX ?) which should
be set by configure.

The "-D__linux" happened to be usable with pcc for this purpose
but should be of course replaced by something less ambiguous.

3. __clear_cache() conditional should not check for __PCC__
but for a HAVE___CLEAR_CACHE feature.

Checking for a certain tool and making assumptions about its properties
is broken by design (nothing personal, this is unfortunately a widely
spread and harmful practice).

This actual case could be in a easy and non-disruptive way worked around
by CC="pcc -D__clear_cache(a,b)=", until a proper feature option/test
would be added to configure (again, a feature test, not a compiler
implementation test).

My two cents.

Regards,
Rune




reply via email to

[Prev in Thread] Current Thread [Next in Thread]