On Wed, Nov 25, 2015 at 11:10 AM, Vasudev = Kamath <vasudev@copyninja.info> wrote:

Hi,

I'm trying to compile ken-cc from =C2=B9. Its giving me following error=

cc -c -m32 -g -O -I/home/vasudev/Documents/C_programming/compilers/9-cc/Lin= ux/386/include -I/home/vasudev/Documents/C_programming/compilers/9-cc/inclu= de -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,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0from 9obj.c:5= :
/usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and _SVI= D_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
=C2=A0# warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEF= AULT_SOURCE"
=C2=A0 =C2=A0^
9obj.c:8:22: fatal error: 9c/9.out.h: No such file or directory
compilation terminated.
mk: cc -c -m32 ...=C2=A0 : exit status=3Dexit(1)
mk: for j in ...=C2=A0 : exit status=3Dexit(1)

I can't find 9c under src/cmd folder. Any hints on how to get it
compiled?.

Cheers,

=C2=B9 https://bitbucket.org/plan9-from-bell= -labs/9-cc/overview

Ryan

[ERROR]: Your autotools build= scripts are 200 lines longer than your program. Something=E2=80=99s wrong.=

http://kirbyfan64.github.io/

=C2=A0

<= /div>

--001a1143e98873bafa0525609abd-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vasudev Kamath To: Ryan Gonzalez References: <877fl6ronj.fsf@rudra.copyninja.info> Date: Wed, 25 Nov 2015 22:54:34 +0530 In-Reply-To: (Ryan Gonzalez's message of "Wed, 25 Nov 2015 11:15:02 -0600") Message-ID: <8737vurnzh.fsf@rudra.copyninja.info> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 7769bb9a-ead9-11e9-9d60-3106f5b1d025 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...) Thanks Ryan, I will follow this. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <8737vurnzh.fsf@rudra.copyninja.info> References: <877fl6ronj.fsf@rudra.copyninja.info> <8737vurnzh.fsf@rudra.copyninja.info> Date: Thu, 26 Nov 2015 12:08:08 +0000 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a1130c8d091da610525706dbc Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 77be204a-ead9-11e9-9d60-3106f5b1d025 --001a1130c8d091da610525706dbc Content-Type: text/plain; charset=UTF-8 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 wrote: > 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...) > > Thanks Ryan, I will follow this. > > --001a1130c8d091da610525706dbc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

That copy of the compilers was changed quite a bit by some= one 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@copyni= nja.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.

--001a1130c8d091da610525706dbc-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <877fl6ronj.fsf@rudra.copyninja.info> References: <877fl6ronj.fsf@rudra.copyninja.info> Date: Thu, 26 Nov 2015 12:10:43 +0000 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=047d7b3a956cd6dc7205257076f9 Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 77c29076-ead9-11e9-9d60-3106f5b1d025 --047d7b3a956cd6dc7205257076f9 Content-Type: text/plain; charset=UTF-8 On 25 November 2015 at 17:10, Vasudev Kamath 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? --047d7b3a956cd6dc7205257076f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= 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,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0from 9obj.c:5= :
/usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and _SVI= D_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
=C2=A0# warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEF= AULT_SOURCE"

Of course, that particular on= e is just the latest crud from the constantly mutating gcc/clang environmen= ts.

Why "DEFAULT" if it's= not in fact the default?

--047d7b3a956cd6dc7205257076f9-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <877fl6ronj.fsf@rudra.copyninja.info> Date: Thu, 26 Nov 2015 13:18:39 +0100 Message-ID: From: David du Colombier <0intro@gmail.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 77c75a02-ead9-11e9-9d60-3106f5b1d025 >> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 User-Agent: K-9 Mail for Android In-Reply-To: References: <877fl6ronj.fsf@rudra.copyninja.info> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 From: Ryan Gonzalez Date: Thu, 26 Nov 2015 12:15:42 -0600 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>, Charles Forsyth Message-ID: Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 77ea6ede-ead9-11e9-9d60-3106f5b1d025 On November 26, 2015 6:10:43 AM CST, Charles Forsyth wrote: >On 25 November 2015 at 17:10, Vasudev Kamath >wrote: > >> In file included from >> >/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include/l= ib9.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 wan= t 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 yo= u use it like you're supposed to, you get errors. Then there's also crap like https://github.com/kirbyfan64/qlibc/commit/fb= 550e9f35a20492bcb6a767e9e3d33e30c00c59. It was a PR I opened. strptime wa= s undefined. Depending on the system, you need to define one of: - _USE_XOPEN - _XOPEN_SOURCE - _BSD_SOURCE and now: - _DEFAULT_SOURCE --=20 Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <877fl6ronj.fsf@rudra.copyninja.info>

Date: Thu, 26 Nov 2015 21:31:11 +0000 Message-ID: From: Charles Forsyth To: Ryan Gonzalez Content-Type: multipart/alternative; boundary=001a1142b97a39e20c0525784baf Cc: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 77ee6778-ead9-11e9-9d60-3106f5b1d025 --001a1142b97a39e20c0525784baf Content-Type: text/plain; charset=UTF-8 On 26 November 2015 at 18:15, Ryan Gonzalez 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? --001a1142b97a39e20c0525784baf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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

the only library on earth tha= t makes me want to bang my head on the floor.

There m= ust be others, surely. What about graphics libraries with APIs designed for= FORTRAN (no data structures)?

What about o= stensible crypto libraries that get their random numbers from Walmart?

--001a1142b97a39e20c0525784baf-- From mboxrd@z Thu Jan 1 00:00:00 1970 References: <877fl6ronj.fsf@rudra.copyninja.info>

From: Andrew Simmons Content-Type: text/plain; charset=us-ascii In-Reply-To: Message-Id: Date: Fri, 27 Nov 2015 08:40:32 +1100 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 787054ea-ead9-11e9-9d60-3106f5b1d025 > the only library on earth that makes me want to bang my head on the floor. > You need to get out more From mboxrd@z Thu Jan 1 00:00:00 1970 User-Agent: K-9 Mail for Android In-Reply-To: References: <877fl6ronj.fsf@rudra.copyninja.info>

MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 From: Ryan Gonzalez Date: Thu, 26 Nov 2015 15:49:20 -0600 To: Charles Forsyth Message-ID: Content-Transfer-Encoding: quoted-printable Cc: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 787570ec-ead9-11e9-9d60-3106f5b1d025 On November 26, 2015 3:31:11 PM CST, Charles Forsyth wrote: >On 26 November 2015 at 18:15, Ryan Gonzalez 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 use= rs need another dependency. Granted, there are other bad libraries or libraries with bad APIs (OpenSS= L, SDL [especially for playing short sounds!], PCRE, etc.). However, you = really don't *have* to use them. You can usually use RE2 or libregexp9 ov= er PCRE, SFML over SDL, and so forth. NOT WITH GLIBC!! *rant over now* --=20 Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <877fl6ronj.fsf@rudra.copyninja.info>

Date: Thu, 26 Nov 2015 21:51:37 +0000 Message-ID: From: Charles Forsyth To: Ryan Gonzalez Content-Type: multipart/alternative; boundary=001a114b350c45d77c05257894a0 Cc: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 787e0d42-ead9-11e9-9d60-3106f5b1d025 --001a114b350c45d77c05257894a0 Content-Type: text/plain; charset=UTF-8 On 26 November 2015 at 21:49, Ryan Gonzalez wrote: > All that is bad...but glibc is worse. The issue is that you kinda *have* > to use it, true, very true. --001a114b350c45d77c05257894a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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

--001a114b350c45d77c05257894a0-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <877fl6ronj.fsf@rudra.copyninja.info>

Date: Thu, 26 Nov 2015 21:56:44 +0000 Message-ID: From: Charles Forsyth To: Ryan Gonzalez Content-Type: multipart/alternative; boundary=001a11467fc69649a1052578a62d Cc: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 78830d9c-ead9-11e9-9d60-3106f5b1d025 --001a11467fc69649a1052578a62d Content-Type: text/plain; charset=UTF-8 On 26 November 2015 at 21:51, Charles Forsyth wrote: > On 26 November 2015 at 21:49, Ryan Gonzalez 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). --001a11467fc69649a1052578a62d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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

