Re: [ft-devel] No support for side-by-side installation of x86-64and i386

[Antoine Leca]

[Resend since I did not see the original one. Sorry if it duplicates. ]

Hallo Werner,

On Thursday, December 8th, 2005 14:37Z, Werner LEMBERG wrote:

>> As far as I've seen, most system headers exist in one copy only, and
>> use preprocessor macros to detect which the architecture is; usually
>> via <sys/isa_defs.h>, which defines macros for most of the
>> interesting cases: [...]
>
> This is the solution I like most.  I don't know how difficult it is to
> achieve that...

Well, if you are reading Ilya's original message, it is about what is
currently done for Freetype (no surprise to me):

Ilya wrote on Tuesday, December 6th, 17:02Z:
] Currently, freetype i386 and x86-64 collide in the following files:
] /usr/bin/freetype-config
] /usr/include/freetype2/freetype/config/ftconfig.h

that is, they collide ONLY on the two "built" configuration files which
describe the "target" architecture; in fact, it boils down that the
target
architecture "bi-arch x86-32 + x86-64" has not been forcasted (in
freetype-config.in and ftconfig.h.in).
This is only what we need (but that's not easy).


This is why I asked Ilya to provide his idea of "his environment" which
would lead to the automatic selection of the correct subtarget/more/arch
(to get back to the analogy with Solaris headers, the selecting macros
in <sys/isa_defs.h>, if I got it correctly : sorry I do not use Solaris
either).

Then, we can probably build the picture of the two files to create for a
GNU/Linux x86-64 target, allowing selection of x86-32 as well : if I am
not mistaken it is the most sensible option.
Then backport it into the .in templates (this is NOT the easy part).


Please, do NOT make the mistake to assume that target=*-x86_64 is
sufficient: while nowadays every targetting x86-64 also supports
x86-32 (i386 if you prefer), there are no architectural reason for this
to hold forever, particularly in embeeded; and also, and perhaps more
importantly, the trick to have /lib for x86-32 and /lib64 for x86-64 is
NOT universal (e.g. on Windows, it is /lib, or more exactly /Program
Files or system32, for x86-64, and something along the lines of /lib32
(like "/Program Files (x86)") for x86-32).

Also as said earlier, we probably should not assume everybody has GLib
or pkg-config installed when targetting x86-64 (furthermore it may lead
to version dependencies).


Antoine