On 06/07/2016 11:03 PM, Jan Kratochvil wrote:
On Tue, 07 Jun 2016 17:30:58 +0200, Pavel Raiskup wrote:
In database packages we have that multilib hack for a very long time,
mostly C&P'ed among various spec files.
#if defined(__x86_64__)
#include "${filename}${opt_additional_suffix}_x86_64.h"
#elif defined(__i386__)
#include "${filename}${opt_additional_suffix}_i386.h"
#elif defined(__ppc64__) || defined(__powerpc64__)
#include "${filename}${opt_additional_suffix}_ppc64.h"
[...]
Is this really the preferred way?
IMHO, no - It's just *one* possible *hack* to address such portability
issues among several.
IMO, the preferred way would be to actually convert such headers
arch-independent.
For example in GDB I have just used a type
which has proper size across all the used archs:
http://pkgs.fedoraproject.org/cgit/rpms/gdb.git/plain/gdb-jit-reader-multilib.patch
(*)
That's what I call the "cascade of defines" approach. Another legitimate
approach.
(*) Why not <stdint.h> - it would be probably rejected upstream as too "new";
although this patch also was not approved in the end.
Full ACK. That's what I usually prefer, because it addresses the actual
causes behind such issues and headers "arch-independent".
IMO, the "too new" actually is red herring. stdint.h/inttypes.h are
around for decades. IIRC, in POSIX since 1999, with many OS-vendors
having shipped implementations for much longer. So not using stdint.h
only serves to cater really old toolchains, which definitely isn't of
any importance on Linux.
Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
