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 789800 - "No such file or directory" error when running gtkdoc-scangobj after commit "scanobj: Don't depend on the system shell"
"No such file or directory" error when running gtkdoc-scangobj after commit "...
Status: RESOLVED WONTFIX
Product: gtk-doc
Classification: Platform
Component: general
1.27
Other Linux
: Normal normal
: ---
Assigned To: gtk-doc maintainers
gtk-doc maintainers
Depends on:
Blocks:
 
 
Reported: 2017-11-02 05:30 UTC by Michael Catanzaro
Modified: 2017-11-03 19:37 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Michael Catanzaro 2017-11-02 05:30:40 UTC
The commit "scanobj: Don't depend on the system shell" broke gtk-doc generation for WebKit. After that commit I'm now seeing a "No such file or directory" error:

$ ninja gtkdoc-no-html
[4/4] Generating ../docs-build-no-html.stamp
FAILED: docs-build-no-html.stamp 
cd /home/mcatanzaro/Projects/WebKit/WebKitBuild/GNOME && /usr/bin/cmake -E env CC=/usr/lib64/ccache/cc "CFLAGS=-fdiagnostics-color=always -Wno-expansion-to-defined -Wno-maybe-uninitialized -Wwrite-strings -Wundef -Wpointer-arith -Wmissing-format-attribute -Wformat-security -Wcast-align -Wextra -Wall  -fno-strict-aliasing -fno-exceptions -gsplit-dwarf -Wno-unused-parameter" /home/mcatanzaro/Projects/WebKit/Tools/gtk/generate-gtkdoc --skip-html && touch docs-build-no-html.stamp
WARNING:root:[Errno 2] No such file or directory
Traceback (most recent call last):
  • File "/home/mcatanzaro/Projects/WebKit/Tools/gtk/generate-gtkdoc", line 200 in <module>
    saw_warnings = generate_documentation(webkitdom_generator)
  • File "/home/mcatanzaro/Projects/WebKit/Tools/gtk/generate-gtkdoc", line 148 in generate_documentation
    return generate_doc(generator, arguments.skip_html)
  • File "/home/mcatanzaro/Projects/WebKit/Tools/gtk/generate-gtkdoc", line 135 in generate_doc
    generator.generate(not skip_html)
  • File "/home/mcatanzaro/Projects/WebKit/Tools/gtk/gtkdoc.py", line 143 in generate
    self._run_gtkdoc_scangobj()
  • File "/home/mcatanzaro/Projects/WebKit/Tools/gtk/gtkdoc.py", line 338 in _run_gtkdoc_scangobj
    env=env, cwd=self.output_dir)
  • File "/home/mcatanzaro/Projects/WebKit/Tools/gtk/gtkdoc.py", line 209 in _run_command
    % (args[0], process.returncode))
Exception: gtkdoc-scangobj produced a non-zero return code 1
ninja: build stopped: subcommand failed.

I haven't debugged it further yet.
Comment 1 Stefan Sauer (gstreamer, gtkdoc dev) 2017-11-02 15:46:56 UTC
I don't see any backtrace from gtkdoc itself here? Can you tell what gtkdoc command was run in the end?
Comment 2 Christoph Reiter (lazka) 2017-11-02 16:11:52 UTC
I suspect it's the output of the OSError handling (sadly it doesn't say which command wasn't found), so it can't find either --cc, --ld or --run.

I'll try to build webkit, but that always takes ages here..
Comment 3 Michael Catanzaro 2017-11-02 16:20:28 UTC
The command that was run was 'gtkdoc-scangobj --module=webkitdomgtk-4.0'. That doesn't work anymore.

Don't waste your time building WebKit on my behalf! Let me try to debug scangobj a bit more to see if I can figure out how exactly the command line it's executing changed. I didn't get that far last night.

What I do remember from last night is that this is the failing command:

    try:
        call(shlex.split(options.cc) + shlex.split(options.cflags) +
             ["-c", "-o", o_file, c_file])
Comment 4 Michael Catanzaro 2017-11-02 17:33:20 UTC
BEFORE the patch, we had this code:

    # Compiling scanner
    command = '%s %s %s -c -o %s %s' % (options.cc, stdout, options.cflags, o_file, c_file)
    res = subprocess.check_call(command, shell=True)

Here's the value of command:

