Re: Hacks for multilib unclean C headers

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

 



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?  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
	(*)
And thus GDB does have now one .h file with the same content on all archs.

/usr/include/* files should remain readable, they should not be an obfuscated
intermediate compilation form.

I find the separate .h files for each arch only as a last resort hack.
And thus I find it not preferred to make a last resort hack a part of the
standard packaging macros.


Jan Kratochvil


(*) Why not <stdint.h> - it would be probably rejected upstream as too "new";
although this patch also was not approved in the end.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux