GNOME Bugzilla – Bug 779812
Build fails
Last modified: 2017-07-31 10:54:55 UTC
I see this when building with jhbuild from git master now: CXX smooth_refresh.o CXX disks.o CXX selinux.o CXX systemd.o CXX cgroups.o CXX gsm_gnomesu.o CXX gsm_gksu.o CXX gsm_pkexec.o CXX lsof.o CXX prefsdialog.o CXX application.o make[3]: *** No rule to make target 'legacy/gsm-resources.o', needed by 'gnome-system-monitor'. Stop. make[3]: *** Waiting for unfinished jobs.... CXX main.o make[3]: Leaving directory '/home/kmaraas/.cache/jhbuild/build/gnome-system-monitor/src' Makefile:641: recipe for target 'all-recursive' failed make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory '/home/kmaraas/.cache/jhbuild/build/gnome-system-monitor/src' Makefile:599: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/kmaraas/.cache/jhbuild/build/gnome-system-monitor' Makefile:464: recipe for target 'all' failed make: *** [all] Error 2 *** Error during phase build of gnome-system-monitor: ########## Error running make -j 5 *** [1/1]
It works when building outside of jhbuild though.
Have you tried cleaning the jhbuild cache for system-monitor ? This looks like a duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=779337 I've made some build modifications and the autotools seem unable to properly do this without a full cleaning.
OK, it's really a duplicate. Why does jhbuild uses --disable-static ?
I have added --disable-static here to speed up the build. As mentioned in mail I've tried again with the same result, and I think it's related to builddir != srcdir. jhbuild builds in ~/.cache/jhbuild here while the source is located in ~/src/gnome/
*** Bug 781881 has been marked as a duplicate of this bug. ***
(In reply to Benoît Dejean from comment #3) > OK, it's really a duplicate. Why does jhbuild uses --disable-static ? JHBuild uses --disable-static by default for all modules, because we never want to install static libraries in GNOME, and it's a waste of time to build libraries twice. This is how all GNOME releases are prepared. It's also how Fedora packages are prepared.
This flag disables static libraries, that's not the same that not installing static libraries. system-monitor builds a noninst static library and that flag disables it: https://git.gnome.org/browse/gnome-system-monitor/tree/src/legacy/Makefile.am If anyone has another idea about how do build a separate object with different flags, I'll take it. Our requirements are that the C files must be built with different flags and dependencies thant the C++ files.
FWIW we are not going to change the flags we use to build all of GNOME just for system-monitor. We've used --disable-static for longer than I remember.
(In reply to Benoît Dejean from comment #7) > system-monitor builds a noninst static library and that flag disables it: > > https://git.gnome.org/browse/gnome-system-monitor/tree/src/legacy/Makefile.am I'm not sure... lots of GNOME modules use static libtool convenience libraries (.lo files) during the build, that's extremely common. They are definitely not disabled by use of --disable-static. What looks funky here is that you're directly using a non-libtool archive legacy/gsm-resources.o in LDADD in src/Makefile.am. That looks wrong; I've never seen that before. I think that's the problem here. It also defeats the point of using libtool, since it's not portable (not that I care about that :). Why can't you use a normal libtool archive there? > If anyone has another idea about how do build a separate object with > different flags, I'll take it. Our requirements are that the C files must be > built with different flags and dependencies thant the C++ files. I think you should use a libtool archive for this.
That's the only I've found because glib-compile-resources generates C with ELF stuff that are not pulled for the archive otherwise. You are right that --disable-static doesn't prevent the noinst library to be built, it only makes the weird legacy/gsm-resources.o inclusion from src/Makefile.am work. (Anyway, I've tried to override this with jhbuild, but adding --enable-static does not drop the --disable-static)
The generated resource files should be included in the main executable, not a convenience library. Use CFLAGS and CXXFLAGS to control compiler flags on a language-specific basis. If you have flags in CPPFLAGS or LDFLAGS that are somehow language-specific, rethink this. You don't need special dependencies for your resource files.
Why exactly does libgsmlegacy exist? It looks like the only difference is that it doesn't link to the *mm dependencies? I think you can probably simplify things a lot by getting rid of it.
Created attachment 350743 [details] [review] Include generated GResource source directly in executable One of the cardinal rules of Autotools is to only ever work with libtool archives, as directly generating native shared or static libaries is not portable and defeats the point of using libtool. However, libtool archives are incompatible with GResources. This is not really problematic, though, as we can just include the generated GResource source directly in the target executable, like other GNOME apps do. This fixes the build with --disable-static, which is used to build all GNOME modules in JHBuild.
You should not compile C files with C++ flags and includes. That's what called the switch to a legacy lib. It used to be like your patch but was raising more and more warnings. We have a bunch of C files, and we need them to be compiled with C-only flags and includes.
(In reply to Benoît Dejean from comment #14) > You should not compile C files with C++ flags Yes, so don't put C++ flags into CFLAGS or CPPFLAGS (C preprocessor flags). > and includes. That's unreasonable, as it would make it impractical to combine C and C++ code. Just don't include C++ headers in your C files. > That's what > called the switch to a legacy lib. It used to be like your patch but was > raising more and more warnings. We have a bunch of C files, and we need them > to be compiled with C-only flags and includes. You don't need a separate library to get separate build flags for your C and C++ files (CFLAGS and CXXFLAGS), and you really don't need separate includes (CPPFLAGS). It's true that, to my knowledge, a separate library is the only way to get separate CPPFLAGS in Autotools, but I don't understand why you you would ever need that or why you think you need that. Anyway, although you'll probably either have to do something along the lines of my patch or just give up on using GResource, I don't really care how you fix this. When this is fixed, please revert https://git.gnome.org/browse/jhbuild/commit/?id=bccf664bd912979fa49ca50a99f58841291dec2e
Can we keep it cool ? I think I need a separate CPPFLAGS because PKG_CHECK_MODULES / pkg-config do not have separate cflags/cppflags concept. The initial problem is that 'pkg-config --cflags gtkmm-3.0' gives a '-std=c++11' switch. Then AM_CPPFLAGS is initialized with all the _CFLAGS variables, which leads to C sources being compiled with a C++ switch. The only alternative I can see is to install the xml and ui files instead ?
Created attachment 350767 [details] [review] 0001-Do-not-compile-the-GResource-to-C-but-create-bundle-.patch
(In reply to Benoît Dejean from comment #16) > The initial problem is that > 'pkg-config --cflags gtkmm-3.0' gives a '-std=c++11' switch. Ah, wow! I guess it's not clearly wrong for gtkmm to put C++ flags into pkg-config's cflags. Although C++ flags are not C flags, pkg-config cflags actually map to Automake's CPPFLAGS (which you do use properly in gnome-system-monitor), and I suppose it probably is expected to specify C++ standard version there. But this is clearly causing a big problem for applications that use both C and C++. Moreover, most applications probably want to use GCC's default standard, std=gnu++14, without being unexpectedly downgraded to the older standard and having GNU extensions disabled. So I think the best solution here is for the *mm libraries to not specify any C++ standard version via pkg-config. Applications that depend on *mm libraries should specify an appropriate version of the C++ standard themselves. Application developers are basically required to know which standards version they're using anyway. Otherwise, with new C++17 just a few months away and new standards being ratified so frequently nowadays, we're headed towards a dark future where different C++ libraries attempt to specify different standards versions using pkg-config. Murray, what do you think about this?
Comment on attachment 350743 [details] [review] Include generated GResource source directly in executable Your patch seems better than mine. Nice workaround. Shame it's needed. :/
Created attachment 350768 [details] [review] 0001-Do-not-compile-the-GResource-to-C-but-create-bundle-.patch Same as before but removed the debug puts statement.
I confirm that with this patch jhbuild can now successfully compile gnome-system-monitor. Robert ?
Ok, tested the patch and it works.
Sorry for tumbling in, but that's where randomly browsing gets me... (In reply to Benoît Dejean from comment #16) > I think I need a separate CPPFLAGS because PKG_CHECK_MODULES / pkg-config do > not have separate cflags/cppflags concept. The initial problem is that > 'pkg-config --cflags gtkmm-3.0' gives a '-std=c++11' switch. Then > AM_CPPFLAGS is initialized with all the _CFLAGS variables, which leads to C > sources being compiled with a C++ switch.] Then IMO the real fix would be not to do that with AM_CPPFLAGS. It seems very wrong to me to stuff CFLAGS into any CPPFLAGS. Is this something that is widely done? Is it essential for any purpose, or just convenient? FWIW, my current project is written in C++ with gtkmm, but I have a GResource, which I have no problem at all in * separately compiling my GResource as C, with the C compiler having its own sets of preprocessor/compiler flags, includes, etc.; * having my C++ source that needs the GResource do extern "C" { #include "the-gresource.h" } * and using the C++ linker on the various C- or C++-derived object files.
(In reply to Daniel Boles from comment #23) > Then IMO the real fix would be not to do that with AM_CPPFLAGS. It seems > very wrong to me to stuff CFLAGS into any CPPFLAGS. Is this something that > is widely done? Is it essential for any purpose, or just convenient? The confusion is that pkg-config --cflags is badly-named. It is supposed to be only used for C preprocessor flags: CPPFLAGS. But it is named --cflags, and the Autotools variables are named _CFLAGS. That is stupidly confusing. But yes, the right thing to do is not to specify --std=c++11 at all in pkg-config, because pkg-config has no place to do so, and because all GNOME applications probably want C++ 14 (which we use in WebKit) or maybe even C++ 17 instead. I would be extremely frustrated if I wanted to use gtkmm and it were to force me down to C++ 11....