Hi!
I'm atttaching three files with (abridged) listings of how/what we're
currently installing for a 32-/64-bit x86_64 GNU/Linux target compiler,
and nvptx-none as well as x86_64-intelmicemul-linux-gnu offloading
compilers. For offloading compilation to work (that is, for the target
compiler to locate the offloading compilers), these three trees (nice
tongue twister!) currently have to be installed into the same prefix.
As you can see with the following commands, there are clashes in the
installed files, for example for the target vs. nvptx-none offloading
compiler:
$ comm -12 install install-nvptx-none
share/info/[...]
share/locale/[...]
share/man/[...]
That's probably harmless (but should be fixed anyways), but for target
vs. x86_64-intelmicemul-linux-gnu offloading compiler, it's worse:
$ comm -12 install install-x86_64-intelmicemul-linux-gnu
include/c++/[...]
lib32/[snipped; expected to be similar to lib64]
lib64/libasan.a
lib64/libasan.la
lib64/libasan.so.3.0.0
lib64/libasan_preinit.o
lib64/libatomic.a
lib64/libatomic.la
lib64/libatomic.so.1.2.0
lib64/libcilkrts.a
lib64/libcilkrts.la
lib64/libcilkrts.so.5.0.0
lib64/libcilkrts.spec
lib64/libgcc_s.so
lib64/libgcc_s.so.1
lib64/libgfortran.a
lib64/libgfortran.la
lib64/libgfortran.so.3.0.0
lib64/libgfortran.spec
lib64/libgomp.a
lib64/libgomp.la
lib64/libgomp.so.1.0.0
lib64/libgomp.spec
lib64/libitm.a
lib64/libitm.la
lib64/libitm.so.1.0.0
lib64/libitm.spec
lib64/liblsan.a
lib64/liblsan.la
lib64/liblsan.so.0.0.0
lib64/libmpx.a
lib64/libmpx.la
lib64/libmpx.so.2.0.0
lib64/libmpx.spec
lib64/libquadmath.a
lib64/libquadmath.la
lib64/libquadmath.so.0.0.0
lib64/libsanitizer.spec
lib64/libssp.a
lib64/libssp.la
lib64/libssp.so.0.0.0
lib64/libssp_nonshared.a
lib64/libssp_nonshared.la
lib64/libstdc++.a
lib64/libstdc++.la
lib64/libstdc++.so.6.0.22
lib64/libstdc++.so.6.0.22-gdb.py
lib64/libstdc++fs.a
lib64/libstdc++fs.la
lib64/libsupc++.a
lib64/libsupc++.la
lib64/libtsan.a
lib64/libtsan.la
lib64/libtsan.so.0.0.0
lib64/libubsan.a
lib64/libubsan.la
lib64/libubsan.so.0.0.0
lib64/libvtv.a
lib64/libvtv.la
lib64/libvtv.so.0.0.0
share/gcc-6.0.0/python/libstdcxx/__init__.py
share/gcc-6.0.0/python/libstdcxx/v6/__init__.py
share/gcc-6.0.0/python/libstdcxx/v6/printers.py
share/gcc-6.0.0/python/libstdcxx/v6/xmethods.py
share/info/[...]
share/locale/[...]
share/man/[...]
Again, the clashes in include/ and share/ files are probably harmless
(but should be fixed anyways).
But I'm actually confused as to seeing libgomp.so in that list -- given
the conflict of which compiler installations' libgomp.so "wins", I wonder
how it can be working that some of the functions in there are supposed to
behave differently on/are compiled differently for target vs. offloading
target? Or did I do/understand something wrong? For a lot of other
libraries it's probably not "severe", given that they will basically be
the same whether compiled for x86_64-pc-linux-gnu or
x86_64-intelmicemul-linux-gnu (plus slightly different configure
options). But anyway: this issue looks like it might cause confusion,
and definitely should be fixed?
And then we also got clashes between nvptx-none and
x86_64-intelmicemul-linux-gnu offloading compilers:
$ comm -12 install-nvptx-none install-x86_64-intelmicemul-linux-gnu
lib/libcc1.la
lib/libcc1.so.0.0.0
share/info/[...]
share/locale/[...]
share/man/[...]
(I'm now confused why the target compiler is installating libcc1.* into
lib64/ but the offloading compilers into lib/.) Anyway: another source
of conflicts.
$ grep libcc1\\. *
install:lib64/libcc1.la
install:lib64/libcc1.so.0.0.0
install-nvptx-none:lib/libcc1.la
install-nvptx-none:lib/libcc1.so.0.0.0
install-x86_64-intelmicemul-linux-gnu:lib/libcc1.la
install-x86_64-intelmicemul-linux-gnu:lib/libcc1.so.0.0.0
I wonder if it wouldn't actually be safer to re-configure things so that
the offloading toolchains are always completely installed into their own
subdirectory. That would avoid all such file installation conflicts.
For instance, I think a "normal" user has no business in directly running
the offloading toolchains' binaries; I consider these offloading
toolchains an "implementation detail" to enable the target compiler's
-foffload=[...], basically.
One problem is, though, if offloading compilation/linking involves shared
libraries (which it doesn't for nvptx-none but does for
x86_64-intelmicemul-linux-gnu, as far as I know). If it is expected that
these shared libraries are found in the usual paths searched by ld.so, I
wonder how that is meant to be working currently, at all? For example,
given the libgomp.so issue raised above. Maybe I'm not understanding the
x86_64
