After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 780162 - valac failure with separate build directory
valac failure with separate build directory
Status: RESOLVED FIXED
Product: vte
Classification: Core
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-03-16 20:42 UTC by Egmont Koblinger
Modified: 2017-12-28 20:38 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Egmont Koblinger 2017-03-16 20:42:40 UTC
$ mkdir BUILD
$ cd BUILD
$ ../autogen.sh
$ make

[...]
Making all in vala
make[3]: Entering directory '/tmp/vte-221aae5/BUILD/bindings/vala'
 VAPIGEN vte-2.91.vapi
  VALAC    ../../../bindings/vala/vte_2_91_vala.stamp
error: ./vte-2.91.vapi not found
Compilation failed: 1 error(s), 0 warning(s)
Makefile:642: recipe for target '../../../bindings/vala/vte_2_91_vala.stamp' failed
make[3]: *** [../../../bindings/vala/vte_2_91_vala.stamp] Error 1
make[3]: Leaving directory '/tmp/vte-221aae5/BUILD/bindings/vala'
Makefile:447: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/tmp/vte-221aae5/BUILD/bindings'
Makefile:573: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/tmp/vte-221aae5/BUILD'
Makefile:480: recipe for target 'all' failed
make: *** [all] Error 2

Recent commits 221aae5 and 9ca6db2 don't modify the behavior, 9ca6db2^ also fails with this error.

Interestingly, the reportedly missing file _is_ there in the directory where 'make' stands at that time (/tmp/vte-221aae5/BUILD/bindings/vala/vte-2.91.vapi). Does valac maybe change its directory?
Comment 1 Egmont Koblinger 2017-03-16 20:56:46 UTC
The 0.47.90 tarball suffers from the same issue.  0.46.1 is fine.
Comment 2 Dominique Leuenberger 2017-03-20 22:50:07 UTC
Commit https://git.gnome.org/browse/vte/commit/?id=29fb71d3e6ba46e3539a2e0b755b0c7bb1c74670 references this bug

Actually, with this applied, I am not able to build vte, neither using srcdir==builddir nor srcdir!=builddir

[  140s] git.mk: Generating .gitignore
[  140s] CDPATH="${ZSH_VERSION+.}:" && cd . && /usr/bin/valac --target-glib=2.38 --pkg=posix --pkg=gio-2.0 --pkg=gtk+-3.0 --gresources app.gresource.xml  --disable-since-check -D GTK_3_16  -C app.vala config.vapi
[  140s] gcc -DHAVE_CONFIG_H -I. -I../..  -I../../src -I../../src/vte -I../../src/vte    -Wno-unused-variable -Wno-unused-but-set-variable -pthread -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/gtk-3.0 -I/usr/include/pkg/libxkbcommon -I/usr/include/wayland -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libdrm -I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/p11-kit-1 -pipe -Wall -Wcast-align -Wendif-labels -Werror=declaration-after-statement -Werror=format=2 -Werror=format-nonliteral -Werror=format-security -Werror=implicit-function-declaration -Werror=init-self -Werror=missing-include-dirs -Werror=missing-prototypes -Werror=pointer-arith -Wextra -Wfloat-equal -Wlogical-op -Wmisleading-indentation -Wmissing-declarations -Wmissing-include-dirs -Wmissing-format-attribute -Wmissing-noreturn -Wno-missing-field-initializers -Wno-switch-enum -Wno-unused-parameter -Wno-packed -Wshadow -Wsign-compare -Wstrict-aliasing=2 -Wundef -Wuninitialized -Wunsafe-loop-optimizations -Wwrite-strings -fno-common -fdiagnostics-show-option -fno-strict-aliasing -fstack-protector -fstack-protector-strong -fno-semantic-interposition -Wno-deprecated-declarations -Waggregate-return -Wimplicit -Wnested-externs -Wold-style-definition -Wstrict-prototypes  -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -g -c -o vte_2_91-appresources.o `test -f 'appresources.c' || echo './'`appresources.c
[  141s] app.vala:975.5-1047.6: warning: the modifier `static' is not applicable to constants
[  141s] app.vala:25.10-25.12: error: The symbol `Vte' could not be found
[  141s]   public Vte.Terminal terminal { get; construct set; }
[  141s]          ^^^
[  141s] app.vala:42.24-42.26: error: The symbol `Vte' could not be found
[  141s]   public SearchPopover(Vte.Terminal term,
[  141s]                        ^^^



Reverting the referenced commit allowed me to build vte-0.48.0
Comment 3 Christian Persch 2017-03-20 22:55:04 UTC
Works here both for srcdir and non-srcdir builds, on F25.
Comment 4 Egmont Koblinger 2017-03-20 22:57:36 UTC
Ouch.

Succeeds for me in 2 out of my 3 checked out repos, fails in 1.

Also fails with a fresh checkout.
Comment 5 Egmont Koblinger 2017-03-20 22:58:07 UTC
@chpe, does it work you after a fresh git clone?
Comment 6 Christian Persch 2017-03-20 23:18:40 UTC
Yes.
Comment 7 Egmont Koblinger 2017-03-20 23:33:05 UTC
Actually it fails in all my repos, I just needed to do a "make clean".
Comment 8 Dominique Leuenberger 2017-03-20 23:34:10 UTC
(In reply to Egmont Koblinger from comment #7)
> Actually it fails in all my repos, I just needed to do a "make clean".

Glad to hear I'm not just insane
Comment 9 Christian Persch 2017-03-21 12:23:30 UTC
I reverted the patch.

No idea what to try next here, maybe just WONTFIX builddir != srcdir with --enable-vala ?
Comment 10 Egmont Koblinger 2017-03-21 12:59:09 UTC
Could you please cherry-pick the revert to 0-48?

Let's not close as wontfix, at least keep it open even if we can't fix it currently.
Comment 11 Egmont Koblinger 2017-04-06 02:45:07 UTC
FYI: I've upgraded to Zesty (17.04), the same compilation problem of 0.48.0 persists (0.48.1 and master are okay of course due to the revert).
Comment 12 Christian Persch 2017-12-28 20:38:29 UTC
AFAIK this is fixed on master.