[9fans] Compiling ken-cc on Linux

[9fans] Compiling ken-cc on Linux

[Vasudev Kamath]

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

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

[Ryan Gonzalez]

[-- Attachment #1: Type: text/plain, Size: 1455 bytes --]

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 <vasudev@copyninja.info>
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/

[-- Attachment #2: Type: text/html, Size: 2363 bytes --]

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

[Vasudev Kamath]

Ryan Gonzalez <rymg19@gmail.com> 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...)

Thanks Ryan, I will follow this.

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

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 632 bytes --]

That copy of the compilers was changed quite a bit by someone else, and I
only belatedly realised that.
I'll try to resurrect that one, since it would help me keep the Plan 9 and
Inferno compilers in sync, as well.

On 25 November 2015 at 17:24, Vasudev Kamath <vasudev@copyninja.info> wrote:

> Ryan Gonzalez <rymg19@gmail.com> 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...)
>
> Thanks Ryan, I will follow this.
>
>

[-- Attachment #2: Type: text/html, Size: 1167 bytes --]

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

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 603 bytes --]

On 25 November 2015 at 17:10, Vasudev Kamath <vasudev@copyninja.info> wrote:

> 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"
>

Of course, that particular one is just the latest crud from the constantly
mutating gcc/clang environments.
Why "DEFAULT" if it's not in fact the default?

[-- Attachment #2: Type: text/html, Size: 1019 bytes --]

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

[David du Colombier]

>> 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"
>
>
> Of course, that particular one is just the latest crud from the constantly
> mutating gcc/clang environments.
> Why "DEFAULT" if it's not in fact the default?

Yes, that's a recent change. And since you want backward compatibility, you now
have to define both _BSD_SOURCE/_SVID_SOURCE and _DEFAULT_SOURCE.

--
David du Colombier

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

[Ryan Gonzalez]

On November 26, 2015 6:10:43 AM CST, Charles Forsyth <charles.forsyth@gmail.com> wrote:
>On 25 November 2015 at 17:10, Vasudev Kamath <vasudev@copyninja.info>
>wrote:
>
>> 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"
>>
>
>Of course, that particular one is just the latest crud from the
>constantly
>mutating gcc/clang environments.
>Why "DEFAULT" if it's not in fact the default?

That's actually mostly glibc, the only library on earth that makes me want to bang my head on the floor.

I don't remember what GNU extension it is where glibc declares a function that Posix says should return no value as returning a value. So, when you use it like you're supposed to, you get errors.

Then there's also crap like https://github.com/kirbyfan64/qlibc/commit/fb550e9f35a20492bcb6a767e9e3d33e30c00c59. It was a PR I opened. strptime was undefined. Depending on the system, you need to define one of:

- _USE_XOPEN
- _XOPEN_SOURCE
- _BSD_SOURCE
and now:
- _DEFAULT_SOURCE
-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.

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

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 355 bytes --]

On 26 November 2015 at 18:15, Ryan Gonzalez <rymg19@gmail.com> wrote:

> the only library on earth that makes me want to bang my head on the floor.


There must be others, surely. What about graphics libraries with APIs
designed for FORTRAN (no data structures)?
What about ostensible crypto libraries that get their random numbers from
Walmart?

[-- Attachment #2: Type: text/html, Size: 664 bytes --]

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

[Andrew Simmons]

> the only library on earth that makes me want to bang my head on the floor.
>
You need to get out more

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

[Ryan Gonzalez]

On November 26, 2015 3:31:11 PM CST, Charles Forsyth <charles.forsyth@gmail.com> wrote:
>On 26 November 2015 at 18:15, Ryan Gonzalez <rymg19@gmail.com> wrote:
>
>> the only library on earth that makes me want to bang my head on the
>floor.
>
>
>There must be others, surely. What about graphics libraries with APIs
>designed for FORTRAN (no data structures)?
>What about ostensible crypto libraries that get their random numbers
>from
>Walmart?

All that is bad...but glibc is worse. The issue is that you kinda *have* to use it, no matter how simple or complicated or stupid your program is. It's just...there. If you want to use a sane(r) libc like musl, your users need another dependency.

Granted, there are other bad libraries or libraries with bad APIs (OpenSSL, SDL [especially for playing short sounds!], PCRE, etc.). However, you really don't *have* to use them. You can usually use RE2 or libregexp9 over PCRE, SFML over SDL, and so forth. NOT WITH GLIBC!!

*rant over now*
-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.

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

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 185 bytes --]