On 26 November 2015 at 21:49, Ryan Gonzale= z <rymg19@gmail.com> wrote:
All that is bad...but glibc is worse. The issue is that you kinda *have* t= o use it,

true, very true.

<= br>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?&qu= ot; into /dev/audio every so often, to save my voice

(cron would be good because it could switch to "blistering b= arnacles!" when children were present).

--001a11467fc69649a1052578a62d-- From mboxrd@z Thu Jan 1 00:00:00 1970 User-Agent: K-9 Mail for Android In-Reply-To: References: <877fl6ronj.fsf@rudra.copyninja.info>

MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 From: Ryan Gonzalez Date: Thu, 26 Nov 2015 16:02:33 -0600 To: Charles Forsyth Message-ID: <835ECE9E-472C-448D-8125-67BBACB09752@gmail.com> Content-Transfer-Encoding: quoted-printable Cc: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 788759c4-ead9-11e9-9d60-3106f5b1d025 On November 26, 2015 3:56:44 PM CST, Charles Forsyth wrote: >On 26 November 2015 at 21:51, Charles Forsyth > >wrote: > >> On 26 November 2015 at 21:49, Ryan Gonzalez 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 lin= king Clang, so I had to rebuild EVERYTHING. Stupid thing took about an ho= ur 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? --=20 Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <835ECE9E-472C-448D-8125-67BBACB09752@gmail.com> References: <877fl6ronj.fsf@rudra.copyninja.info>

