Bug 158417 – REGRESSION(r201449) [GTK] ARMv7 build fails with libicudata.so.55: cannot open shared object file on gtkdoc-scangobj step

• Status: RESOLVED
• Resolution: FIXED
• Component: Tools / Tests

[Carlos Alberto Lopez Perez]

After r201449 <http://trac.webkit.org/r201449> The GTK+ ARM buildbot is failing to build with the following output:

[14/293] Generating ../docs-build-no-html.stamp[K
FAILED: cd /webkit/gtk-linux-arm-release/build/WebKitBuild/Release && CC=/usr/lib/ccache/cc CFLAGS=-Wno-error\  /webkit/gtk-linux-arm-release/build/Tools/gtk/generate-gtkdoc --skip-html && touch docs-build-no-html.stamp
Copying template files to output directory...
Running gtkdoc-scan
Running gtkdoc-scangobj
./webkitdomgtk-4.0-scan: error while loading shared libraries: libicudata.so.55: cannot open shared object file: No such file or directory
Scan failed: 

Generating webkitdomgtk-4.0 documentation...
Traceback (most recent call last):
  File "/webkit/gtk-linux-arm-release/build/Tools/gtk/generate-gtkdoc", line 201, in <module>
    saw_warnings = generate_documentation(webkitdom_generator)
  File "/webkit/gtk-linux-arm-release/build/Tools/gtk/generate-gtkdoc", line 148, in generate_documentation
    return generate_doc(generator, arguments.skip_html)
  File "/webkit/gtk-linux-arm-release/build/Tools/gtk/generate-gtkdoc", line 134, in generate_doc
    generator.generate(not skip_html)
  File "/webkit/gtk-linux-arm-release/build/Tools/gtk/gtkdoc.py", line 143, in generate
    self._run_gtkdoc_scangobj()
  File "/webkit/gtk-linux-arm-release/build/Tools/gtk/gtkdoc.py", line 338, in _run_gtkdoc_scangobj
    env=env, cwd=self.output_dir)
  File "/webkit/gtk-linux-arm-release/build/Tools/gtk/gtkdoc.py", line 209, in _run_command
    % (args[0], process.returncode))
Exception: gtkdoc-scangobj produced a non-zero return code 127

https://build.webkit.org/builders/GTK%20Linux%20ARM%20Release/builds/11341/steps/compile-webkit/logs/stdio

[Carlos Alberto Lopez Perez]

I can reproduce the problem on a wandboard running Debian 8 Jessie.

The issue is related to this:

1) wandboard ~/WebKit $ file WebKitBuild/Release/Documentation/webkitdomgtk-4.0/webkitdomgtk-4.0-scan
WebKitBuild/Release/Documentation/webkitdomgtk-4.0/webkitdomgtk-4.0-scan: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=96abf72688893997831d15db58f8c814c4ce91e0, not stripped


2) wandboard ~/WebKit $ ldd WebKitBuild/Release/Documentation/webkitdomgtk-4.0/webkitdomgtk-4.0-scan | grep icu
	libicui18n.so.52 => /usr/lib/arm-linux-gnueabihf/libicui18n.so.52 (0xb47ab000)
	libicuuc.so.52 => /usr/lib/arm-linux-gnueabihf/libicuuc.so.52 (0xb467c000)
	libharfbuzz-icu.so.0 => /usr/lib/arm-linux-gnueabihf/libharfbuzz-icu.so.0 (0xb420e000)
	libicudata.so.52 => /usr/lib/arm-linux-gnueabihf/libicudata.so.52 (0xb23b3000)


3) wandboard ~/WebKit $ LD_LIBRARY_PATH=$(pwd)/WebKitBuild/DependenciesGTK/Root/lib ldd WebKitBuild/Release/Documentation/webkitdomgtk-4.0/webkitdomgtk-4.0-scan | grep icu
	libicui18n.so.52 => /usr/lib/arm-linux-gnueabihf/libicui18n.so.52 (0xb4688000)
	libicuuc.so.52 => /usr/lib/arm-linux-gnueabihf/libicuuc.so.52 (0xb4559000)
	libharfbuzz-icu.so.0 => /home/igalia/WebKit/WebKitBuild/DependenciesGTK/Root/lib/libharfbuzz-icu.so.0 (0xb40bd000)
	libicudata.so.52 => /usr/lib/arm-linux-gnueabihf/libicudata.so.52 (0xb2082000)
	libicuuc.so.55 => /home/igalia/WebKit/WebKitBuild/DependenciesGTK/Root/lib/libicuuc.so.55 (0xb1d45000)
	libicudata.so.55 => not found
	libicudata.so.55 => not found


When the ldd command is run inside the JHBuild environment (LD_LIBRARY_PATH env variable) the linker is not able to resolve the library dependencies.

