Re: [HACKERS] configure on linux

>
> On 4 Feb 1998, Goran Thyni wrote:
>
> > >include/config.h is unchanged
> > >linking ./backend/port/tas/linux.s to backend/port/tas.s
> > >configure: error: ./backend/port/tas/linux.s: File not found
> >
> > It does compile OK, since this file is not used anyway.
> > But it would be confusing to Joe User if it is still there
> > in the release. :-)
>
> With the 1998-02-04 snapshot, I see the same problem that Gran sees
> on NetBSD/sparc, where it looks for a tas/bsd.s to link to. It's
> building here now, after I put an empty bsd.s where it wanted it and
> reran configure -- I assume, from Gran's experience, that it's OK.
>
> Actually, it would be good to get all tas() assembly implementations
> out of include/storage/s_lock.h and into genuine .s files like this.
> With the current way of doing it, the assembly routine has to be
> "static", because s_lock.h is included several places, which is a bit
> silly, but a worse consequence is that GCC will inline the assembly
> code at optimization levels above 2, thus breaking it.. Is this what
> you're doing, and the reason why the above problem occurred?

Don't break my optimizations. The locking stuff is in *.h files for a
reason. They get called thousands of times, and inlining this code has
produced a good speedup and they aren't that big.

The only case where the inlining of the lock code does not work in on
alpha/linux, and I believe it is because the assembler does not support
local labels. If this is your problem, there is an s_lock.c file for
such cases, but the general case of using s_lock.h and inlining the lock
calls is a good strategy.

>
> By the way, I'm running Monday's snapshot on NetBSD/vax now. Small
> changes only: a couple of changed ifdefs, a couple of Makefile mods
> and a tas() implementation in four lines of assembly. There are no
> shared libraries, and no dynamic loading of object modules, but apart
> from that, it works fine -- regression tests pass and fail in the same
> pattern as on NetBSD/sparc, with the addition of dynload failures.
>
> Is it too late to get the VAX stuff into 6.3? It's really not much,
> and it would be kinda fun... :-)

I certainly think we want those changes. 6.3 beta is the place we
expect to be making platform-specific patches.

--
Bruce Momjian
maillist(at)candle(dot)pha(dot)pa(dot)us