On 26 November 2015 at 21:49, Ryan Gonzalez <rymg19@gmail.com> wrote:

> All that is bad...but glibc is worse. The issue is that you kinda *have*
> to use it,


true, very true.

[-- Attachment #2: Type: text/html, Size: 463 bytes --]

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

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]

On 26 November 2015 at 21:51, Charles Forsyth <charles.forsyth@gmail.com>
wrote:

> On 26 November 2015 at 21:49, Ryan Gonzalez <rymg19@gmail.com> wrote:
>
>> All that is bad...but glibc is worse. The issue is that you kinda *have*
>> to use it,
>
>
> true, very true.


i remember glibc being my first instance of having to buy a bigger drive
just to build the thing.
with clang+llvm, I revisited that, and also had to buy more RAM and CPU.
i wondered whether to have a cron entry to speak "WTF?" into /dev/audio
every so often, to save my voice
(cron would be good because it could switch to "blistering barnacles!" when
children were present).

[-- Attachment #2: Type: text/html, Size: 1296 bytes --]

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

[Ryan Gonzalez]

On November 26, 2015 3:56:44 PM CST, Charles Forsyth <charles.forsyth@gmail.com> wrote:
>On 26 November 2015 at 21:51, Charles Forsyth
><charles.forsyth@gmail.com>
>wrote:
>
>> On 26 November 2015 at 21:49, Ryan Gonzalez <rymg19@gmail.com> wrote:
>>
>>> All that is bad...but glibc is worse. The issue is that you kinda
>*have*
>>> to use it,
>>
>>
>> true, very true.
>
>
>i remember glibc being my first instance of having to buy a bigger
>drive
>just to build the thing.
>with clang+llvm, I revisited that, and also had to buy more RAM and
>CPU.

I remember the time I was trying to build LLVM+Clang on Windows in debug mode. Because...MinGW...I actually surpassed the file size limit when linking Clang, so I had to rebuild EVERYTHING. Stupid thing took about an hour each time.

Because MinGW.

>i wondered whether to have a cron entry to speak "WTF?" into /dev/audio
>every so often, to save my voice
>(cron would be good because it could switch to "blistering barnacles!"
>when
>children were present).

It would be so funny if it malfunctioned:

WTF barnacles!
blistering WTF?
-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.

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

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]

On 26 November 2015 at 22:02, Ryan Gonzalez <rymg19@gmail.com> wrote:

> I remember the time I was trying to build LLVM+Clang on Windows in debug
> mode. Because...MinGW...I actually surpassed the file size limit when
> linking Clang, so I had to rebuild EVERYTHING. Stupid thing took about an
> hour each time.


Ah. Debug mode. It took me a while to suspect: I don't think you can build
debug mode at all now in 32-bit mode.
Even with gold instead of gnu ld it needs more memory than they can
represent in their arrangement of 32-bit user-mode address space.

[-- Attachment #2: Type: text/html, Size: 876 bytes --]

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

[David du Colombier]

>> I remember the time I was trying to build LLVM+Clang on Windows in debug
>> mode. Because...MinGW...I actually surpassed the file size limit when
>> linking Clang, so I had to rebuild EVERYTHING. Stupid thing took about an
>> hour each time.
>
>
> Ah. Debug mode. It took me a while to suspect: I don't think you can build
> debug mode at all now in 32-bit mode.
> Even with gold instead of gnu ld it needs more memory than they can
> represent in their arrangement of 32-bit user-mode address space.

If I remember correctly, the last time I built clang in debug mode, it used
more than 12 GB of memory during the linking. So yes, three times
bigger than the 32-bit address space.

--
David du Colombier

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

[Ryan Gonzalez]

On November 26, 2015 4:30:32 PM CST, David du Colombier <0intro@gmail.com> wrote:
>>> I remember the time I was trying to build LLVM+Clang on Windows in
>debug
>>> mode. Because...MinGW...I actually surpassed the file size limit
>when
>>> linking Clang, so I had to rebuild EVERYTHING. Stupid thing took
>about an
>>> hour each time.
>>
>>
>> Ah. Debug mode. It took me a while to suspect: I don't think you can
>build
>> debug mode at all now in 32-bit mode.
>> Even with gold instead of gnu ld it needs more memory than they can
>> represent in their arrangement of 32-bit user-mode address space.
>
>If I remember correctly, the last time I built clang in debug mode, it
>used
>more than 12 GB of memory during the linking. So yes, three times
>bigger than the 32-bit address space.

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!

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

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

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]