<835ECE9E-472C-448D-8125-67BBACB09752@gmail.com> Date: Thu, 26 Nov 2015 22:08:10 +0000 Message-ID: From: Charles Forsyth To: Ryan Gonzalez Content-Type: multipart/alternative; boundary=001a114b2a5272cba6052578cfe0 Cc: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 788c7c42-ead9-11e9-9d60-3106f5b1d025 --001a114b2a5272cba6052578cfe0 Content-Type: text/plain; charset=UTF-8 On 26 November 2015 at 22:02, Ryan Gonzalez 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. --001a114b2a5272cba6052578cfe0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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

I remember the time I was tryi= ng to build LLVM+Clang on Windows in debug mode. Because...MinGW...I actual= ly surpassed the file size limit when linking Clang, so I had to rebuild EV= ERYTHING. Stupid thing took about an hour each time.

= Ah. Debug mode. It took me a while to suspect: I don't think you can bu= ild debug mode at all now in 32-bit mode.

E= ven with gold instead of gnu ld it needs more memory than they can represen= t in their arrangement of 32-bit user-mode address space.

--001a114b2a5272cba6052578cfe0-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <877fl6ronj.fsf@rudra.copyninja.info>

<835ECE9E-472C-448D-8125-67BBACB09752@gmail.com> Date: Thu, 26 Nov 2015 23:30:32 +0100 Message-ID: From: David du Colombier <0intro@gmail.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 78913c14-ead9-11e9-9d60-3106f5b1d025 >> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 User-Agent: K-9 Mail for Android In-Reply-To: References: <877fl6ronj.fsf@rudra.copyninja.info>

<835ECE9E-472C-448D-8125-67BBACB09752@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 From: Ryan Gonzalez Date: Thu, 26 Nov 2015 17:08:24 -0600 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>, David du Colombier <0intro@gmail.com> Message-ID: <69275011-637E-4D0C-9E17-2F0CF1B93503@gmail.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 7895d440-ead9-11e9-9d60-3106f5b1d025 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 t= hink it used that much. I only have 6 GB right now! --=20 Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <69275011-637E-4D0C-9E17-2F0CF1B93503@gmail.com> References: <877fl6ronj.fsf@rudra.copyninja.info>

<835ECE9E-472C-448D-8125-67BBACB09752@gmail.com> <69275011-637E-4D0C-9E17-2F0CF1B93503@gmail.com> Date: Thu, 26 Nov 2015 23:21:54 +0000 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a114b2a522fcafc052579d7a4 Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 78a6ae46-ead9-11e9-9d60-3106f5b1d025 --001a114b2a522fcafc052579d7a4 Content-Type: text/plain; charset=UTF-8 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. --001a114b2a522fcafc052579d7a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= 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 addre= ss space, I'll never know.

--001a114b2a522fcafc052579d7a4-- From mboxrd@z Thu Jan 1 00:00:00 1970 User-Agent: K-9 Mail for Android In-Reply-To: References: <877fl6ronj.fsf@rudra.copyninja.info>

<835ECE9E-472C-448D-8125-67BBACB09752@gmail.com> <69275011-637E-4D0C-9E17-2F0CF1B93503@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 From: Ryan Gonzalez Date: Thu, 26 Nov 2015 17:41:52 -0600 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>, Charles Forsyth Message-ID: Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 78b890c0-ead9-11e9-9d60-3106f5b1d025 On November 26, 2015 5:21:54 PM CST, Charles Forsyth wrote: >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 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 lo= ng those things took to compile... --=20 Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Brantley Coile Content-type: multipart/alternative; boundary="Apple-Mail=_F5A6E67D-0523-491A-85EE-538335420CA2" Message-id: <549869E7-C18F-43D2-A90A-12D7FF1120EE@me.com> MIME-version: 1.0 (Mac OS X Mail 9.0 $3094$) Date: Thu, 26 Nov 2015 19:02:13 -0500 References: <877fl6ronj.fsf@rudra.copyninja.info>

<835ECE9E-472C-448D-8125-67BBACB09752@gmail.com> <69275011-637E-4D0C-9E17-2F0CF1B93503@gmail.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 78c17140-ead9-11e9-9d60-3106f5b1d025 --Apple-Mail=_F5A6E67D-0523-491A-85EE-538335420CA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Clearly history is wrong. It would never be able to compile C in less = than 18MB (1/2 of clang=E2=80=99s text size). Therefor Unix didn=E2=80=99t= really happen. It=E2=80=99s 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=E2=80=99t for their great = mistake=E2=80=94the 3B20. Results: no more =E2=80=9COne system; it = works." > On Nov 26, 2015, at 6:21 PM, Charles Forsyth = wrote: >=20 >=20 > 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! >=20 > 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. --Apple-Mail=_F5A6E67D-0523-491A-85EE-538335420CA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Clearly history is wrong. It would never be able to compile C = in less than 18MB (1/2 of clang=E2=80=99s text size). Therefor Unix = didn=E2=80=99t really happen. It=E2=80=99s 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=E2=80=99t= for their great mistake=E2=80=94the 3B20. Results: no more =E2=80=9C= 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> 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.

