compiled chrome tries to use /lib64/ld-linux-x86-64.so.2 when not present
Reported by
john.fra...@outlook.com,
Feb 9 2018
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3343.0 Safari/537.36 Steps to reproduce the problem: 1. compile chromium-browser 2. attempt to run browser - fails 3. symlink link /lib64 -> /lib - works What is the expected behavior? On a pure 64-bit system it should work What went wrong? The compilation system should check for the location of ld-linux-x86-64.so.2 rather than use a hard coded location. Did this work before? N/A Chrome version: 66.0.3343.0 Channel: n/a OS Version: 4.14.10 Flash Version:
,
Feb 10 2018
The path to the loader is /lib/ld-linux-x86-64.so.2 gn was used as follows: gn gen out/Default --args='is_debug=false symbol_level=0 enable_nacl=false remove_webcore_debug_symbols=true'
,
Feb 13 2018
This is probably coming from clang itself (and GCC does something similar): https://chromium.googlesource.com/external/github.com/llvm-mirror/clang/+/a9de5f6b28931eab59bca3c566e135195cb291ce/lib/Driver/ToolChains/Linux.cpp#554 What distro are you using? Does your distro's own compiler packages patch that code?
,
Feb 13 2018
I'm using the 64bit version of tinycorelinux. Since I'm building a chromium-browser package for the distro, no, it doesn't patch that code.. The distros gcc does not use the (non-existant) /lib64 loader - does the chromium-browser build use the system clang or an internal downloaded one?
,
Feb 13 2018
It looks like tinycorelinux's GCC does patch paths so that /lib is used instead of /lib64. If you're building Chromium from git with the GN arguments you mentioned above it will use its own clang copy, which will fail to load because it expects /lib64/ld-linux-x86-64.so.2 to be present (and the same will apply to other binaries that are pulled as part of the build process). If you're building a package (and thus building from a tarball, not git), you'll likely want to use your distro's compiler, be it clang or GCC, in which case you have full control over what the dynamic linker path will be.
,
Feb 14 2018
Are you speaking of using the source code tarballs from: https://github.com/chromium/chromium/releases ..because it looks like these build in the same way as the git clone, i.e. using downloaded rather than system tools?
,
Feb 14 2018
Those tarballs are created by GitHub automatically and aren't expected to build at all (it obviously doesn't include any of the other repositories that Chromium depends on). I'm talking about the tarballs all other distros use to build their packages (https://commondatastorage.googleapis.com/chromium-browser-official/chromium-<VERSION>.tar.xz). We can continue the discussion (or you could post your questions to the chromium-packager mailing list), but I'm closing this bug since there's nothing to fix on our side.
,
Feb 14 2018
I'm not sure, but I'm guessing not. Your best bet is to look at what existing packages are created in other distros and ask the mailing list when you hit a roadblock.
,
Feb 14 2018
Thanks: https://commondatastorage.googleapis.com/chromium-browser-official/chromium-64.0.3282.168.tar.xz works - the source tarballs are well hidden. The readme still contains instructions to compile from git - are there instructions to compile from the tarball somewhere?
,
Feb 14 2018
Hmm - I think I'll file this under too much trouble. Thanks again for your comments.
,
Feb 14 2018
You're welcome. I'm sorry there's no easy answer here, but Chromium is a really complex piece of software with a build system that is not used by any other project and which can be very difficult to package from scratch. Depend on what you need Tinylinuxcore for, you might be better off using something like Yocto (which has a meta-browser layer with an up-to-date-recipe).
,
Feb 14 2018
Tinycorelinux uses the fifth browser (8MB packaged vs 87MB for chromium git), but every so often I need a challenge :) |
|||
►
Sign in to add a comment |
|||
Comment 1 by raphael....@intel.com
, Feb 9 2018