On 26 November 2015 at 23:08, Ryan Gonzalez <rymg19@gmail.com> 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.

[-- Attachment #2: Type: text/html, Size: 922 bytes --]

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

[Ryan Gonzalez]

On November 26, 2015 5:21:54 PM CST, Charles Forsyth <charles.forsyth@gmail.com> wrote:
>On 26 November 2015 at 23:08, Ryan Gonzalez <rymg19@gmail.com> 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 read in LBAC that one compiler had about 80 passes. All of which stored their results on disk. I can't help but shudder at the thought of how long those things took to compile...
-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.

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

[Brantley Coile]

[-- Attachment #1: Type: text/plain, Size: 1225 bytes --]

Clearly history is wrong. It would never be able to compile C in less than 18MB (1/2 of clang’s text size). Therefor Unix didn’t really happen. It’s all been a phone company conspiracy for world domination, like the NASA  not really putting a man on the moon. We were just *told* they had built a system in 1973 using a simple two pass compiler that would fit into about 28KW of memory. AT&T would have gotten away with it too, if it weren’t for their great  mistake—the 3B20. Results: no more “One system; it works."

> On Nov 26, 2015, at 6:21 PM, Charles Forsyth <charles.forsyth@gmail.com> wrote:
> 
> 
> On 26 November 2015 at 23:08, Ryan Gonzalez <rymg19@gmail.com <mailto:rymg19@gmail.com>> 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.


[-- Attachment #2: Type: text/html, Size: 2055 bytes --]

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

[Giacomo Tesio]

[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]

2015-11-27 0:21 GMT+01:00 Charles Forsyth <charles.forsyth@gmail.com>:

>
> On 26 November 2015 at 23:08, Ryan Gonzalez <rymg19@gmail.com> 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

[-- Attachment #2: Type: text/html, Size: 2111 bytes --]

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

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

[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 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 <tlaronde +AT+ polynum +dot+ com>
                     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

[Steffen Nurpmeso]

arnold@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

[Giacomo Tesio]

[-- Attachment #1: Type: text/plain, Size: 805 bytes --]

2015-11-27 13:42 GMT+01:00 <tlaronde@polynum.com>:

> 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

[-- Attachment #2: Type: text/html, Size: 1246 bytes --]

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 <tlaronde +AT+ polynum +dot+ com>
                     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

[Vasudev Kamath]

Hi Ryan,

Ryan Gonzalez <rymg19@gmail.com> 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]

[-- Attachment #1: Type: text/plain, Size: 2011 bytes --]

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 <vasudev@copyninja.info> wrote:
>
>Hi Ryan,
>
>Ryan Gonzalez <rymg19@gmail.com> 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.

[-- Attachment #2: Type: text/html, Size: 2609 bytes --]

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

[Vasudev Kamath]

Ryan Gonzalez <rymg19@gmail.com> 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(&t);
         ^
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

[trebol]

Ryan Gonzalez <rymg19@gmail.com> 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 <vasudev@copyninja.info>
> 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

[Ryan Gonzalez]

On November 27, 2015 11:16:02 AM CST, Vasudev Kamath <vasudev@copyninja.info> wrote:
>Ryan Gonzalez <rymg19@gmail.com> 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(&t);
>         ^
>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

[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

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

[Vasudev Kamath]

Ryan Gonzalez <rymg19@gmail.com> writes:

>>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!

Yes indeed. Now I'm having following error, after applying patch you
mentioned in the comment.

cc -m32  -o o.out y.tab.o lex.o /home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libcc.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
(cd 6c; mk  all)
mk: no recipe to make 'div.o'

So there is no div.c under src/cmd/6c. I see that old mkfile mkfile_o
has div.c but I don't know where original source file went. Removing
div.$O\ from mkfile gives the following error.

cc -m32  -o o.out cgen.o enam.o list.o mul.o peep.o reg.o sgen.o swt.o txt.o pswt.o pgen.o /home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libcc.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
cgen.o: In function `cgen':
/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:320: undefined reference to `sdiv2'
/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:323: undefined reference to `smod2'
/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:425: undefined reference to `sdivgen'
/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:427: undefined reference to `udivgen'
/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:632: undefined reference to `sdiv2'
/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:635: undefined reference to `smod2'
/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:759: undefined reference to `sdivgen'
/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:762: undefined reference to `udivgen'
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)

In both case I'm hitting dead end. Any hints for going forward?.

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

[Ryan Gonzalez]

On November 29, 2015 3:41:45 AM CST, Vasudev Kamath <vasudev@copyninja.info> wrote:
>Ryan Gonzalez <rymg19@gmail.com> writes:
>
>>>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!
>
>Yes indeed. Now I'm having following error, after applying patch you
>mentioned in the comment.
>
>cc -m32  -o o.out y.tab.o lex.o
>/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libcc.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
>
>(cd 6c; mk  all)
>mk: no recipe to make 'div.o'
>
>So there is no div.c under src/cmd/6c. I see that old mkfile mkfile_o
>has div.c but I don't know where original source file went. Removing
>div.$O\ from mkfile gives the following error.
>
>cc -m32  -o o.out cgen.o enam.o list.o mul.o peep.o reg.o sgen.o swt.o
>txt.o pswt.o pgen.o
>/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libcc.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
>
>cgen.o: In function `cgen':
>/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:320:
>undefined reference to `sdiv2'
>/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:323:
>undefined reference to `smod2'
>/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:425:
>undefined reference to `sdivgen'
>/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:427:
>undefined reference to `udivgen'
>/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:632:
>undefined reference to `sdiv2'
>/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:635:
>undefined reference to `smod2'
>/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:759:
>undefined reference to `sdivgen'
>/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:762:
>undefined reference to `udivgen'
>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)
>
>In both case I'm hitting dead end. Any hints for going forward?.

Well, the 6* compilers don't work ATM anyway, so I think you can just comment out the relevant lines in src/cmd/mkfile.
-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.

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

[Steffen Nurpmeso]

erik quanstrom <quanstro@quanstro.net> wrote:
 |> 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"

..hm, i have read his dissertation some years ago, from the end of
the 80s?, in which he translates the SunOS operating system manual
to German for almost a hundred pages?

--steffen

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

[tlaronde]

On Sun, Nov 29, 2015 at 07:57:58AM +0200, lucio@proxima.alt.za wrote:
>
> I remember using AutoCad 2.6 on an 8086 with a floating point
> accelerator and being impressed by the speed of its 3D rendering.  I
> have no idea how AutoCad behaves these days, but faster rendering
> would imply finishing before it even started.  So where is the real
> improvement?
>

You could have been impressed with Microstation (originally from
InterGraph) doing everything in scaled integers (it was clear it
came from Unix world too by several features, like regexp) so using
only the CPU. It run smoothly on 386 with DOS and DOS extender.
Once they "ported" it to Windows 95 and NT, we waited years for
the hardware to be able to give back the performance we had with
"poorer" hardware and OS. It almost took 10 years if I'm not
mistaken... And I hear that progress is "continuous". In another
world probably...

--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     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]

> One interesting thing is that for the past twenty years new
> architectures have been designed to run C code well.  Just check out
> the papers a ISCA.  Then why do we have to have such complicated
> compilers to generate code for it.

I'm pretty sure that you can lay that at C's door.  Had Algol or
Pascal been targeted, the architectures would not have so many
loopholes to go insane over.  C's pragmatism came back to bite it.

Of course, Algol or Pascal's discipline meant they never stood a
chance, so it's a lose-lose situation.  Let's be grateful that C
existed at all.  Had ADA or PL/I won that war, I doubt the Personal
Computer would have ever become affordable.

What it suggests to me is that the next programming notation should
first of all describe an architecture that can be engineered without
an infinite array of corner cutting features that can't be represented
in any semblance of programming code, which is why the compiler needs
to know about each and every one and even the likely circumstances
under which they ought to be used.

Then we can hand to the engineers a programming language they can
target with their architectures and they won't botch it too badly.

On further thought, it's obvious where it all went wrong: C is not one
language, it is only scaffolding.  Targeting it was bound to lead to
an infinite number of outcomes.

Lucio.

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

[lucio]

> I think the issue is trying to fix a broken problem.  Perfect
> compatibility is pretty much impossible, but most attempts done to fix
> it just shift the pain to somewhere else.  What's the quote about
> complexity not disappearing, just moving around?

Basically, increased CPU complexity provides increased performance,
which is then used to provide features that only unskilled users could
wish for.  I once described the syndrome as "I can't figure how this
application works, but the next release will be easier to use".

I remember using AutoCad 2.6 on an 8086 with a floating point
accelerator and being impressed by the speed of its 3D rendering.  I
have no idea how AutoCad behaves these days, but faster rendering
would imply finishing before it even started.  So where is the real
improvement?

Sadly, we developers buy all the hype just like uneducated users.
Another example: I switched from XYWrite to Brief 1.something because
the latter was as fast, but in addition it handled backspace in
replace mode correctly (XYWrite pulled back the remainder of the line,
where Brief actually replaced the precedingcharacter with a space and
moved the cursor under it).  Brief 2.1 was better, with worthwhile
improvements, whereas 3.1 was a dog.  I never promoted myself to it,
No doubt, the developer had made enough money from users like me to
afford a 386 PC and forgot that I would not have access to one :-(

In summary, we have the resources, we may as well squander them.  And
those who can't afford them?  "Let them eat cake!".

Lucio.

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

[Brantley Coile]

Not dogmatic. Just 38 years and I still believe small is beautify. 

One interesting thing is that for the past twenty years new architectures have been designed to run C code well. Just check out the papers a ISCA. Then why do we have to have such complicated compilers to generate code for it.

> On Nov 28, 2015, at 3:31 PM, Anthony Sorace <a@9srv.net> wrote:
> 
> Brantley wrote:
> 
>> 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...
> 
> Note the "almost all" in there. It's important not to get dogmatic about such things. The argument isn't that kencc is at precisely the perfect point on the simplicity-vs-optimization spectrum, but that it's pretty darn close, closer that known alternatives, and errs on the safer side. Likely there are optimizations or features in newer chipsets that would be worth supporting, but even so: we've got a long way to go before hitting gcc/clang levels.

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

[Anthony Sorace]

Brantley wrote:

> 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...

Note the "almost all" in there. It's important not to get dogmatic about such things. The argument isn't that kencc is at precisely the perfect point on the simplicity-vs-optimization spectrum, but that it's pretty darn close, closer that known alternatives, and errs on the safer side. Likely there are optimizations or features in newer chipsets that would be worth supporting, but even so: we've got a long way to go before hitting gcc/clang levels.

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

[Ryan Gonzalez]

On November 28, 2015 12:42:25 AM CST, da Tyga <cyberfonic@gmail.com> wrote:
>I have been following this discussion about the C compiler and can no
>longer stop myself from making a (snarky?) comment.
>

If you thing this is snarky, you've never visited the Final Fantasy XV board on GameFAQs! ;)

>The K&R 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.
>

I think the issue is trying to fix a broken problem. Perfect compatibility is pretty much impossible, but most attempts done to fix it just shift the pain to somewhere else. What's the quote about complexity not disappearing, just moving around?

I prefer languages that prefer correctness to perfect, cross-platform APIs that consist of 2000 functions, and no one knows what the hell half of them do.

>
>On 28 November 2015 at 12:01, erik quanstrom <quanstro@quanstro.net>
>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
>>
>>

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
CURRENTLY LISTENING TO: The Key We've Lost (Xenoblade Chronicles X)

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 <cyberfonic@gmail.com> wrote:
> 
> I have been following this discussion about the C compiler and can no longer stop myself from making a (snarky?) comment.
> 
> The K&R 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 <quanstro@quanstro.net> 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]

[-- Attachment #1: Type: text/plain, Size: 2480 bytes --]

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

The K&R 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 <quanstro@quanstro.net> 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
>
>

[-- Attachment #2: Type: text/html, Size: 2967 bytes --]