[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: multilib (was Re: gcc-4.6: please add m68k support)



Thorsten,

has hwcap evolved to the point where it does no longer require directory lookups of O(n!)? The thread you gave seems to die down at around that point in the discussion. Has a dependency model for hwcaps been implemented?

How many capabilities would we need to map existing hardware?

Cheers,

Michael


Thorsten Glaser wrote:
Dixi quod?

(2) Although I wonder why we build the multilib stuff at all, you
 told me to not disable it, but I can?t find the 68040/68060
 optimised target libraries in the .deb packages? so they just
 take up compile time at the moment.

Actually, why don?t we install the 68040 and 68060 optimised
versions and use hwcaps¹ so the programmes can decide at run
time whether to use them?

Assuming m68k and coldfile have ?the same ABI?² at least for
binaries, we could even go one step further: install optimised
versions for 68020, 68040, 68060, coldfire into hwcaps direc-
tories and either (if possible) a common (working on both)
version in the normal lib directory or (this would require
all libraries to be compiled twice though) no common version
for libraries at all, just for executables. (The coldfire part
might be aided by multiarch (on the OS level, like it?s being
introduced currently) if we were to make a fake Debian/coldfire
port that required the normal m68k port as baseline, like it?s
being done with ? don?t remember ? s390x or ppc64. Or multiarch
could do all of the coldfire half, but that doesn?t invalidate
the hwcaps idea, does it?)

(1) Almost³ undocumented, but the thread at ? makes for a start:
  http://lists.debian.org/debian-devel/2005/01/msg00856.html

(2) quoted from https://wiki.debian.org/ArmHardFloatPort#ld.so_hwcaps

(3) duckduckgoing for both hwcaps and hwcap shows some results, though

bye,
//mirabilos


Reply to: