* [kyukhin/gomp4-offload] DESTDIR issues
@ 2014-09-17 13:31 Jakub Jelinek
2014-09-17 14:04 ` Paolo Bonzini
0 siblings, 1 reply; 5+ messages in thread
From: Jakub Jelinek @ 2014-09-17 13:31 UTC (permalink / raw)
To: Ilya Verbin, Kirill Yukhin, Bernd Schmidt, Alexandre Oliva,
Paolo Bonzini, DJ Delorie
Cc: gcc-patches
Hi!
It seems building of the host compiler requires the offloading compiler
to be installed directly in the prefix, which is something really
undesirable e.g. for distro builds where things are installed with
non-empty $(DESTDIR).
Right now it seems that for building all that is needed is
main_target_image.h.
Either we can do something like the following patch, i.e. look
at -I$(DESTDIR)/$(target_dir)/include first and fall back to
-I$(target_dir)/include, which fixed the build for me, but unfortunately
it violates GNU conventions:
https://www.gnu.org/prep/standards/html_node/DESTDIR.html
"DESTDIR should be supported only in the install* and uninstall* targets, as
those are the only targets where it is useful."
while this patch uses it during build.
Another option would be to have two different modes of building
--enable-offload-targets= compilers, one where you really have
all the offloading target compilers installed (with empty DESTDIR, or
initially with non-empty DESTDIR, then somehow (package manager, etc.)
copied to the right prefix), and another one where for each offloading
target you'd additionally specify the build directory containing
non-installed tree (dunno, could be e.g.
--enable-offload-targets=x86_64-intelmic-linux-gnu=/some/path,ptx-none=/some/other/path
format?) and let the host compiler's build look into the other build trees
for what it needs during building and/or testing (for building
main_target_image.h should be supposedly all that is needed, for testing
perhaps more).
Thoughts on this?
2014-09-17 Jakub Jelinek <jakub@redhat.com>
* plugin/Makefile.am (libgomp_plugin_mic_la_CPPFLAGS): Use
$(DESTDIR)$(target_dir)/include path before
trying $(target_dir)/include.
* plugin/Makefile.in: Regenerated.
--- liboffloadmic/plugin/Makefile.am 2014-09-16 18:16:17.961415565 +0200
+++ liboffloadmic/plugin/Makefile.am 2014-09-17 14:40:26.990566860 +0200
@@ -47,7 +47,7 @@ target_dir = $(libdir)/gcc/$(accel_targe
if PLUGIN_HOST
toolexeclib_LTLIBRARIES = libgomp-plugin-mic.la
libgomp_plugin_mic_la_SOURCES = libgomp-plugin-mic.cpp
- libgomp_plugin_mic_la_CPPFLAGS = $(CPPFLAGS) -DLINUX -DCOI_LIBRARY_VERSION=2 -DMYO_SUPPORT -DOFFLOAD_DEBUG=1 -DSEP_SUPPORT -DTIMING_SUPPORT -DHOST_LIBRARY=1 -DMIC_LIB_PATH=\"$(target_dir)\" -I$(coi_inc_dir) -I$(myo_inc_dir) -I$(liboffload_src_dir) -I$(libgomp_dir) -I$(target_dir)/include
+ libgomp_plugin_mic_la_CPPFLAGS = $(CPPFLAGS) -DLINUX -DCOI_LIBRARY_VERSION=2 -DMYO_SUPPORT -DOFFLOAD_DEBUG=1 -DSEP_SUPPORT -DTIMING_SUPPORT -DHOST_LIBRARY=1 -DMIC_LIB_PATH=\"$(target_dir)\" -I$(coi_inc_dir) -I$(myo_inc_dir) -I$(liboffload_src_dir) -I$(libgomp_dir) -I$(DESTDIR)$(target_dir)/include -I$(target_dir)/include
libgomp_plugin_mic_la_LDFLAGS = -L$(liboffload_dir)/.libs -loffloadmic -version-info 1:0:0
else # PLUGIN_TARGET
plugin_includedir = $(libsubincludedir)
--- liboffloadmic/plugin/Makefile.in 2014-09-16 18:16:17.961415565 +0200
+++ liboffloadmic/plugin/Makefile.in 2014-09-17 14:54:50.555096069 +0200
@@ -277,7 +277,7 @@ libsubincludedir = $(libdir)/gcc/$(targe
target_dir = $(libdir)/gcc/$(accel_target)/$(gcc_version)
@PLUGIN_HOST_TRUE@toolexeclib_LTLIBRARIES = libgomp-plugin-mic.la
@PLUGIN_HOST_TRUE@libgomp_plugin_mic_la_SOURCES = libgomp-plugin-mic.cpp
-@PLUGIN_HOST_TRUE@libgomp_plugin_mic_la_CPPFLAGS = $(CPPFLAGS) -DLINUX -DCOI_LIBRARY_VERSION=2 -DMYO_SUPPORT -DOFFLOAD_DEBUG=1 -DSEP_SUPPORT -DTIMING_SUPPORT -DHOST_LIBRARY=1 -DMIC_LIB_PATH=\"$(target_dir)\" -I$(coi_inc_dir) -I$(myo_inc_dir) -I$(liboffload_src_dir) -I$(libgomp_dir) -I$(target_dir)/include
+@PLUGIN_HOST_TRUE@libgomp_plugin_mic_la_CPPFLAGS = $(CPPFLAGS) -DLINUX -DCOI_LIBRARY_VERSION=2 -DMYO_SUPPORT -DOFFLOAD_DEBUG=1 -DSEP_SUPPORT -DTIMING_SUPPORT -DHOST_LIBRARY=1 -DMIC_LIB_PATH=\"$(target_dir)\" -I$(coi_inc_dir) -I$(myo_inc_dir) -I$(liboffload_src_dir) -I$(libgomp_dir) -I$(DESTDIR)$(target_dir)/include -I$(target_dir)/include
@PLUGIN_HOST_TRUE@libgomp_plugin_mic_la_LDFLAGS = -L$(liboffload_dir)/.libs -loffloadmic -version-info 1:0:0
@PLUGIN_HOST_FALSE@plugin_includedir = $(libsubincludedir)
@PLUGIN_HOST_FALSE@plugin_include_HEADERS = main_target_image.h
Jakub
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [kyukhin/gomp4-offload] DESTDIR issues
2014-09-17 13:31 [kyukhin/gomp4-offload] DESTDIR issues Jakub Jelinek
@ 2014-09-17 14:04 ` Paolo Bonzini
2014-09-17 14:10 ` Jakub Jelinek
0 siblings, 1 reply; 5+ messages in thread
From: Paolo Bonzini @ 2014-09-17 14:04 UTC (permalink / raw)
To: Jakub Jelinek, Ilya Verbin, Kirill Yukhin, Bernd Schmidt,
Alexandre Oliva, DJ Delorie
Cc: gcc-patches
Il 17/09/2014 15:31, Jakub Jelinek ha scritto:
> It seems building of the host compiler requires the offloading compiler
> to be installed directly in the prefix, which is something really
> undesirable e.g. for distro builds where things are installed with
> non-empty $(DESTDIR).
Is the offloading compiler built together with GCC or previously? If
the latter, what's the difference between the offloading compiler and
say gmp? Setting the LD_LIBRARY_PATH would be the responsibility of
whoever builds GCC; it would be the same here for the COMPILER_PATH.
> Either we can do something like the following patch, i.e. look
> at -I$(DESTDIR)/$(target_dir)/include first and fall back to
> -I$(target_dir)/include, which fixed the build for me, but unfortunately
> it violates GNU conventions:
> https://www.gnu.org/prep/standards/html_node/DESTDIR.html
> "DESTDIR should be supported only in the install* and uninstall* targets, as
> those are the only targets where it is useful."
> while this patch uses it during build.
I agree with the coding standards. The right way to do it could be a
configure option, if it's really not possible to leave it to whoever
builds GCC.
Paolo
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [kyukhin/gomp4-offload] DESTDIR issues
2014-09-17 14:04 ` Paolo Bonzini
@ 2014-09-17 14:10 ` Jakub Jelinek
2014-09-17 16:00 ` Paolo Bonzini
0 siblings, 1 reply; 5+ messages in thread
From: Jakub Jelinek @ 2014-09-17 14:10 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Ilya Verbin, Kirill Yukhin, Bernd Schmidt, Alexandre Oliva,
DJ Delorie, gcc-patches
On Wed, Sep 17, 2014 at 04:04:25PM +0200, Paolo Bonzini wrote:
> Il 17/09/2014 15:31, Jakub Jelinek ha scritto:
> > It seems building of the host compiler requires the offloading compiler
> > to be installed directly in the prefix, which is something really
> > undesirable e.g. for distro builds where things are installed with
> > non-empty $(DESTDIR).
>
> Is the offloading compiler built together with GCC or previously? If
> the latter, what's the difference between the offloading compiler and
> say gmp? Setting the LD_LIBRARY_PATH would be the responsibility of
> whoever builds GCC; it would be the same here for the COMPILER_PATH.
Right now previously, but (usually) from the very same sources, so I think
it will be usually (but not always?) desirable to build them together, perhaps
not in a single toplevel configure and single toplevel make.
Jakub
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [kyukhin/gomp4-offload] DESTDIR issues
2014-09-17 14:10 ` Jakub Jelinek
@ 2014-09-17 16:00 ` Paolo Bonzini
2014-09-18 10:59 ` Ilya Verbin
0 siblings, 1 reply; 5+ messages in thread
From: Paolo Bonzini @ 2014-09-17 16:00 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Ilya Verbin, Kirill Yukhin, Bernd Schmidt, Alexandre Oliva,
DJ Delorie, gcc-patches
Il 17/09/2014 16:09, Jakub Jelinek ha scritto:
>> > Is the offloading compiler built together with GCC or previously? If
>> > the latter, what's the difference between the offloading compiler and
>> > say gmp? Setting the LD_LIBRARY_PATH would be the responsibility of
>> > whoever builds GCC; it would be the same here for the COMPILER_PATH.
> Right now previously, but (usually) from the very same sources, so I think
> it will be usually (but not always?) desirable to build them together, perhaps
> not in a single toplevel configure and single toplevel make.
If it's from the same sources, that probably rules out a single toplevel
configure/make. Is it a problem if a newer GCC is compiled with older
headers from the offloading compiler?
In any case, I would go with a configure option.
Paolo
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [kyukhin/gomp4-offload] DESTDIR issues
2014-09-17 16:00 ` Paolo Bonzini
@ 2014-09-18 10:59 ` Ilya Verbin
0 siblings, 0 replies; 5+ messages in thread
From: Ilya Verbin @ 2014-09-18 10:59 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Paolo Bonzini, Kirill Yukhin, Bernd Schmidt, Alexandre Oliva,
DJ Delorie, gcc-patches
Ok, the approach with additional --enable-offload-targets arguments seems to be
more appropriate, so I will fix offloading infrastructure pach #1.
Thanks,
-- Ilya
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-09-18 10:59 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-17 13:31 [kyukhin/gomp4-offload] DESTDIR issues Jakub Jelinek
2014-09-17 14:04 ` Paolo Bonzini
2014-09-17 14:10 ` Jakub Jelinek
2014-09-17 16:00 ` Paolo Bonzini
2014-09-18 10:59 ` Ilya Verbin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).