+1 for 1) option. Python would benefit from this, too, as it has some platform specific headers.

Also, just, recently, new multilib-safe build of libffi broke Python build as reported in [1]. Although this seems to be a cornercase, the 1) option is a clear systematic solution that would solve this sort of issues once and for all.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=979696

+1 for 1) In mysql/mariadb, we are forced to use some ugly hacks (similar to ad 2)), but 1) seems cleaner:

http://pkgs.fedoraproject.org/cgit/mariadb.git/tree/mariadb.spec#n402

I agree the hack used in mariadb (and lot of other packages) is ugly.

If the gcc new include path could be an option, but I don't think it is the right solution.

We should prefer to rely in pkg-config (or foo_config) output.

Ex:
{{{
$ pkg-config --cflags libzip
-I/usr/lib64/libzip/include
}}}

So, you will notice that a lot of upstream have already fix this problem using headers in %{_libdir} (even if this is probably not FHS compliant).

For mariadb
{{{
$ mysql_config --include
-I/usr/include/mysql
}}}

Consumer of my_config.h (it's only an example) will not include <mysql/my_config.h> but only <my_config.h>, so having an new include search path which not solve the initial problem.

So, in this case, if an arch specific include is wanted, this should be reported by mysql_config output (and very probably be discussed / accepted by upstream)

If someone could propose a draft that would make it quicker for FPC to take a look at this. Otherwise an FPC member will have to make the time to review the prior art and condense it into a guideline draft.

Replying to [comment:6 toshio]:

If someone could propose a draft

I am not sure if we are at the stage, where we should propose any drafts. I'd like to know, what is FPC's opinion on this matter. Which of the above points would be supported by FPC. For example Remi seems to be against this idea entirely ...

Since you are speaking about draft, then I assume that you speak about 2nd point, but that makes me wonder again, are you considering it as a temporary solution until 1) or as a "permanent" one? If you might support 1nd proposal, would you mind to comment into referred bug?

After you clarify this questions, I'll come up with some draft.

Thanks.

Replying to [comment:7 vondruch]:

Replying to [comment:6 toshio]:

If someone could propose a draft

I am not sure if we are at the stage, where we should propose any drafts. I'd like to know, what is FPC's opinion on this matter. Which of the above points would be supported by FPC. For example Remi seems to be against this idea entirely ...

I think the most obvious draft is (as usual) specify a best practise way of doing what everyone does, so either what python/etc. does with header-<arch-word-size>.h and then create a wrapper which uses WORDSIZE to include the right file, or the SDL approach if that has a good way to pick arch from CPP.

Having a special GCC include dir. which is arch. specific and always there seems ok to me, at first thought ... but that doesn't exist yet, right? I'm also not sure where it should go, /usr/x86_64-redhat-linux/include seems not generic enough so packages would have to guess (or run some command) to find out where to put their files ... which seems bad.

Forcing pkg-config, or something similar, to add random extra -I flags seems like the worst idea to me.

But I only speak for myself.

Replying to [comment:8 james]:

I think the most obvious draft is (as usual) specify a best practise way of doing what everyone does, so either what python/etc. does with header-<arch-word-size>.h and then create a wrapper which uses WORDSIZE to include the right file, or the SDL approach if that has a good way to pick arch from CPP.

Word size is not enough. Endian is needed as well. But for the moment, I'll try to draft something along these lines:

http://pkgs.fedoraproject.org/cgit/ruby.git/commit/?id=1e68c10ca8fdeef75236b24640285f3e68f723a6

Having a special GCC include dir. which is arch. specific and always there seems ok to me, at first thought ... but that doesn't exist yet, right? I'm also not sure where it should go, /usr/x86_64-redhat-linux/include seems not generic enough so packages would have to guess (or run some command) to find out where to put their files ... which seems bad.

There would be probably macro for this.

vondruch, did anything ever happen here? You indicated that you were going to try and draft something, but that was a long time ago.

No response; closing. Please feel free to reopen if you have more information to add.

Here is the draft-change for existing MultilibTricks [1] draft :), is that what is needed?
Can I change that page directly?

Text used previously:

'''myautoconf.h files with a size in them'''

...skip...

If what is needed are integer of a length independent from the platform,
integers like int32_t from inttypes.h can be used.

Fixed text proposed:

'''Architecture dependent header files'''

Some packages install header files (typically named *config.h, automatically 
generated by build system) which will have something in them relating to the
byte size of some (typically integer or poitner) types at compile time.

Those files then may differ on multilib-counterpart architectures.  This
kind of API specification is bad in most cases, however, since an API should
be completely platform independent.

The best believed solution to this integer length incompatibility is to have
it fixed once and forever upstream -- for example use integer types of a
length independent from the platform (integers like int32_t from inttypes.h
can be used).  This is however hard to achieve in many cases.

The one possible way to get around this problem is (considering that the
architecture-dependent file is named 'config.h' and we build on x86_64
platform), to move the config.h into config_x86_64.h and as a substitution
for the original config.h install architecture-independent stub header file
like:
    {{{
    ...
    #if defined(__x86_64__)
    #include "config_x86_64.h"
    #elif defined(__i386__)
    #include "config_i386.h"
    ...
    }}}

There is convenient RPM macro '%multilib_fix_c_header' in redhat-rpm-config
package that allows you to automatize this, typically you can just use
    {{{
    %install
    ...
    make install DESTDIR=%{buildroot}
    ...
    %multilib_fix_c_header --file %{_includedir}/package/config.h
    ...
    }}}

[1] https://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks

Related bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1286193

Ah, I've chosen the approach 2) here because I missed this ticket before, but it is just matter of implementation. Once gcc bug ​https://bugzilla.redhat.com/show_bug.cgi?id=979696 is fixed, we can fix the '%multilib_fix_c_header' macro.

What I personally dislike on 1) is that it just complicates reading of header files -- when I see code like '#include <somewhere/something.h>', I usually want to look in /usr/include/somewhere/something.h file (there is 'gcc -I', but still). Not having the "api" file there makes the 2) approach slightly better than 1) to me.

Can you please not reopen 18 month closed tickets? Open a new one and you can link to this, thanks.

Replying to [comment:18 james]:

Can you please not reopen 18 month closed tickets? Open a new one and you can link to this, thanks.

It might be nice to provide some reasoning for this, since I think that reopening tickets makes perfect sense, since this was never really resolved and people who were in the discussion might still be interested in the discussion. We might of course disagree.

It just helps a lot in dealing with them, as we don't have a significant amount of text from 18 months ago to read through and try to remember what applies/why/etc. Obviously you can add a comment to old tickets saying "I still think this needs resolving, see the new ticket I opened #123blah", and you can point back to the old ticket in the new one (hopefully with some kind of summary of what happened and was discussed).

I'm not ready for ticket asking for ratification of MultilibTricks draft yet, so let's continue
with work on that draft first.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/F6YVSCNNFFFNEOQ4TN6BJOPJZ2KMPEOJ/

FWIW, I edited the draft ​https://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks as promised, so that it now suggests 'BuildRequires: multilib-rpm-config'.