You don't have the x86_64 -devel package installed.

That is, you're not really supposed to have the i686 -devel package installed on x86_64, at least not without the corresponding x86_64 -devel package. 

Run
# rpm -e openblas-devel.i686
and then run
# dnf -y install openblas-devel

and it should work.

Have you actually tried your own advice? The bottom line is, it is a conflict to install both -devel - some of us wants to do both 32-bit and 64-bit developments.

(In reply to Hin-Tak Leung from comment #3)
> Have you actually tried your own advice? 

Did *you* even try it?

> The bottom line is, it is a conflict to install both -devel - some of us wants
> to do both 32-bit and 64-bit developments.

And the way to do it is to use mock (or other chroot) to build the 32-bit package in a true 32-bit environment. Any other way is not supported in Fedora.

This is not a bug with openblas, it's a general feature in Fedora and rpm.

I'll go back on my earlier statement: it's just not possible to have both i686 and x86_64 -devel packages installed simultaneously.

Multiarched packages are for *compatibility* only, not development.

I have regularly had both -devel.i686 and -devel.x86_64 on. Many package maintainers try to cope. See for example, freetype-devel's

i686:
/usr/include/freetype2/freetype/config/ftconfig-32.h
/usr/include/freetype2/freetype/config/ftconfig.h

x86_64:
/usr/include/freetype2/freetype/config/ftconfig-64.h
/usr/include/freetype2/freetype/config/ftconfig.h

Here is freetype's wrapper "ftconfig.h" around the two differing headers:

===
$ more ftconfig.h 
#ifndef __FTCONFIG_H__MULTILIB
#define __FTCONFIG_H__MULTILIB

#include <bits/wordsize.h>

#if __WORDSIZE == 32
# include "ftconfig-32.h"
#elif __WORDSIZE == 64
# include "ftconfig-64.h"
#else
# error "unexpected value for __WORDSIZE macro"
#endif

#endif 
===

and here is the part in freetype.spec which separates the two differing headers:

===
%install
...
# fix multilib issues
%define wordsize %{__isa_bits}

mv $RPM_BUILD_ROOT%{_includedir}/freetype2/freetype/config/ftconfig.h \
   $RPM_BUILD_ROOT%{_includedir}/freetype2/freetype/config/ftconfig-%{wordsize}.h
install -p -m 644 %{SOURCE3} $RPM_BUILD_ROOT%{_includedir}/freetype2/freetype/config/ftconfig.h
===

I think openblas can do the same thing.

I tried this, but part of openblas detects what kind of host it is being compiled on; so it either needs to be modified, or two sets of rpms need to be compiled on two sets of hosts.

Still a problem in fedora 27.

Feel free to file a feature request / patches upstream. If they agree to change the header files, then the Fedora packages will be updated.

Again, multiarch is only for binary compability in Fedora. If you want to develop 32-bit applications, use a chroot or mock.

Created attachment 1375070 [details]
small patch to the fedora spec file to implement multiarch support

This patch is to be applied to git://pkgs.fedoraproject.org/openblas.git . It has been tested to do the job.

Upstream *DOES* support building 32-bit libraries on 64-bit host. You do "make ... BINARY=32 ..." to achieve that. I don't know if it is clearly documented, but I found this when I finally get my hand dirty to look at the spec file and running "rpmbuild --rebuild --target=i686 ..." and worked out why multarch isn't working since the v0.2.19 -> v0.2.20 upgrade.

So this small patch adds the "... BINARY=32 ..." part, as well as the include header idea borrowed from multiarch freetype mentioned earlier.

Already tested and works correctly on f27. (It is a bit crazy that 64-bit took ~11 GB of disk space to build, and the 32-bit a bit less...).

Please apply the patch , rebuild and push an update.

Quite a few packages have the same arrangement (this include freetype, and python, and of course my custom-built openblas). 

$ find /usr/include/ -type f -name '*-32.h'
/usr/include/python2.7/pyconfig-32.h
/usr/include/python3.6m/pyconfig-32.h
/usr/include/openblas/openblas_config-32.h
/usr/include/jconfig-32.h
/usr/include/gnu/lib-names-32.h
/usr/include/gnu/stubs-32.h
/usr/include/freetype2/freetype/config/ftconfig-32.h

$ find /usr/include/ -type f -name '*-64.h'
/usr/include/python2.7/pyconfig-64.h
/usr/include/H5pubconf-64.h
/usr/include/python3.6m/pyconfig-64.h
/usr/include/QtCore/qconfig-64.h
/usr/include/openblas/openblas_config-64.h
/usr/include/GraphicsMagick/magick/magick_types-64.h
/usr/include/gnu/lib-names-64.h
/usr/include/gnu/stubs-64.h
/usr/include/jconfig-64.h
/usr/include/libart-2.0/libart_lgpl/art_config-64.h
/usr/include/ImageMagick-6/magick/version-64.h
/usr/include/ImageMagick-6/magick/magick-config-64.h
/usr/include/ImageMagick-6/magick/magick-baseconfig-64.h
/usr/include/orbit-2.0/orbit/orbit-config-64.h
/usr/include/freetype2/freetype/config/ftconfig-64.h
/usr/include/qt5/QtCore/qconfig-64.h
/usr/include/qt5/QtQml/5.9.2/QtQml/private/qv4global_p-64.h
/usr/include/event2/event-config-64.h
/usr/include/tiffconf-64.h
/usr/include/clang/Config/config-64.h

(In reply to Hin-Tak Leung from comment #10)
> Created attachment 1375070 [details]
> small patch to the fedora spec file to implement multiarch support
> 
> This patch is to be applied to git://pkgs.fedoraproject.org/openblas.git .
> It has been tested to do the job.

Go ahead and submit it upstream. I'm *NOT* going to fork the Fedora packages from what upstream offers. That would directly conflict with the Fedora packaging guidelines.

> Upstream *DOES* support building 32-bit libraries on 64-bit host. You do
> "make ... BINARY=32 ..." to achieve that. I don't know if it is clearly
> documented, but I found this when I finally get my hand dirty to look at the
> spec file and running "rpmbuild --rebuild --target=i686 ..." and worked out
> why multarch isn't working since the v0.2.19 -> v0.2.20 upgrade.

That is clearly beside the point. Nobody wants to build a 32-bit library on a 64-bit host. We build 64-bit libraries on 64-bit hosts, and 32-bit libraries on 32-bit hosts. Multiarch allows you to keep using 32-bit applications on a 64-bit host; the packages are pulled from the 32-bit build. BUILDING 32-BIT APPLICATIONS ON 64-BIT FEDORA IS NOT SUPPORTED IN ANY WAY IN FEDORA! Like I've said a dozen times before, the way to do this is to use chroot or mock, WHICH IS DESIGNED FOR THIS PURPOSE.