Re: [PATCH] Improve compatibility with other platforms

[David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>]

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

On Wed, Jan 03, 2018 at 08:03:27AM -0600, Kyle Evans wrote:
> [Resending with a proper mail client, because my initial response
> didn't go to the lists]
> 
> On Tue, Jan 2, 2018 at 9:55 PM, David Gibson
> <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote:
> > Ok sounds good.  I had a look at the tests using -ldl and it looks
> > like they couldn't easily be adapted to avoid it.  However, I'd be ok
> > with logic to skip those tests if libdl isn't available, if you want
> > to broaden support to older releases.
> 
> The hard part is that libdl doesn't need to be available. With FreeBSD
> (and generally, all BSDs if I understood right), the symbols expected
> of libdl are available in libc.
> 
> If I have my terminology right, our libdl is in fact just a filter on
> libc to isolate these symbols/functions for all of the software that
> expected libdl. We'd spent enough time patching out -ldl that it
> seemed a good idea, but these binaries *do* compile without it.

Ah, right.

I that case, I think the approach to take is to make a new LIBDL make
variable with the "-ldl" in it, so that it can be overridden on *BSD
to be empty.

> 
> > At the moment dtc seems to be just teetering on the edge of being
> > complex enough to need some sort of configuration system (whether it
> > be hand-rolled scripts, autoconf or whatever).  So far I've been
> > avoiding adding such a thing, because that introduces a bunch of
> > problems of its own: hand rolled scripts are a pain to maintain,
> > autoconf is ugly as sin, pretty much anything else is nonstandard and
> > liable to introduce a bunch of extra dependencies.  But, I might have
> > to bite the bullet at some point.
> 
> Ugh, build systems. =P

I know, right.

> > Great.  MacOS support is interesting in particular, because unlike
> > FreeBSD, I can set up a Travis build to test it there, which means I'm
> > much more likely to catch regressions.  In fact, looks like I have a
> > stale branch here that added an OSX build to the travis.yml - I think
> > some of the errors you've found and didn't have time to debug them
> > (debugging when your only host is indirect through Travis is pretty
> > painful).
> 
> It'd be interesting to see those results as of recent. Their userland
> should be similar enough in the ways you care about for the results to
> likely be relevant to us, I would think.

I rebased and tried it again:
    https://travis-ci.org/dgibson/dtc/jobs/324587391

Looks like we're getting problems with the interesting way I (ab)use
the assembler to produce a test blob.  I've hit a number of problems
with that over time, so I'd really like to replace it with something
else.  Unfortunately, I haven't yet thought of a replacement that
wouldn't be a pain in the arse.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]