/usr/lib64/ccache/cc >/dev/null -I/home/mcatanzaro/Projects/WebKit/Source -I/home/mcatanzaro/Projects/WebKit/Source/WebKit/WebProcess/InjectedBundle/API/gtk/DOM -I/home/mcatanzaro/Projects/WebKit/WebKitBuild/GNOME/DerivedSources/webkit2gtk -I/home/mcatanzaro/Projects/WebKit/WebKitBuild/GNOME/DerivedSources/ForwardingHeaders/webkit2gtk -I/home/mcatanzaro/Projects/GNOME/install/include/webkitgtk-4.0 -I/home/mcatanzaro/Projects/GNOME/install/include/glib-2.0 -I/home/mcatanzaro/Projects/GNOME/install/lib/glib-2.0/include -I/home/mcatanzaro/Projects/GNOME/install/include/gtk-3.0 -I/home/mcatanzaro/Projects/GNOME/install/include/pango-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/libdrm -I/home/mcatanzaro/Projects/GNOME/install/include/harfbuzz -I/home/mcatanzaro/Projects/GNOME/install/include/gdk-pixbuf-2.0 -I/home/mcatanzaro/Projects/GNOME/install/include/gio-unix-2.0/ -I/home/mcatanzaro/Projects/GNOME/install/include/atk-1.0 -I/home/mcatanzaro/Projects/GNOME/install/include/at-spi2-atk/2.0 -I/home/mcatanzaro/Projects/GNOME/install/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/home/mcatanzaro/Projects/GNOME/install/include/libsoup-2.4 -pthread -I/usr/include/libxml2 -fdiagnostics-color=always -Wno-expansion-to-defined -Wno-maybe-uninitialized -Wwrite-strings -Wundef -Wpointer-arith -Wmissing-format-attribute -Wformat-security -Wcast-align -Wextra -Wall  -fno-strict-aliasing -fno-exceptions -gsplit-dwarf -Wno-unused-parameter -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_32 -Wno-cast-align -c -o webkitdomgtk-4.0-scan.o webkitdomgtk-4.0-scan.c

Now, after the patch, the command is an array:

['/usr/lib64/ccache/cc', '-I/home/mcatanzaro/Projects/WebKit/Source', '-I/home/mcatanzaro/Projects/WebKit/Source/WebKit/WebProcess/InjectedBundle/API/gtk/DOM', '-I/home/mcatanzaro/Projects/WebKit/WebKitBuild/GNOME/DerivedSources/webkit2gtk', '-I/home/mcatanzaro/Projects/WebKit/WebKitBuild/GNOME/DerivedSources/ForwardingHeaders/webkit2gtk', '-I/home/mcatanzaro/Projects/GNOME/install/include/webkitgtk-4.0', '-I/home/mcatanzaro/Projects/GNOME/install/include/glib-2.0', '-I/home/mcatanzaro/Projects/GNOME/install/lib/glib-2.0/include', '-I/home/mcatanzaro/Projects/GNOME/install/include/gtk-3.0', '-I/home/mcatanzaro/Projects/GNOME/install/include/pango-1.0', '-I/usr/include/cairo', '-I/usr/include/pixman-1', '-I/usr/include/freetype2', '-I/usr/include/libpng16', '-I/usr/include/libdrm', '-I/home/mcatanzaro/Projects/GNOME/install/include/harfbuzz', '-I/home/mcatanzaro/Projects/GNOME/install/include/gdk-pixbuf-2.0', '-I/home/mcatanzaro/Projects/GNOME/install/include/gio-unix-2.0/', '-I/home/mcatanzaro/Projects/GNOME/install/include/atk-1.0', '-I/home/mcatanzaro/Projects/GNOME/install/include/at-spi2-atk/2.0', '-I/home/mcatanzaro/Projects/GNOME/install/include/at-spi-2.0', '-I/usr/include/dbus-1.0', '-I/usr/lib64/dbus-1.0/include', '-I/home/mcatanzaro/Projects/GNOME/install/include/libsoup-2.4', '-pthread', '-I/usr/include/libxml2', '-fdiagnostics-color=always', '-Wno-expansion-to-defined', '-Wno-maybe-uninitialized', '-Wwrite-strings', '-Wundef', '-Wpointer-arith', '-Wmissing-format-attribute', '-Wformat-security', '-Wcast-align', '-Wextra', '-Wall', '-fno-strict-aliasing', '-fno-exceptions', '-gsplit-dwarf', '-Wno-unused-parameter', '-DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_32', '-Wno-cast-align', '-c', '-o', 'webkitdomgtk-4.0-scan.o', 'webkitdomgtk-4.0-scan.c']

