Re: [9fans] Compiling ken-cc on Linux

[trebol]

Ryan Gonzalez  wrote:

> See
> https://bitbucket.org/plan9-from-bell-labs/9-cc/issues/1/problems-building-under-x64-linux
> for some tips on fixing various errors you may encounter, including this
> one. (I opened that issue like 8 months ago...)
>
> On Wed, Nov 25, 2015 at 11:10 AM, Vasudev Kamath 
> wrote:
>
> >
> > Hi,
> >
> > I'm trying to compile ken-cc from ¹. Its giving me following error
> >
> > cc -c -m32 -g -O
> > -I/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include
> > -I/home/vasudev/Documents/C_programming/compilers/9-cc/include -DLINUX_386
> > -I../cmd/ 9obj.c
> > In file included from
> > /home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include/lib9.h:9:0,
> >  from 9obj.c:5:
> > /usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and
> > _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
> >  # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use
> > _DEFAULT_SOURCE"
> >^
> > 9obj.c:8:22: fatal error: 9c/9.out.h: No such file or directory
> > compilation terminated.
> > mk: cc -c -m32 ...  : exit status=exit(1)
> > mk: for j in ...  : exit status=exit(1)
> >
> > I can't find 9c under src/cmd folder. Any hints on how to get it
> > compiled?.
> >
> > Cheers,
> >
> > ¹ https://bitbucket.org/plan9-from-bell-labs/9-cc/overview
> >
> >
>
>
> -- 
> Ryan
> [ERROR]: Your autotools build scripts are 200 lines longer than your
> program. Something’s wrong.
> http://kirbyfan64.github.io/
h+
h+

Re: [9fans] Compiling ken-cc on Linux

[Vasudev Kamath]

Ryan Gonzalez  writes:

> Try going to the top of mathi.h and putting:
>
> #undef isnan
> #undef isinf
>
> Stupid macros that don't look like macros.

That worked. Even I didn't realize those as macros. But now I land in
new error.

/usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE 
are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
 # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
   ^
In file included from 
/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include/lib9.h:19:0,
 from fdlibm/fdlibm.h:2,
 from fdlibm/s_isnan.c:20:
fdlibm/s_isnan.c:22:6: error: expected identifier or ‘(’ before ‘sizeof’
  int isnan(double x)
  ^
mk: cc -c -m32 ...  : exit status=exit(1)
mk: for j in ...  : exit status=exit(1)

So I went and put #undef isnan again before #include "fdlibm.h" in
s_isnan.c and now I stop at a new error, again not mentioned in your
reported issue.

Posix.c: In function ‘myctime’:
Posix.c:9:9: warning: implicit declaration of function ‘ctime’ 
[-Wimplicit-function-declaration]
  return ctime();
 ^
Posix.c:9:9: warning: return makes pointer from integer without a cast 
[-Wint-conversion]
cc -m32  -o o.out ar.o Posix.o 
/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libmach.a 
/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libbio.a 
/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/lib9.a 
ar.o: In function `page':
/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/iar/ar.c:1120: 
warning: the use of `mktemp' is dangerous, better use `mkstemp' or `mkdtemp'
/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libmach.a(obj.o):(.rodata+0x198):
 undefined reference to `_is9'
/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libmach.a(obj.o):(.rodata+0x19c):
 undefined reference to `_read9'
collect2: error: ld returned 1 exit status
mk: cc -m32  ...  : exit status=exit(1)
mk: for j in ...  : exit status=exit(1)
mk: for j in ...  : exit status=exit(1)

I guess this is because of commenting out 9obj.c from compilation. So I
modified 9obj.c, below is the patch

vasudev@rudra:~/Documents/C_programming/compilers/9-cc$ hg diff 
src/libmach/obj.c 
diff -r 65fb8bb56c59 src/libmach/obj.c
--- a/src/libmach/obj.c Thu Apr 23 11:11:38 2015 +0100
+++ b/src/libmach/obj.c Fri Nov 27 22:44:29 2015 +0530
@@ -24,14 +24,14 @@
 int_is5(char*),
_is6(char*),
_is8(char*),
-   _is9(char*),
+   /* _is9(char*), */
_isk(char*),
_isq(char*),
_isv(char*),
_read5(Biobuf*, Prog*),
_read6(Biobuf*, Prog*),
_read8(Biobuf*, Prog*),
-   _read9(Biobuf*, Prog*),
+   /* _read9(Biobuf*, Prog*), */
_readk(Biobuf*, Prog*),
_readq(Biobuf*, Prog*),
_readv(Biobuf*, Prog*);
@@ -63,7 +63,7 @@
/*[ObjSparc64]*/{0, 0,},
/*[ObjAmd64]*/  "amd64 .6", _is6, _read6,
/*[ObjSpim]*/   {0, 0,},
-   /*[ObjPower64]*/"power64 .9",   _is9, _read9,
+   /*[ObjPower64]*//* "power64 .9",_is9, _read9, */
/*[Maxobjtype]*/0, 0
 };

That took compilation further but now it breaks at point 4 in your
issue. I hope I won't encounter more new issues :-).

Cheers,

Re: [9fans] Compiling ken-cc on Linux

[Vasudev Kamath]

Hi Ryan,

Ryan Gonzalez  writes:
> See
> https://bitbucket.org/plan9-from-bell-labs/9-cc/issues/1/problems-building-under-x64-linux
> for some tips on fixing various errors you may encounter, including
> this one. (I opened that issue like 8 months ago...)

I followed your reported issue. I could fix first 2 points but I get
different error after that.

(cd src/libmath; mk  all)
/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libmath.a 
doesn't exist: assuming it will be an archive
cc -c -m32 -g -O 
-I/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include 
-I/home/vasudev/Documents/C_programming/compilers/9-cc/include -DLINUX_386 
blas.c
In file included from 
/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include/lib9.h:9:0,
 from blas.c:1:
/usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE 
are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
 # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
   ^
In file included from 
/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include/lib9.h:19:0,
 from blas.c:1:
/home/vasudev/Documents/C_programming/compilers/9-cc/include/mathi.h:59:12: 
error: expected identifier or ‘(’ before ‘sizeof’
 extern int isnan(double);
^
mk: cc -c -m32 ...  : exit status=exit(1)
mk: for j in ...  : exit status=exit(1)

I tried to find sizeof in mathi.h but I can't really find
anything. (Yeah there is no sizeof in either mathi.h or related
files). 

I'm unsure what the error is indicating. Any idea on how to proceed further?.

Re: [9fans] Compiling ken-cc on Linux

[Ryan Gonzalez]

Try going to the top of mathi.h and putting:

#undef isnan
#undef isinf

Stupid macros that don't look like macros.

On November 27, 2015 10:50:20 AM CST, Vasudev Kamath  
wrote:
>
>Hi Ryan,
>
>Ryan Gonzalez  writes:
>> See
>>
>https://bitbucket.org/plan9-from-bell-labs/9-cc/issues/1/problems-building-under-x64-linux
>> for some tips on fixing various errors you may encounter, including
>> this one. (I opened that issue like 8 months ago...)
>
>I followed your reported issue. I could fix first 2 points but I get
>different error after that.
>
>(cd src/libmath; mk  all)
>/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libmath.a
>doesn't exist: assuming it will be an archive
>cc -c -m32 -g -O
>-I/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include
>-I/home/vasudev/Documents/C_programming/compilers/9-cc/include
>-DLINUX_386 blas.c
>In file included from
>/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include/lib9.h:9:0,
> from blas.c:1:
>/usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and
>_SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
># warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use
>_DEFAULT_SOURCE"
>   ^
>In file included from
>/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include/lib9.h:19:0,
> from blas.c:1:
>/home/vasudev/Documents/C_programming/compilers/9-cc/include/mathi.h:59:12:
>error: expected identifier or ‘(’ before ‘sizeof’
> extern int isnan(double);
>^
>mk: cc -c -m32 ...  : exit status=exit(1)
>mk: for j in ...  : exit status=exit(1)
>
>I tried to find sizeof in mathi.h but I can't really find
>anything. (Yeah there is no sizeof in either mathi.h or related
>files). 
>
>I'm unsure what the error is indicating. Any idea on how to proceed
>further?.

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.

Re: [9fans] Compiling ken-cc on Linux

[Ryan Gonzalez]

On November 27, 2015 11:16:02 AM CST, Vasudev Kamath  
wrote:
>Ryan Gonzalez  writes:
>
>> Try going to the top of mathi.h and putting:
>>
>> #undef isnan
>> #undef isinf
>>
>> Stupid macros that don't look like macros.
>
>That worked. Even I didn't realize those as macros. But now I land in
>new error.
>
>/usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and
>_SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
># warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use
>_DEFAULT_SOURCE"
>   ^
>In file included from
>/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include/lib9.h:19:0,
> from fdlibm/fdlibm.h:2,
> from fdlibm/s_isnan.c:20:
>fdlibm/s_isnan.c:22:6: error: expected identifier or ‘(’ before
>‘sizeof’
>  int isnan(double x)
>  ^
>mk: cc -c -m32 ...  : exit status=exit(1)
>mk: for j in ...  : exit status=exit(1)
>
>So I went and put #undef isnan again before #include "fdlibm.h" in
>s_isnan.c and now I stop at a new error, again not mentioned in your
>reported issue.
>
>Posix.c: In function ‘myctime’:
>Posix.c:9:9: warning: implicit declaration of function ‘ctime’
>[-Wimplicit-function-declaration]
>  return ctime();
> ^
>Posix.c:9:9: warning: return makes pointer from integer without a cast
>[-Wint-conversion]
>cc -m32  -o o.out ar.o Posix.o
>/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libmach.a
>/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libbio.a
>/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/lib9.a
>
>ar.o: In function `page':
>/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/iar/ar.c:1120:
>warning: the use of `mktemp' is dangerous, better use `mkstemp' or
>`mkdtemp'
>/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libmach.a(obj.o):(.rodata+0x198):
>undefined reference to `_is9'
>/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libmach.a(obj.o):(.rodata+0x19c):
>undefined reference to `_read9'
>collect2: error: ld returned 1 exit status
>mk: cc -m32  ...  : exit status=exit(1)
>mk: for j in ...  : exit status=exit(1)
>mk: for j in ...  : exit status=exit(1)
>
>I guess this is because of commenting out 9obj.c from compilation. So I
>modified 9obj.c, below is the patch
>
>vasudev@rudra:~/Documents/C_programming/compilers/9-cc$ hg diff
>src/libmach/obj.c 
>diff -r 65fb8bb56c59 src/libmach/obj.c
>--- a/src/libmach/obj.c Thu Apr 23 11:11:38 2015 +0100
>+++ b/src/libmach/obj.c Fri Nov 27 22:44:29 2015 +0530
>@@ -24,14 +24,14 @@
> int_is5(char*),
>_is6(char*),
>_is8(char*),
>-   _is9(char*),
>+   /* _is9(char*), */
>_isk(char*),
>_isq(char*),
>_isv(char*),
>_read5(Biobuf*, Prog*),
>_read6(Biobuf*, Prog*),
>_read8(Biobuf*, Prog*),
>-   _read9(Biobuf*, Prog*),
>+   /* _read9(Biobuf*, Prog*), */
>_readk(Biobuf*, Prog*),
>_readq(Biobuf*, Prog*),
>_readv(Biobuf*, Prog*);
>@@ -63,7 +63,7 @@
>/*[ObjSparc64]*/{0, 0,},
>/*[ObjAmd64]*/  "amd64 .6", _is6, _read6,
>/*[ObjSpim]*/   {0, 0,},
>-   /*[ObjPower64]*/"power64 .9",   _is9, _read9,
>+   /*[ObjPower64]*//* "power64 .9",_is9, _read9,
>*/
>/*[Maxobjtype]*/0, 0
> };
>
>That took compilation further but now it breaks at point 4 in your
>issue. I hope I won't encounter more new issues :-).
>

Ah, yes, I completely forgot about that part. :/ Good luck with the rest of the 
compilation! You'll need it!

>Cheers,

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.

Re: [9fans] Compiling ken-cc on Linux

[tlaronde]

On Fri, Nov 27, 2015 at 09:13:20AM +0100, Giacomo Tesio wrote:
> 
> I know nothing about compilers, but actually gcc and clang dimension and
> complexity is astonishing.

It's not astonishing: it's research. They want to prove that a black
hole does exist. So they write a "model", a software implementation of
black holes that is, indeed, able to absorb every bit of RAM, every
block of disk, every CPU cycle so that whatever is put in a computer,
nothing can ever go out. And the thing finally collapses due to its very
size: so big that no one is able to understand and correct it. Then it 
is called: "standard", a de facto no varietur, not because it is perfect
not to mention useful, but because it is impossible to evolve.

It's a kind of success (though there are a lot of competing
implementations of software black holes, improving almost endlessly:
less and less signal, more and more noise).
-- 
Thierry Laronde 
 http://www.kergis.com/
 http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Compiling ken-cc on Linux

[lucio]

> What about ostensible crypto libraries that get their random numbers from
> Walmart?

Do they get those over the counter?

Lucio.

Re: [9fans] Compiling ken-cc on Linux

[tlaronde]

On Fri, Nov 27, 2015 at 03:07:30PM +0100, Giacomo Tesio wrote:
> 
> Funny, but actually I was wondering if there is any subtle issue in the
> standards of the C language that makes it somehow hard to implement.

I guess it depends on what is the "standard". The naked C language is
(was) simple. The guaranteed routines were something else: the C
library---contrary to Pascal, for example, where some routines were
part of the language.

That's the way I understand Charles' irony: it seems difficult to find a
more simple (and efficient) language as C.

There are problem with standards but there are far more problems with
people that do not refer to standards and do not know what they use.
Using Plan9' APE is a good way, for example, to ensure that one is only
using POSIX. Yes, it is not up-to-date since POSIX evolves; but failing
to compile with APE is generally not due to missing pieces in APE but to
fuzzy use of things outside POSIX in the program one wants to compile. 

BTW this was already the case when the Plan9 paper about APE was 
written. But it's getting worse.
-- 
Thierry Laronde 
 http://www.kergis.com/
 http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Compiling ken-cc on Linux

[Giacomo Tesio]

2015-11-27 13:42 GMT+01:00 :

> On Fri, Nov 27, 2015 at 09:13:20AM +0100, Giacomo Tesio wrote:
> >
> > I know nothing about compilers, but actually gcc and clang dimension and
> > complexity is astonishing.
>
> It's not astonishing: it's research. They want to prove that a black
> hole does exist.
>

Funny, but actually I was wondering if there is any subtle issue in the
standards of the C language that makes it somehow hard to implement.
For example I've met a few times weird implementations of libraries and
frameworks dictated by broken standards: once they are in, they can never
be removed due to backward compatibility. I thought that Charles (that also
implemented the Limbo compiler) might have referenced these kind of issues
in his pun.


Giacomo

Re: [9fans] Compiling ken-cc on Linux

[Steffen Nurpmeso]

 |How they ever got it going on a system with 64Kbytes of address space\
 |, I'll never know.

Yeah!

--steffen

Re: [9fans] Compiling ken-cc on Linux

[erik quanstrom]

> Funny, but actually I was wondering if there is any subtle issue in the
> standards of the C language that makes it somehow hard to implement.
> For example I've met a few times weird implementations of libraries and
> frameworks dictated by broken standards: once they are in, they can never
> be removed due to backward compatibility. I thought that Charles (that also
> implemented the Limbo compiler) might have referenced these kind of issues
> in his pun.

i think the simple answer is: no.  but many folks just love complexity, and are
determined to find it.  if you give such a person one problem, they'll come back
with two problems.  i call these folks complicators.  don't be a complicator.

(i have to remind myself this from time to time.)

- erik

Re: [9fans] Compiling ken-cc on Linux

[Brantley Coile]

Great point. And you actually don’t meet the minimum requirement for snarky 
messages.

You argue the the large compilers are due to the increase in the complexity of 
the specification and the complexities of generating code for the Intel 
instruction set. To some extent you are correct. A modern C compiler would be 
larger than a PDP-11 compiler. In fact, I would argue it should be about twice 
the size of the PDP compiler.

I’m kind of cheating when I say that, because I know for a fact that a ANSI C 
compiler would be that much larger because that’s about the size of the Plan 9 
C compiler compared to the PDP-11 compiler. The 7th Edition C compiler was 
about 12,000 lines. Plan9’s compiler for the 64 bit x86 instruction set is 
22,000 lines of source.

One could argue that the Plan 9 C compiler lacks the modern optimizations that 
the other compilers have. This would be true. But I would argue that almost all 
of those optimizations are either not needed because the coder could have 
optimized his code in the first place, or are way past the point of diminishing 
returns. So, I would say that those optimization fill a much needed gap.

Niklaus Wirth pointed out that the best characteristic of a language used to 
create very efficient programs is predictability. This is especially true for 
the modern architectures. We are much smarter than any compiler will ever be 
and the knowledge of the micro architecture is required to write the fastest 
code. (It doesn’t really change that fast over the years.) The programmer does 
the work. That predictability is best delivered when the compiler only 
optimized inefficiencies it generates and not try to outsmart the programmer.

I for one really enjoyed your point. 

  Brantley

> On Nov 28, 2015, at 1:42 AM, da Tyga  wrote:
> 
> I have been following this discussion about the C compiler and can no longer 
> stop myself from making a (snarky?) comment.
> 
> The K standard for C was very much written when the C language was a higher 
> than assembler language for the PDP-11 (at least that's how I became 
> acquainted with it back in 1976).  Most of us, in those days, welcomed 
> something that was more high level than macro-assembler and yet amenable to 
> writing operating systems and utilities (unlike FORTRAN, ALGOL and COBOL of 
> that era).  Many of us would use the -s switch to check the generated 
> assembler code and in some cases even modify the assembler code for selected 
> functions to get exactly the desired result.
> 
> The PDP-11 had a rather simple instruction set, thus the compiler produced 
> relatively predictable code.  The undefined behaviours in many cases meant 
> that at least on the PDP-11 we would know what to expect.  It was only once 
> code was ported to other systems that these assumptions started getting 
> sorely tested.
> 
> Fast forward to present time, we have a bloated C standard and even more 
> bloated C++ standards.  The target instruction sets are rich with lots of 
> special case instructions; out of sequence execution; multi-level caches add 
> further constraints.  So today's compilers need to analyse complex source 
> code to run with good performance on extremely complex targets.  We shouldn't 
> forget that in the case of the x86 family the compilers need to optimise for 
> an ever evolving instruction set and retain backward compatibility across 
> earlier variants.
> 
> 
> On 28 November 2015 at 12:01, erik quanstrom  wrote:
> > Funny, but actually I was wondering if there is any subtle issue in the
> > standards of the C language that makes it somehow hard to implement.
> > For example I've met a few times weird implementations of libraries and
> > frameworks dictated by broken standards: once they are in, they can never
> > be removed due to backward compatibility. I thought that Charles (that also
> > implemented the Limbo compiler) might have referenced these kind of issues
> > in his pun.
> 
> i think the simple answer is: no.  but many folks just love complexity, and 
> are
> determined to find it.  if you give such a person one problem, they'll come 
> back
> with two problems.  i call these folks complicators.  don't be a complicator.
> 
> (i have to remind myself this from time to time.)
> 
> - erik
> 
> 

Re: [9fans] Compiling ken-cc on Linux

[da Tyga]

I have been following this discussion about the C compiler and can no
longer stop myself from making a (snarky?) comment.

The K standard for C was very much written when the C language was a
higher than assembler language for the PDP-11 (at least that's how I became
acquainted with it back in 1976).  Most of us, in those days, welcomed
something that was more high level than macro-assembler and yet amenable to
writing operating systems and utilities (unlike FORTRAN, ALGOL and COBOL of
that era).  Many of us would use the -s switch to check the generated
assembler code and in some cases even modify the assembler code for
selected functions to get exactly the desired result.

The PDP-11 had a rather simple instruction set, thus the compiler produced
relatively predictable code.  The undefined behaviours in many cases meant
that at least on the PDP-11 we would know what to expect.  It was only once
code was ported to other systems that these assumptions started getting
sorely tested.

Fast forward to present time, we have a bloated C standard and even more
bloated C++ standards.  The target instruction sets are rich with lots of
special case instructions; out of sequence execution; multi-level caches
add further constraints.  So today's compilers need to analyse complex
source code to run with good performance on extremely complex targets.  We
shouldn't forget that in the case of the x86 family the compilers need to
optimise for an ever evolving instruction set and retain backward
compatibility across earlier variants.


On 28 November 2015 at 12:01, erik quanstrom  wrote:

> > Funny, but actually I was wondering if there is any subtle issue in the
> > standards of the C language that makes it somehow hard to implement.
> > For example I've met a few times weird implementations of libraries and
> > frameworks dictated by broken standards: once they are in, they can never
> > be removed due to backward compatibility. I thought that Charles (that
> also
> > implemented the Limbo compiler) might have referenced these kind of
> issues
> > in his pun.
>
> i think the simple answer is: no.  but many folks just love complexity,
> and are
> determined to find it.  if you give such a person one problem, they'll
> come back
> with two problems.  i call these folks complicators.  don't be a
> complicator.
>
> (i have to remind myself this from time to time.)
>
> - erik
>
>

Re: [9fans] Compiling ken-cc on Linux

[Steffen Nurpmeso]

arn...@skeeve.com wrote:
 |> Alternative compilers, like tcc, only build C on very few architectures /
 |> os with almost no optimization: they are much smaller, but still not
 |> standard compliant.

 |TCC compiles really fast, and it's (finally) good enough that I can use
 |it for my personal development / testing, but I would not use it to
 |build a production binary, the code quality is much poorer. On Linux
 |you can't use it for debugging either - it doesn't generate the
 |debug info you need. :-(  For that, GCC and clang are the way to go.

I just started to use tcc(1) for faster recompilations during my
chaotic way of walking, and it was an a-ha just as was the
detection of jikes(1) compared to the Java-shipped compiler in,
say, 1999.  (And in fact that was the reason to start learning
C++, later C, and not continue with only Perl and Java.)

  ?2[sdaoden@wales ]$ time make CC=clang devel >/dev/null 2>&1
  0m55.37s real 0m29.44s user 0m27.24s system
  ?0[sdaoden@wales ]$ time make CC=gcc devel >/dev/null 2>&1
  0m50.04s real 0m26.13s user 0m24.92s system
  ?2[sdaoden@wales ]$ time make CC=tcc devel >/dev/null 2>&1
  0m17.90s real 0m7.29s user 0m12.07s system

But without reconfiguration in normal development it feels more
drastic than these lines suggest.  Of course, ship-out user code.
Plan9 users don't have those problems in their native
self-contained environment, also the UnixWare and native Sun cc's
are ok, but on *BSD and Linux you really don't have any more
options.  E.g., i just tried pcc(1), which could be one, on
a Linux box:

  Using C compiler $CC="pcc"
  /usr/include/stdc-predef.h:59: warning: __STDC_ISO_10646__ redefined 
(previously defined at "./___tmp12443.c" line -9)
  ld: cannot find crtbegin.o: No such file or directory
well we could but..
  ld: cannot find -lpcc
there is none!
  error: ld terminated with status 1
  ERROR: i cannot compile a "Hello world" via
 pcc -I/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/include/ 
-I/home/sdaoden/usr/include -I/usr/local/include -I/usr/include  
-L/home/sdaoden/usr/lib -L/lib -L/usr/local/lib -L/usr/lib

That after some work already.  VoidLinux has a package, though,
i should try that.

 |I agree with the general sentiments - GLIBC and GCC are both bloated.
 |But for the day-to-day work that *I* do, they're livable.

Due to the large community and the commercial interest (remember
the billion dollar campaign of IBM over a decade ago) you have the
newest technologies in a usable state.  I.e., i've found a drastic
memory bug in Jörg Schilling's Bourne shell (likely developed only
on Solaris rooted) simply by compiling and starting it under
FreeBSD.  And i have found stack read violations simply by running
them under Linux?  I always had my own memory allocation stuff
with tracing and logging and canaries, but read violations are
hard to detect without real red zones.  And it's easy to simply
look into /proc/PID/ and see a lot of things at a glance via ls(1)
/ cat(1) that otherwise require special programs or things which
are real horror for me, like dtrace (no!).  Acid has it at least
in its name.  Never liked debug robots anyway.

But otherwise i always like going back to BSD, i guess just Plan9
people like to come back into the grown rather self-contained
environment.  You install the ISO and are ready to go, with
network and development.  I.e., i install a new FreeBSD and the
configuration files from 2002 still work.  That is valuable.
I think there is pcc for NetBSD, also.

--steffen

Re: [9fans] Compiling ken-cc on Linux

[erik quanstrom]

> memory bug in Jörg Schilling's Bourne shell (likely developed only
> on Solaris rooted) simply by compiling and starting it under
> FreeBSD.  And i have found stack read violations simply by running

given cdrtools, this is not a surprise.  
https://en.wikipedia.org/wiki/Cdrtools#Device_naming
"all the world's a vax^h^h^hscsi"

- erik

[9fans] libsec/port/hmac.c

[erik quanstrom]

hmac_x(uchar *p, ulong len, uchar *key, ulong klen, uchar *digest, DigestState 
*s,
DigestState*(*x)(uchar*, ulong, uchar*, DigestState*), int xlen)
{
int i;
uchar pad[Hmacblksz+1], innerdigest[256];

if(xlen > sizeof(innerdigest))
return nil;
if(klen > Hmacblksz)
return nil;

/* first time through */
if(s == nil || s->seeded == 0){
>>  if(klen >= Hmacblksz){
print("klen too large: %lud", klen);
assert(0);

i'm pretty sure that > is ment here, not >=.  am i missing something?

- erik

Re: [9fans] Compiling ken-cc on Linux

[Giacomo Tesio]

2015-11-27 0:21 GMT+01:00 Charles Forsyth :

>
> On 26 November 2015 at 23:08, Ryan Gonzalez  wrote:
>
>> Holy crap, that's crazy. I built it in debug mode on Linux, but I don't
>> think it used that much. I only have 6 GB right now!
>
>
> You have to remember that a C compiler is one of the largest, most complex
> software components that human beings have ever had to produce.
> The original C reference manual made it look deceptively easy, but really
> there's a ton of stuff going on in there, as you can see.
> How they ever got it going on a system with 64Kbytes of address space,
> I'll never know.
>

I'd love to read more about this, Charles. :-)

I know nothing about compilers, but actually gcc and clang dimension and
complexity is astonishing.
I've always thought that this is due to their desire to compile many
different language optimized for many different OS and architectures on
many different OS and architecture.

Alternative compilers, like tcc, only build C on very few architectures /
os with almost no optimization: they are much smaller, but still not
standard compliant.


How can it be?


Giacomo

Re: [9fans] Compiling ken-cc on Linux

[arnold]

> I know nothing about compilers, but actually gcc and clang dimension and
> complexity is astonishing.
> I've always thought that this is due to their desire to compile many
> different language optimized for many different OS and architectures on
> many different OS and architecture.

That is a very large part of the reason. People also have used GCC
(and I guess clang/llvm) as research vehicles, and such bits and pieces
get included even if not stricly necessary. Also note that C++ is a
hugely complicated langauge, and getting all the standards stuff right
for it (and even for C) takes a lot of work.  But you summed it up:

* Multiple languages (front ends)
* Multiple architectures (code generators / backends)
* Optimized - a huge part of GCC is different kinds of optimizers

> Alternative compilers, like tcc, only build C on very few architectures /
> os with almost no optimization: they are much smaller, but still not
> standard compliant.
>
> How can it be?

In the case of TCC, there is no real guiding hand. People do what they
feel like, or as they need it.  Also, the original code base leaves a
lot to be desired from a software design / engineering standpoint.
(Function names consisting of a single letter!)

TCC compiles really fast, and it's (finally) good enough that I can use
it for my personal development / testing, but I would not use it to
build a production binary, the code quality is much poorer. On Linux
you can't use it for debugging either - it doesn't generate the
debug info you need. :-(  For that, GCC and clang are the way to go.

I agree with the general sentiments - GLIBC and GCC are both bloated.
But for the day-to-day work that *I* do, they're livable.

My two cents,

Arnold