= --Apple-Mail=_F5A6E67D-0523-491A-85EE-538335420CA2-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <877fl6ronj.fsf@rudra.copyninja.info>

<835ECE9E-472C-448D-8125-67BBACB09752@gmail.com> <69275011-637E-4D0C-9E17-2F0CF1B93503@gmail.com> Date: Fri, 27 Nov 2015 09:13:20 +0100 Message-ID: From: Giacomo Tesio To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a1130d134b8c7920525814311 Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 78c6456c-ead9-11e9-9d60-3106f5b1d025 --001a1130d134b8c7920525814311 Content-Type: text/plain; charset=UTF-8 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 --001a1130d134b8c7920525814311 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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

On 26 Nov= ember 2015 at 23:08, Ryan Gonzalez <rymg19@gmail.com> wrote:<= br>
Holy crap, that's crazy. I built it i= n 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 huma= n beings have ever had to produce.
The orig= inal 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 s= pace, I'll never know.

I= 9;d love to read more about this, Charles. :-)

I know nothing about compilers, but actually gcc an= d clang dimension and complexity is astonishing.

I've always thought that this is due to their desire to compi= le many different language optimized for many different OS and architecture= s on many different OS and architecture.

Alternative compilers, like tcc, onl= y 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

--001a1130d134b8c7920525814311-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnold@skeeve.com Message-Id: <201511270856.tAR8uBol016809@freefriends.org> Date: Fri, 27 Nov 2015 01:56:11 -0700 To: 9fans@9fans.net References: <877fl6ronj.fsf@rudra.copyninja.info>

<835ECE9E-472C-448D-8125-67BBACB09752@gmail.com> <69275011-637E-4D0C-9E17-2F0CF1B93503@gmail.com>

In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 78cc46e2-ead9-11e9-9d60-3106f5b1d025 > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 27 Nov 2015 13:05:56 +0100 From: Steffen Nurpmeso To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20151127120556.BySSXW-9_%sdaoden@yandex.com> References: <877fl6ronj.fsf@rudra.copyninja.info>

<835ECE9E-472C-448D-8125-67BBACB09752@gmail.com> <69275011-637E-4D0C-9E17-2F0CF1B93503@gmail.com> In-Reply-To: User-Agent: s-nail v14.8.5-176-g4c6d78d Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 78d13a4e-ead9-11e9-9d60-3106f5b1d025 |How they ever got it going on a system with 64Kbytes of address space\ |, I'll never know. Yeah! --steffen From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net Date: Fri, 27 Nov 2015 14:32:34 +0200 From: lucio@proxima.alt.za In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 78d5b51a-ead9-11e9-9d60-3106f5b1d025 > What about ostensible crypto libraries that get their random numbers from > Walmart? Do they get those over the counter? Lucio. From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 27 Nov 2015 13:42:51 +0100 From: tlaronde@polynum.com To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20151127124251.GA625@polynum.com> References:

<835ECE9E-472C-448D-8125-67BBACB09752@gmail.com> <69275011-637E-4D0C-9E17-2F0CF1B93503@gmail.com>

MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 78da0dea-ead9-11e9-9d60-3106f5b1d025 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 27 Nov 2015 14:33:12 +0100 From: Steffen Nurpmeso To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20151127133312.4nVVd3cC7%sdaoden@yandex.com> References: <877fl6ronj.fsf@rudra.copyninja.info>

<835ECE9E-472C-448D-8125-67BBACB09752@gmail.com> <69275011-637E-4D0C-9E17-2F0CF1B93503@gmail.com>

