Re: [Tack-devel] all of Ack-5.5 under Linux

[David G. <dg...@co...>]

Re build tools: unfortunately the ACK is a really complex thing to build
with lots of code generation and dependencies between components. The old
build system didn't even try to track any of this stuff and relied on a
hard-coded build order and single-threaded builds; but it was impossibly
slow and impossible to understand, and didn't really achieve correct builds
anyway. It was completely unable to be modified to support parallel builds.
Hence the succession of new build systems.

I'm actually on the verge of giving up on make completely; it's essentially
unable to do correct builds no matter how hard you try (try to build
something which produces multiple output files some time!).

Re mach vs plat: mach contains CPU architectures, plat contains machine
targets. Each plat depends on a single mach, but each mach may be used by
any number of plats. (Although not all the platform-specific stuff has been
moved out of mach yet.)

Re libc problems: I don't know whether this is present in 5.5, but I
wouldn't be surprised if it did. The problem is that the libc depends on
many, many symbols which don't have prototypes by just importing them with
extern. It's particularly keen on calling leading-underscore versions of
system calls, so the implementation of system() actually calls _execl() to
do the work. If the syscall library doesn't implement _execl() and only
implements execl() then everything will appear to work until you try to
actually *use* system(). I think the only complete syscall libraries are
minix and em. (If you look in
https://github.com/davidgiven/ack/blob/release-5-6/mach/minix/libsys you'll
see that each symbol is defined twice.) (Also, it took me ages to find the
em syscall library because it only exists in K&R C; it's in
https://github.com/davidgiven/ack/tree/release-5-6/lang/cem/libcc/mon and
the last change was in 1993. I think the phrase 'creakingly old' applies
here.)

This only became apparent with em because ass doesn't work like led and
tries to resolve all symbols when it links, rather than just the used ones.


On Wed, 20 Jun 2018 at 18:24 <u-...@ae...> wrote:

> Hello David,
>
> On Wed, Jun 20, 2018 at 04:53:26PM +0200, David Given wrote:
> > Very belatedly, I got em binaries working with the 6.0 stream, and
> there's
> > a basic em22 platform. It's all in head of git and it's built
> automatically
> > so you can just check out, build, install, and do:
> >
> > $ /usr/local/lib/ack/int /usr/local/share/ack/examples/mandelbrot_c.em22
>
> Congratulations!
>
> I appreciate your work on Ack and understand that the new build tools
> make your development easier or feasible at all.
>
> Unfortunately, the new Ack-6* build stuff did not really fit in my
> development model. I tried it earlier, before porting ackpack.
>
> One property is that the new build tools are more "complex" than the
> target, they can not be built/maintained without yet other tools, much
> more complicated than ack.
>
> Ack used to be dependent only on the V7-era stuff and I try to keep its
> maintenance in that complexity domain. (According to the commits, up to
> version 4 Ack was apparently small enough to be hosted even on pdp-11.)
>
> The other thing is the semantics of different directories.
> This is not exactly consistent in the original Ack (at least where the
> stuff is being installed, objects of different classes/namespaces are
> often mixed in common directories) but I find it even harder to follow
> in the new one. What is the semantics of "mach" vs "plat"?
>
> > ...and it should work. However, I discovered huge problems with the libc
> in
> > the process and it needs refactoring --- turns out that it largely only
> > works by accident at the moment, so I'm taking some time out to try and
> fix
> > that before adding em24 and em44.
>
> Is it because of some changes in libc or is the problem present in 5.5?
>
> I can confirm that the interpreter indeed needs some fixing.
>
> Tested a program which worked reliably both
>  natively, built with ackpack for linux on ia32, and
>  under apout, when built with ack-5.5 for v7unix on pdp.
>
> It worked on small data also under em22/int but crashed at some point
> given a larger dataset (not affecting the amount of the needed memory
> but among others the number of de/allocations).
>
> Regards,
> Rune
>
>