My wild guess is that maybe webkitdomgtk-4.0-scan has been built outside of the JHBuild because it is linking against libicudata.so.52 instead of libicudata.so.55 ?

[Carlos Alberto Lopez Perez]

The libraries seem all there:

wandboard ~/WebKit $ ls -ln WebKitBuild/DependenciesGTK/Root/lib/*icu*.*
lrwxrwxrwx 1 1001 1001       26 Jun  6 10:29 WebKitBuild/DependenciesGTK/Root/lib/libharfbuzz-icu.so -> libharfbuzz-icu.so.0.935.0
lrwxrwxrwx 1 1001 1001       26 Jun  6 10:29 WebKitBuild/DependenciesGTK/Root/lib/libharfbuzz-icu.so.0 -> libharfbuzz-icu.so.0.935.0
-rwxr-xr-x 1 1001 1001     9344 Jun  6 10:29 WebKitBuild/DependenciesGTK/Root/lib/libharfbuzz-icu.so.0.935.0
lrwxrwxrwx 1 1001 1001       18 Jun  6 10:27 WebKitBuild/DependenciesGTK/Root/lib/libicudata.so -> libicudata.so.55.1
lrwxrwxrwx 1 1001 1001       18 Jun  6 10:27 WebKitBuild/DependenciesGTK/Root/lib/libicudata.so.55 -> libicudata.so.55.1
-rwxr-xr-x 1 1001 1001 25910236 Jun  6 10:27 WebKitBuild/DependenciesGTK/Root/lib/libicudata.so.55.1
lrwxrwxrwx 1 1001 1001       18 Jun  6 10:27 WebKitBuild/DependenciesGTK/Root/lib/libicui18n.so -> libicui18n.so.55.1
lrwxrwxrwx 1 1001 1001       18 Jun  6 10:27 WebKitBuild/DependenciesGTK/Root/lib/libicui18n.so.55 -> libicui18n.so.55.1
-rwxr-xr-x 1 1001 1001  3935528 Jun  6 10:27 WebKitBuild/DependenciesGTK/Root/lib/libicui18n.so.55.1
lrwxrwxrwx 1 1001 1001       16 Jun  6 10:27 WebKitBuild/DependenciesGTK/Root/lib/libicuio.so -> libicuio.so.55.1
lrwxrwxrwx 1 1001 1001       16 Jun  6 10:27 WebKitBuild/DependenciesGTK/Root/lib/libicuio.so.55 -> libicuio.so.55.1
-rwxr-xr-x 1 1001 1001    83668 Jun  6 10:27 WebKitBuild/DependenciesGTK/Root/lib/libicuio.so.55.1
lrwxrwxrwx 1 1001 1001       16 Jun  6 10:27 WebKitBuild/DependenciesGTK/Root/lib/libicule.so -> libicule.so.55.1
lrwxrwxrwx 1 1001 1001       16 Jun  6 10:27 WebKitBuild/DependenciesGTK/Root/lib/libicule.so.55 -> libicule.so.55.1
-rwxr-xr-x 1 1001 1001   696304 Jun  6 10:27 WebKitBuild/DependenciesGTK/Root/lib/libicule.so.55.1
lrwxrwxrwx 1 1001 1001       16 Jun  6 10:27 WebKitBuild/DependenciesGTK/Root/lib/libiculx.so -> libiculx.so.55.1
lrwxrwxrwx 1 1001 1001       16 Jun  6 10:27 WebKitBuild/DependenciesGTK/Root/lib/libiculx.so.55 -> libiculx.so.55.1
-rwxr-xr-x 1 1001 1001    79888 Jun  6 10:27 WebKitBuild/DependenciesGTK/Root/lib/libiculx.so.55.1
lrwxrwxrwx 1 1001 1001       18 Jun  6 10:27 WebKitBuild/DependenciesGTK/Root/lib/libicutest.so -> libicutest.so.55.1
lrwxrwxrwx 1 1001 1001       18 Jun  6 10:27 WebKitBuild/DependenciesGTK/Root/lib/libicutest.so.55 -> libicutest.so.55.1
-rwxr-xr-x 1 1001 1001    96556 Jun  6 10:27 WebKitBuild/DependenciesGTK/Root/lib/libicutest.so.55.1
lrwxrwxrwx 1 1001 1001       16 Jun  6 10:27 WebKitBuild/DependenciesGTK/Root/lib/libicutu.so -> libicutu.so.55.1
lrwxrwxrwx 1 1001 1001       16 Jun  6 10:27 WebKitBuild/DependenciesGTK/Root/lib/libicutu.so.55 -> libicutu.so.55.1
-rwxr-xr-x 1 1001 1001   404264 Jun  6 10:27 WebKitBuild/DependenciesGTK/Root/lib/libicutu.so.55.1
lrwxrwxrwx 1 1001 1001       16 Jun  6 10:27 WebKitBuild/DependenciesGTK/Root/lib/libicuuc.so -> libicuuc.so.55.1
lrwxrwxrwx 1 1001 1001       16 Jun  6 10:27 WebKitBuild/DependenciesGTK/Root/lib/libicuuc.so.55 -> libicuuc.so.55.1
-rwxr-xr-x 1 1001 1001  2446324 Jun  6 10:27 WebKitBuild/DependenciesGTK/Root/lib/libicuuc.so.55.1

[Carlos Alberto Lopez Perez]

After some tests I was able to reduce the problem to this:

1) Save this C code example http://stuf.ro/reading-a-utf-8-file-in-c-with-icu as testicu.c
2) Compile it as follows:
$ gcc $(pkg-config --cflags --libs icu-io) testicu.c -o testicu


If you do this on the standard environment (outside of JHBuild) everything works as expected.

However, if you do that inside the internal JHBuild shell then everything goes wrong.

----

This is what happens outside of JHBuild:

$ echo "Hello world!" > utf8_test.txt
$ gcc $(pkg-config --cflags --libs icu-io) testicu.c -o testicu

$ ldd testicu
	libicuio.so.52 => /usr/lib/arm-linux-gnueabihf/libicuio.so.52 (0xb6eb7000)
	libicui18n.so.52 => /usr/lib/arm-linux-gnueabihf/libicui18n.so.52 (0xb6d5f000)
	libicuuc.so.52 => /usr/lib/arm-linux-gnueabihf/libicuuc.so.52 (0xb6c53000)
	libicudata.so.52 => /usr/lib/arm-linux-gnueabihf/libicudata.so.52 (0xb55d7000)
	libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb54e7000)
	libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb54d4000)
	libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb541d000)
	libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb53a9000)
	libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb5380000)
	/lib/ld-linux-armhf.so.3 (0xb6ee4000)

$ ./testicu 
String size: 13

Hello world!

$ pkg-config --cflags --libs icu-io
-I/usr/include/arm-linux-gnueabihf -licuio -licui18n -licuuc -licudata 


-----------

This is what happens inside of JHBuild:

$ Tools/jhbuild/jhbuild-wrapper --gtk shell
$ echo "Hello world!" > utf8_test.txt
$ gcc $(pkg-config --cflags --libs icu-io) testicu.c -o testicu

$ ldd testicu
	libicuio.so.55 => /home/igalia/WebKit/WebKitBuild/DependenciesGTK/Root/lib/libicuio.so.55 (0xb6f49000)
	libicui18n.so.55 => /home/igalia/WebKit/WebKitBuild/DependenciesGTK/Root/lib/libicui18n.so.55 (0xb6c56000)
	libicuuc.so.55 => /home/igalia/WebKit/WebKitBuild/DependenciesGTK/Root/lib/libicuuc.so.55 (0xb6a56000)
	libicudata.so.55 => not found
	libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6952000)
	libicudata.so.55 => not found
	libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb693f000)
	libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb68cb000)
	libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb6814000)
	libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb67eb000)
	/lib/ld-linux-armhf.so.3 (0xb6f69000)
	libicudata.so.55 => not found
	libicudata.so.55 => not found
$ ./testicu
./testicu: error while loading shared libraries: libicudata.so.55: cannot open shared object file: No such file or directory

$ pkg-config --cflags --libs icu-io
-L/home/igalia/WebKit/WebKitBuild/DependenciesGTK/Root/lib -licuio -licui18n -licuuc -licudata

[Carlos Alberto Lopez Perez]

It seems there is something wrong with the libicudata we are building

inside_internal_jhbuild $ ldd /home/igalia/WebKit/WebKitBuild/DependenciesGTK/Root/lib/libicuio.so.55.1 
	libicuuc.so.55 => /home/igalia/WebKit/WebKitBuild/DependenciesGTK/Root/lib/libicuuc.so.55 (0xb6d39000)
	libicudata.so.55 => not found
	libicui18n.so.55 => /home/igalia/WebKit/WebKitBuild/DependenciesGTK/Root/lib/libicui18n.so.55 (0xb6a32000)
	libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6a1f000)
	libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb69ab000)
	libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb68f4000)
	libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb68cb000)
	libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb67db000)
	/lib/ld-linux-armhf.so.3 (0xb6f59000)
	libicudata.so.55 => not found
	libicudata.so.55 => not found

inside_internal_jhbuild $ ls -l WebKitBuild/DependenciesGTK/Root/lib/libicudata.so*
lrwxrwxrwx 1 igalia igalia       18 Jun  6 12:52 WebKitBuild/DependenciesGTK/Root/lib/libicudata.so -> libicudata.so.55.1
lrwxrwxrwx 1 igalia igalia       18 Jun  6 12:52 WebKitBuild/DependenciesGTK/Root/lib/libicudata.so.55 -> libicudata.so.55.1
-rwxr-xr-x 1 igalia igalia 25910236 Jun  6 12:52 WebKitBuild/DependenciesGTK/Root/lib/libicudata.so.55.1

$ ldd WebKitBuild/DependenciesGTK/Root/lib/libicudata.so.55.1
	not a dynamic executable

$ file WebKitBuild/DependenciesGTK/Root/lib/libicudata.so.55.1
WebKitBuild/DependenciesGTK/Root/lib/libicudata.so.55.1: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=1abd350642e527e20bb600a32865f3b5b2abde4a, not stripped


ldd outputs not a dynamic executable for the libicudata we build. But it works for the icudata from the system

$ ldd /usr/lib/arm-linux-gnueabihf/libicudata.so.52.1 
	libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb5790000)
	/lib/ld-linux-armhf.so.3 (0xb6f10000)

[Carlos Alberto Lopez Perez]

(In reply to comment #4)
> 
> $ ldd WebKitBuild/DependenciesGTK/Root/lib/libicudata.so.55.1
> 	not a dynamic executable
> 
> $ file WebKitBuild/DependenciesGTK/Root/lib/libicudata.so.55.1
> WebKitBuild/DependenciesGTK/Root/lib/libicudata.so.55.1: ELF 32-bit LSB
> shared object, ARM, EABI5 version 1 (SYSV), dynamically linked,
> BuildID[sha1]=1abd350642e527e20bb600a32865f3b5b2abde4a, not stripped
> 
> 
> ldd outputs not a dynamic executable for the libicudata we build. But it
> works for the icudata from the system
> 
> $ ldd /usr/lib/arm-linux-gnueabihf/libicudata.so.52.1 
> 	libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb5790000)
> 	/lib/ld-linux-armhf.so.3 (0xb6f10000)


This debian bug report has some interesting comments about the same (or very similar) issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653457#10

[Carlos Alberto Lopez Perez]

(In reply to comment #5)
> (In reply to comment #4)
> > 
> > $ ldd WebKitBuild/DependenciesGTK/Root/lib/libicudata.so.55.1
> > 	not a dynamic executable
> > 
> > $ file WebKitBuild/DependenciesGTK/Root/lib/libicudata.so.55.1
> > WebKitBuild/DependenciesGTK/Root/lib/libicudata.so.55.1: ELF 32-bit LSB
> > shared object, ARM, EABI5 version 1 (SYSV), dynamically linked,
> > BuildID[sha1]=1abd350642e527e20bb600a32865f3b5b2abde4a, not stripped
> > 
> > 
> > ldd outputs not a dynamic executable for the libicudata we build. But it
> > works for the icudata from the system
> > 
> > $ ldd /usr/lib/arm-linux-gnueabihf/libicudata.so.52.1 
> > 	libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb5790000)
> > 	/lib/ld-linux-armhf.so.3 (0xb6f10000)
> 
> 
> This debian bug report has some interesting comments about the same (or very
> similar) issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653457#10

Indeed, very same issue.

Applying the above Debian patch to the icu sources and rebuilding fixes the build and al liking problems.

wandboard ~/WebKit $ LD_LIBRARY_PATH=$(pwd)/WebKitBuild/DependenciesGTK/Root/lib ldd WebKitBuild/Release/bin/WebKitWebProcess |grep icu
	libicui18n.so.55 => /home/igalia/WebKit/WebKitBuild/DependenciesGTK/Root/lib/libicui18n.so.55 (0xb454d000)
	libicuuc.so.55 => /home/igalia/WebKit/WebKitBuild/DependenciesGTK/Root/lib/libicuuc.so.55 (0xb4317000)
	libharfbuzz-icu.so.0 => /home/igalia/WebKit/WebKitBuild/DependenciesGTK/Root/lib/libharfbuzz-icu.so.0 (0xb395e000)
	libicudata.so.55 => /home/igalia/WebKit/WebKitBuild/DependenciesGTK/Root/lib/libicudata.so.55 (0xb1298000)


I'm going to upload a patch ASAP.

[Carlos Alberto Lopez Perez]

Created attachment 280612 [details]
Patch

[Michael Catanzaro]

Comment on attachment 280612 [details]
Patch

Looks like we run about 10 sed scripts to do this not only here but also to a bunch of different Makefiles when building the Fedora package... so this solution is much simpler than what we have.

[WebKit Commit Bot]

Comment on attachment 280612 [details]
Patch

Clearing flags on attachment: 280612

Committed r201726: <http://trac.webkit.org/changeset/201726>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Carlos Garcia Campos]

Wow, this was tricky, thank you very much Carlos!