<201511270856.tAR8uBol016809@freefriends.org> In-Reply-To: <201511270856.tAR8uBol016809@freefriends.org> User-Agent: s-nail v14.8.5-176-g4c6d78d MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 78df1dbc-ead9-11e9-9d60-3106f5b1d025 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=3Dclang devel >/dev/null 2>&1 0m55.37s real 0m29.44s user 0m27.24s system ?0[sdaoden@wales ]$ time make CC=3Dgcc devel >/dev/null 2>&1 0m50.04s real 0m26.13s user 0m24.92s system ?2[sdaoden@wales ]$ time make CC=3Dtcc 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=3D"pcc" /usr/include/stdc-predef.h:59: warning: __STDC_ISO_10646__ redefined (pre= viously 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/sda= oden/usr/include -I/usr/local/include -I/usr/include -L/home/sdaoden/u= sr/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=C3=B6rg 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 From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <20151127124251.GA625@polynum.com> References:

<835ECE9E-472C-448D-8125-67BBACB09752@gmail.com> <69275011-637E-4D0C-9E17-2F0CF1B93503@gmail.com>

<20151127124251.GA625@polynum.com> Date: Fri, 27 Nov 2015 15:07:30 +0100 Message-ID: From: Giacomo Tesio To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=047d7b873dd24ace3c05258636fa Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 78e40688-ead9-11e9-9d60-3106f5b1d025 --047d7b873dd24ace3c05258636fa Content-Type: text/plain; charset=UTF-8 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 --047d7b873dd24ace3c05258636fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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

On Fri, Nov 27, 2015 at 09:13:20= AM +0100, Giacomo Tesio wrote:
>
> I know nothing about compilers, but actually gcc and clang dimension a= nd
> 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 t= hat makes it somehow hard to implement.

For e= xample I've met a few times weird implementations of libraries and fram= eworks dictated by broken standards: once they are in, they can never be re= moved due to backward compatibility. I thought that Charles (that also impl= emented the Limbo compiler) might have referenced these kind of issues in h= is pun.

Giacomo

--047d7b873dd24ace3c05258636fa-- From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 27 Nov 2015 15:34:58 +0100 From: tlaronde@polynum.com To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20151127143458.GA692@polynum.com> References:

<835ECE9E-472C-448D-8125-67BBACB09752@gmail.com> <69275011-637E-4D0C-9E17-2F0CF1B93503@gmail.com>

<20151127124251.GA625@polynum.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 78e8911c-ead9-11e9-9d60-3106f5b1d025 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vasudev Kamath To: Ryan Gonzalez References: <877fl6ronj.fsf@rudra.copyninja.info> Date: Fri, 27 Nov 2015 22:20:20 +0530 In-Reply-To: (Ryan Gonzalez's message of "Wed, 25 Nov 2015 11:15:02 -0600") Message-ID: <877fl3bd4j.fsf@rudra.copyninja.info> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable Cc: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 78ecd448-ead9-11e9-9d60-3106f5b1d025 Hi Ryan, Ryan Gonzalez writes: > See > https://bitbucket.org/plan9-from-bell-labs/9-cc/issues/1/problems-buildin= g-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/Lin= ux/386/include -I/home/vasudev/Documents/C_programming/compilers/9-cc/inclu= de -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_SOU= RCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp] # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURC= E" ^ 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 =A1=AE(=A1=AF before =A1=AEsizeof=A1=AF extern int isnan(double); ^ mk: cc -c -m32 ... : exit status=3Dexit(1) mk: for j in ... : exit status=3Dexit(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).=20 I'm unsure what the error is indicating. Any idea on how to proceed further= ?. From mboxrd@z Thu Jan 1 00:00:00 1970 User-Agent: K-9 Mail for Android In-Reply-To: <877fl3bd4j.fsf@rudra.copyninja.info> References: <877fl6ronj.fsf@rudra.copyninja.info> <877fl3bd4j.fsf@rudra.copyninja.info> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----0IEQFZABDORERSKCKG13IOAOJTBZHP" From: Ryan Gonzalez Date: Fri, 27 Nov 2015 10:59:41 -0600 To: Vasudev Kamath Message-ID: Content-Transfer-Encoding: 7bit Cc: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 78f10bc6-ead9-11e9-9d60-3106f5b1d025 ------0IEQFZABDORERSKCKG13IOAOJTBZHP Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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-buildi= ng-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/libma= th.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/l= ib9.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/l= ib9.h:19:0, > from blas.c:1: >/home/vasudev/Documents/C_programming/compilers/9-cc/include/mathi.h:59:= 12: >error: expected identifier or =E2=80=98(=E2=80=99 before =E2=80=98sizeof= =E2=80=99 > extern int isnan(double); > ^ >mk: cc -c -m32 ... : exit status=3Dexit(1) >mk: for j in ... : exit status=3Dexit(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).=20 > >I'm unsure what the error is indicating. Any idea on how to proceed >further?. --=20 Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity. ------0IEQFZABDORERSKCKG13IOAOJTBZHP Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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-f=
rom-bell-labs/9-cc/issues/1/problems-building-under-x64-linux
 f=
or 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<=
br />different error after that.

(cd src/libmath; mk  all)
/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libm=
ath.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_38=
6 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_SOU=
RCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
 #=
 warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURC=
E"
   ^
In file included from /home/vasudev/Documents/C_program=
ming/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 =E2=80=98(=E2=80=99 =
before =E2=80=98sizeof=E2=80=99
 extern int isnan(double);
    =
        ^
mk: cc -c -m32 ...  : exit status=3Dexit(1)
mk: for j=
 in ...  : exit status=3Dexit(1)

I tried to find sizeof in mat=
hi.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 er=
ror is indicating. Any idea on how to proceed further?.

--
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity. ------0IEQFZABDORERSKCKG13IOAOJTBZHP-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vasudev Kamath To: Ryan Gonzalez References: <877fl6ronj.fsf@rudra.copyninja.info> <877fl3bd4j.fsf@rudra.copyninja.info> Date: Fri, 27 Nov 2015 22:46:02 +0530 In-Reply-To: (Ryan Gonzalez's message of "Fri, 27 Nov 2015 10:59:41 -0600") Message-ID: <8737vrbbxp.fsf@rudra.copyninja.info> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable Cc: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 78f58994-ead9-11e9-9d60-3106f5b1d025 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_SOU= RCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp] # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURC= E" ^ 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 =A1=AE(=A1=AF before = =A1=AEsizeof=A1=AF int isnan(double x) ^ mk: cc -c -m32 ... : exit status=3Dexit(1) mk: for j in ... : exit status=3Dexit(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 =A1=AEmyctime=A1=AF: Posix.c:9:9: warning: implicit declaration of function =A1=AEctime=A1=AF [-= Wimplicit-function-declaration] return ctime(&t); ^ Posix.c:9:9: warning: return makes pointer from integer without a cast [-Wi= nt-conversion] cc -m32 -o o.out ar.o Posix.o /home/vasudev/Documents/C_programming/compil= ers/9-cc/Linux/386/lib/libmach.a /home/vasudev/Documents/C_programming/comp= ilers/9-cc/Linux/386/lib/libbio.a /home/vasudev/Documents/C_programming/com= pilers/9-cc/Linux/386/lib/lib9.a=20 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 `mkdtem= p' /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=3Dexit(1) mk: for j in ... : exit status=3Dexit(1) mk: for j in ... : exit status=3Dexit(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=20 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, From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 27 Nov 2015 18:11:14 +0000 From: trebol To: 9fans@9fans.net Message-ID: <56589cc2.LKJWOzoKCAdGPijl%trebol@india.com> References: <877fl6ronj.fsf@rudra.copyninja.info> In-Reply-To: User-Agent: Heirloom mailx 12.5 6/20/10 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 78fa023a-ead9-11e9-9d60-3106f5b1d025 Ryan Gonzalez wrote: > See > https://bitbucket.org/plan9-from-bell-labs/9-cc/issues/1/problems-build= ing-under-x64-linux > for some tips on fixing various errors you may encounter, including thi= s > 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 =C2=B9. Its giving me following err= or > > > > cc -c -m32 -g -O > > -I/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/incl= ude > > -I/home/vasudev/Documents/C_programming/compilers/9-cc/include -DLINU= X_386 > > -I../cmd/ 9obj.c > > In file included from > > /home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/includ= e/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=3Dexit(1) > > mk: for j in ... : exit status=3Dexit(1) > > > > I can't find 9c under src/cmd folder. Any hints on how to get it > > compiled?. > > > > Cheers, > > > > =C2=B9 https://bitbucket.org/plan9-from-bell-labs/9-cc/overview > > > > > > > --=20 > Ryan > [ERROR]: Your autotools build scripts are 200 lines longer than your > program. Something=E2=80=99s wrong. > http://kirbyfan64.github.io/ h+ h+ From mboxrd@z Thu Jan 1 00:00:00 1970 User-Agent: K-9 Mail for Android In-Reply-To: <8737vrbbxp.fsf@rudra.copyninja.info> References: <877fl6ronj.fsf@rudra.copyninja.info> <877fl3bd4j.fsf@rudra.copyninja.info> <8737vrbbxp.fsf@rudra.copyninja.info> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 From: Ryan Gonzalez Date: Fri, 27 Nov 2015 12:24:26 -0600 To: Vasudev Kamath Message-ID: <9F888B46-B9A9-4DEA-AD47-631DC3D6B9C5@gmail.com> Content-Transfer-Encoding: quoted-printable Cc: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 78fe5196-ead9-11e9-9d60-3106f5b1d025 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/l= ib9.h:19:0, > from fdlibm/fdlibm.h:2, > from fdlibm/s_isnan.c:20: >fdlibm/s_isnan.c:22:6: error: expected identifier or =E2=80=98(=E2=80=99= before >=E2=80=98sizeof=E2=80=99 > int isnan(double x) > ^ >mk: cc -c -m32 ... : exit status=3Dexit(1) >mk: for j in ... : exit status=3Dexit(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 =E2=80=98myctime=E2=80=99: >Posix.c:9:9: warning: implicit declaration of function =E2=80=98ctime=E2= =80=99 >[-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/libma= ch.a >/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libbi= o.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:11= 20: >warning: the use of `mktemp' is dangerous, better use `mkstemp' or >`mkdtemp' >/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libma= ch.a(obj.o):(.rodata+0x198): >undefined reference to `_is9' >/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libma= ch.a(obj.o):(.rodata+0x19c): >undefined reference to `_read9' >collect2: error: ld returned 1 exit status >mk: cc -m32 ... : exit status=3Dexit(1) >mk: for j in ... : exit status=3Dexit(1) >mk: for j in ... : exit status=3Dexit(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=20 >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, --=20 Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity. From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Fri, 27 Nov 2015 16:55:04 -0800 To: 9fans@9fans.net Message-ID: In-Reply-To: <20151127133312.4nVVd3cC7%sdaoden@yandex.com> References: <877fl6ronj.fsf@rudra.copyninja.info>

<835ECE9E-472C-448D-8125-67BBACB09752@gmail.com> <20151127133312.4nVVd3cC7%sdaoden@yandex.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 7912dee0-ead9-11e9-9d60-3106f5b1d025 > memory bug in J=C3=B6rg 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. =20 https://en.wikipedia.org/wiki/Cdrtools#Device_naming "all the world's a vax^h^h^hscsi" - erik From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Fri, 27 Nov 2015 17:01:22 -0800 To: 9fans@9fans.net Message-ID: <391e673be47c95750d6acda7d3ffaa20@bwc> In-Reply-To: References:

<835ECE9E-472C-448D-8125-67BBACB09752@gmail.com> <69275011-637E-4D0C-9E17-2F0CF1B93503@gmail.com>

MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 791803ac-ead9-11e9-9d60-3106f5b1d025 > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 Date: Sat, 28 Nov 2015 17:42:25 +1100 Message-ID: From: da Tyga To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a114713466eb2e80525941cf1 Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 793fc0a4-ead9-11e9-9d60-3106f5b1d025 --001a114713466eb2e80525941cf1 Content-Type: text/plain; charset=UTF-8 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 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 > > --001a114713466eb2e80525941cf1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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 languag= e was a higher than assembler language for the PDP-11 (at least that's = how I became acquainted with it back in 1976).=C2=A0 Most of us, in those d= ays, welcomed something that was more high level than macro-assembler and y= et amenable to writing operating systems and utilities (unlike FORTRAN, ALG= OL and COBOL of that era).=C2=A0 Many of us would use the -s switch to chec= k 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 compi= ler produced relatively predictable code.=C2=A0 The undefined behaviours in= many cases meant that at least on the PDP-11 we would know what to expect.= =C2=A0 It was only once code was ported to other systems that these assumpt= ions started getting sorely tested.

Fast forward t= o present time, we have a bloated C standard and even more bloated C++ stan= dards.=C2=A0 The target instruction sets are rich with lots of special case= instructions; out of sequence execution; multi-level caches add further co= nstraints.=C2=A0 So today's compilers need to analyse complex source co= de to run with good performance on extremely complex targets.=C2=A0 We shou= ldn't forget that in the case of the x86 family the compilers need to o= ptimise for an ever evolving instruction set and retain backward compatibil= ity across earlier variants.

On 28 November 2015 at 12:01, erik quanstro= m <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 librarie= s and
> frameworks dictated by broken standards: once they are in, they can ne= ver
> be removed due to backward compatibility. I thought that Charles (that= also
> implemented the Limbo compiler) might have referenced these kind of is= sues
> in his pun.

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

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

- erik

--001a114713466eb2e80525941cf1-- From mboxrd@z Thu Jan 1 00:00:00 1970 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 9.1 $3096.5$) From: Brantley Coile In-reply-to: Date: Sat, 28 Nov 2015 02:40:31 -0500 Content-transfer-encoding: quoted-printable Message-id: <0962EE36-1765-440C-816F-90DEF0A5720D@me.com> References: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 794868e4-ead9-11e9-9d60-3106f5b1d025 Great point. And you actually don=E2=80=99t 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=E2=80=99m 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=E2=80=99s = 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=E2=80=99s = 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=E2=80=99t 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.=20 Brantley > On Nov 28, 2015, at 1:42 AM, da Tyga wrote: >=20 > I have been following this discussion about the C compiler and can no = longer stop myself from making a (snarky?) comment. >=20 > 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. >=20 > 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. >=20 > 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. >=20 >=20 > 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. >=20 > 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. >=20 > (i have to remind myself this from time to time.) >=20 > - erik >=20 >=20 From mboxrd@z Thu Jan 1 00:00:00 1970 User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 From: Ryan Gonzalez Date: Sat, 28 Nov 2015 14:13:07 -0600 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>, da Tyga Message-ID: <66535EFF-39F3-4BEE-9913-507DF4E660A7@gmail.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 794f44e8-ead9-11e9-9d60-3106f5b1d025 On November 28, 2015 12:42:25 AM CST, da Tyga wrot= e: >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 bo= ard 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.=20 >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 compatibilit= y 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 disappe= aring, just moving around? I prefer languages that prefer correctness to perfect, cross-platform API= s 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 >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 >> >> --=20 Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity. CURRENTLY LISTENING TO: The Key We've Lost (Xenoblade Chronicles X) From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Sorace Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: Date: Sat, 28 Nov 2015 15:31:21 -0500 References: <0962EE36-1765-440C-816F-90DEF0A5720D@me.com> In-Reply-To: <0962EE36-1765-440C-816F-90DEF0A5720D@me.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 7955c840-ead9-11e9-9d60-3106f5b1d025 Brantley wrote: > One could argue that the Plan 9 C compiler lacks the modern optimizations t= hat the other compilers have. This would be true. But I would argue that alm= ost all of those optimizations are either not needed... Note the "almost all" in there. It's important not to get dogmatic about suc= h 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, c= loser that known alternatives, and errs on the safer side. Likely there are o= ptimizations or features in newer chipsets that would be worth supporting, b= ut even so: we've got a long way to go before hitting gcc/clang levels.= From mboxrd@z Thu Jan 1 00:00:00 1970 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 9.1 $3096.5$) From: Brantley Coile In-reply-to: Date: Sat, 28 Nov 2015 18:33:08 -0500 Content-transfer-encoding: quoted-printable Message-id: <4BA8023A-95EF-4B39-85E2-444DD2766C61@me.com> References: <0962EE36-1765-440C-816F-90DEF0A5720D@me.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 795c6c9a-ead9-11e9-9d60-3106f5b1d025 Not dogmatic. Just 38 years and I still believe small is beautify.=20 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 wrote: >=20 > Brantley wrote: >=20 >> 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... >=20 > 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net Date: Sun, 29 Nov 2015 07:57:58 +0200 From: lucio@proxima.alt.za In-Reply-To: <66535EFF-39F3-4BEE-9913-507DF4E660A7@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 796515fc-ead9-11e9-9d60-3106f5b1d025 > 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <96df9ced9a56f62ae0d46b0692093cc6@proxima.alt.za> To: 9fans@9fans.net Date: Sun, 29 Nov 2015 08:12:41 +0200 From: lucio@proxima.alt.za In-Reply-To: <4BA8023A-95EF-4B39-85E2-444DD2766C61@me.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 797899b0-ead9-11e9-9d60-3106f5b1d025 > 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vasudev Kamath To: Ryan Gonzalez References: <877fl6ronj.fsf@rudra.copyninja.info> <877fl3bd4j.fsf@rudra.copyninja.info> <8737vrbbxp.fsf@rudra.copyninja.info> <9F888B46-B9A9-4DEA-AD47-631DC3D6B9C5@gmail.com> Date: Sun, 29 Nov 2015 15:11:45 +0530 In-Reply-To: <9F888B46-B9A9-4DEA-AD47-631DC3D6B9C5@gmail.com> (Ryan Gonzalez's message of "Fri, 27 Nov 2015 12:24:26 -0600") Message-ID: <87k2p1w3ae.fsf@rudra.copyninja.info> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 797ca64a-ead9-11e9-9d60-3106f5b1d025 Ryan Gonzalez 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?. From mboxrd@z Thu Jan 1 00:00:00 1970 User-Agent: K-9 Mail for Android In-Reply-To: <87k2p1w3ae.fsf@rudra.copyninja.info> References: <877fl6ronj.fsf@rudra.copyninja.info> <877fl3bd4j.fsf@rudra.copyninja.info> <8737vrbbxp.fsf@rudra.copyninja.info> <9F888B46-B9A9-4DEA-AD47-631DC3D6B9C5@gmail.com> <87k2p1w3ae.fsf@rudra.copyninja.info> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 From: Ryan Gonzalez Date: Sun, 29 Nov 2015 08:38:44 -0600 To: Vasudev Kamath Message-ID: <40956B2C-0BF4-4787-AA5C-69D76694D608@gmail.com> Content-Transfer-Encoding: quoted-printable Cc: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 7981249a-ead9-11e9-9d60-3106f5b1d025 On November 29, 2015 3:41:45 AM CST, Vasudev Kamath wrote: >Ryan Gonzalez 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/libbi= o.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/libbi= o.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:3= 20: >undefined reference to `sdiv2' >/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:3= 23: >undefined reference to `smod2' >/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:4= 25: >undefined reference to `sdivgen' >/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:4= 27: >undefined reference to `udivgen' >/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:6= 32: >undefined reference to `sdiv2' >/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:6= 35: >undefined reference to `smod2' >/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:7= 59: >undefined reference to `sdivgen' >/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:7= 62: >undefined reference to `udivgen' >collect2: error: ld returned 1 exit status >mk: cc -m32 ... : exit status=3Dexit(1) >mk: for j in ... : exit status=3Dexit(1) >mk: for j in ... : exit status=3Dexit(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 com= ment out the relevant lines in src/cmd/mkfile. --=20 Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity. From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sun, 29 Nov 2015 17:17:51 +0100 From: tlaronde@polynum.com To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20151129161751.GC73@polynum.com> References: <66535EFF-39F3-4BEE-9913-507DF4E660A7@gmail.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 798c8c4a-ead9-11e9-9d60-3106f5b1d025 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 http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 30 Nov 2015 16:46:53 +0100 From: Steffen Nurpmeso To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20151130154653.EzTpc33li%sdaoden@yandex.com> References: <877fl6ronj.fsf@rudra.copyninja.info>

<835ECE9E-472C-448D-8125-67BBACB09752@gmail.com> <20151127133312.4nVVd3cC7%sdaoden@yandex.com> In-Reply-To: User-Agent: s-nail v14.8.5-187-g651a656 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 7990b3c4-ead9-11e9-9d60-3106f5b1d025 erik quanstrom wrote: |> memory bug in J=C3=B6rg 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. =20 | 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