The only difference is that the original command was a string, not an array, and the output of the original command was redirected to /dev/null. Or at least, that was attempted... I'm not sure if it works or not at that position in the command line.
Comment 5 Michael Catanzaro 2017-11-02 17:36:30 UTC
(In reply to Michael Catanzaro from comment #0)
> WARNING:root:[Errno 2] No such file or directory

I'm stumped why this is happening. I would only expect it to happen if /usr/lib64/ccache/cc was not present. But it is.
Comment 6 Christoph Reiter (lazka) 2017-11-02 18:47:00 UTC
No idea here either, nothing stands out. Maybe revert that patch for now until I find the time to test with webkit.
Comment 7 Michael Catanzaro 2017-11-02 19:32:52 UTC
OK then, thanks for letting me revert it.
Comment 8 Michael Catanzaro 2017-11-02 19:35:12 UTC
Also, the easiest way to test is to configure WebKit with 'cmake -DPORT=GTK -DENABLE_GTKDOC'. Then, after building, cd into the build directory and run 'make gtkdoc' or 'ninja gtkdoc' and watch it fail.
Comment 9 Stefan Sauer (gstreamer, gtkdoc dev) 2017-11-02 20:33:32 UTC
And the other difference was 'shell=True' in the old version, but getting rid of this is the point of the change. I'll research what other side-effect this could have. Too bad, that the os-error has no details. Michael, could you run this through: strace -e file -o strace.log <cmd> ?
Comment 10 Michael Catanzaro 2017-11-03 03:33:09 UTC
(In reply to Michael Catanzaro from comment #3)
> What I do remember from last night is that this is the failing command:
> 
>     try:
>         call(shlex.split(options.cc) + shlex.split(options.cflags) +
>              ["-c", "-o", o_file, c_file])

Well that was totally wrong. I was working too late last night. :P Wasted a lot of time due to that mistake.

This is the line that's actually failing:

call(shlex.split(options.run) + ['./' + x_file])

Here's the command that gets passed:

['LD_LIBRARY_PATH=/home/mcatanzaro/Projects/WebKit/WebKitBuild/GNOME/lib:/home/mcatanzaro/Projects/GNOME/install/lib', './webkitdomgtk-4.0-scan']

So because the shell isn't used anymore, it's now trying to execute the file 'LD_LIBRARY_PATH=/home/mcatanzaro/Projects/WebKit/WebKitBuild/GNOME/lib:/home/mcatanzaro/Projects/GNOME/install/lib'. Ooops!

I don't know if you consider that a supported use of gtkdoc-scangobj --run (actually WebKit uses the RUN envvar) or not. But it looks like there's no compelling reason WebKit needs to use RUN to set LD_LIBRARY_PATH. The following WebKit patch fixes the issue:

diff --git a/Tools/gtk/gtkdoc.py b/Tools/gtk/gtkdoc.py
index 48f862a31fa..03c8e8e9b13 100644
--- a/Tools/gtk/gtkdoc.py
+++ b/Tools/gtk/gtkdoc.py
@@ -319,9 +319,9 @@ class GTKDoc(object):
             ldflags = ' "-L%s" %s ' % (self.library_path, additional_ldflags) +
 ldflags
             current_ld_library_path = env.get('LD_LIBRARY_PATH')
             if current_ld_library_path:
-                env['RUN'] = 'LD_LIBRARY_PATH="%s:%s" ' % (self.library_path, current_ld_library_path)
+                env['LD_LIBRARY_PATH'] = '%s:%s' % (self.library_path, current_ld_library_path)
             else:
-                env['RUN'] = 'LD_LIBRARY_PATH="%s" ' % self.library_path
+                env['LD_LIBRARY_PATH'] = self.library_path
 
         if ldflags:
             env['LDFLAGS'] = '%s %s' % (ldflags, env.get('LDFLAGS', ''))
@@ -332,8 +332,6 @@ class GTKDoc(object):
             self.logger.debug('CFLAGS=%s', env['CFLAGS'])
         if 'LDFLAGS' in env:
             self.logger.debug('LDFLAGS %s', env['LDFLAGS'])
-        if 'RUN' in env:
-            self.logger.debug('RUN=%s', env['RUN'])
         self._run_command(['gtkdoc-scangobj', '--module=%s' % self.module_name],
                           env=env, cwd=self.output_dir)

What do you think?
Comment 11 Stefan Sauer (gstreamer, gtkdoc dev) 2017-11-03 18:08:25 UTC
I would prefer to leave the commit from #789531 in, but also log the commands that were run in the exception. This would make it relative easy for people to fix things. If that sounds okay for you, please close this bug.
Comment 12 Michael Catanzaro 2017-11-03 18:20:12 UTC
Yup, that sounds fine to me.

I guess you'll follow-up on that... note that I already reverted the commit yesterday, so you'll need to un-revert it.
Comment 13 Stefan Sauer (gstreamer, gtkdoc dev) 2017-11-03 19:37:35 UTC
Re-Reverted and pushed this:

commit f97eaa65206145c9369cdb92bfd431ab658dc8d0 (HEAD -> master, origin/master, origin/HEAD)
Author: Stefan Sauer <ensonic@users.sf.net>
Date:   Fri Nov 3 20:33:52 2017 +0100

    scangobj: log the command on error
    
    This is a followup for the change from bgo#789531. Since we don't run
    through the shell, projects can run into troubles like in bgo#789800.


Thanks everyone for debugging this.