Re: AC_TRY_RUN vs crosscompile

On 14.04.2017 18:20, Uli Schlachter wrote:

<snip>

>> As the test is likely to fail on many automated build machineries (and
>> indeed could give false results - the same arch doesn't necessarily
>> mean it will be working on the target),
> 
> I think "Linux" means that it will still work at runtime, but I don't
> know the details. Why would this be arch specific?

Target specific (depending on the actual target kernel configuration).
In desktop world, there might be no one running a kernel w/ sysvipc,
but in embedded world, it's far from being unusual. (maybe, some day,
some desktop distros might begin phasing out sysvipc, too.)

So, I'd suggest:
a) find a solution that works well in both cases
b) provide a build-time flag instead of AC_TRY_RUN

>> wouldn't it be better to have an explicit configure flag for that ?
> 
> No one would use such a configure flag. Configure's job is to figure out
> details of the target system and this is just such a detail.

But in that case, it can't do it reliably.

In that case we've got an optional feature that's only available on a
limited set of targets. For reliable packaging, you want to control
what features are built in and certainly not having a build script
trying to be more clever than the systems integrator - especially in
embedded world.

This especially means that a package should never enable/disable certain
features just because some library or header *seems* to exist on the
build host. In general one should never assume that build host and
target have much in common.

Autoconf has a long and horrible history of taking weird assumptions,
which already caused us (especially in embedded world) uncountable
hours of wasted lifetime. AC_TRY_RUN() is a major troublemakers.

> Which check exactly? The one which checks if shmat() after deletion
> still works? That's sounds too much like "We only care about Linux" for
> my taste. 

No, thats not my intention. I just have really bad feeling about that
automatic here that can easily create a hidden dependency.

I have no idea on which systems this hack actually work - on my box
the symbol was set (at least on non-cross), but I wouldn't count on
that working forever. On BSD it seems to be a runtime parameter.

Actually, I wonder that it works at all, smells like a bug (I'd never
expect that a deleted segment is remains accessible in the namespace at
all - which is the opposite of the usual filesystem semantics).
Assuming a later kernel fix that (maybe that could even be considered a
security hole), applications built on the older one suddenly behave
strangely on the new one. And the system integrators (eg. distro folks)
will have a hard time finding out whats going on here.

So, at least there should be an runtime check on first use.
(I'd guess runtime kernel upgrades w/o restarting applications is
pretty rare :o).

> Also, this check works around a race condition and debugging
> race conditions is nasty. 

What race condition exactly ? The only posting I've found so far talked
about the false assumption that this linux-specific behaviour works
everywhere and introduced exactly the AC_TRY_RUN() call we're now
talking about.

>> OTOH, we should also think of making that an explicit build-time check,
>> as certain target systems (especially embedded) might not have it
>> enabled in the kernel (while still having the headers).
> 
> "It" is shared memory, right?

It's about whether the currently running kernel has deferred deletion
enabled right now or not.


--mtx

-- 
cairo mailing list
[email protected]
https://lists.cairographics.org/mailman/listinfo/cairo