Compiling issues on CentOS7

An update on centos7 seems to have broken something. The OS continues to compile openwrt image generator but when it comes to LEDE, I cannot get past the following problems.

Build dependency: Please reinstall the GNU C Compiler - it appears to be broken
Build dependency: Please reinstall the GNU C++ Compiler - it appears to be broken
Build dependency: Please install ncurses. (Missing libncurses.so or ncurses.h)
Build dependency: Please install a static zlib. (Missing libz.a or zlib.h)

I've been searching for two days on the net, trying different suggestions but still cannot get past this. More confusing is why image generator still works with chaos calmer but these problems with LEDE.

Any help would be so very appreciated.

What happens if you do as instructed (reinstall several packages)?

I've done that, all of them have been reinstalled and then some. That's why I'm asking here because I'm out of ideas and threads to read :slight_smile:

Odd, similar issue on Debian too.

On Debian, same thing. Everything compiles fine with openwrt but I get the following error with lede.

bash: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by bash)

bash: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by bash)

Oddly, the above shows both 2.14 and 2.15.

What is going on and why does lede require these newer tools that most will not have on their machines?

Most will have since all newer distributions have them.

RedHat and CentOS are conservative in their version selection and not "bleeding edge" in the way that Fedora, Debian, and, to some extent Ubuntu are. There may be RPMs for the newer versions available.

I don't recall how RedHat/CentOS handle multiple versions of utilities, but if there isn't a way to keep the "as-shipped" version of the compiler as well as a newer one, you may have difficulty with builds of other software. If there isn't an OS-supplied way of selecting between compilers, setting environment variables or aliases is a typical approach. The OpenWRT build system, bring GNU-based, may also support the idea of version-qualified build tools.

This is not uncommon. For example, to build the Andriod OS, you need the proper versions of the utilities, as well as a specific version of Java, any of which can vary by the version of the build tools you are using.

Thank you. Everything you said makes sense and I understand now.

I'm running Centos 7.4 (which is in fact the very latest) and Debian 7 so if both of these cannot update to the required versions, can you suggest what does. I'll install a new vm to handle both openwrt and lede.

Debian 7 is pretty old now, but I know that it was from the era when version upgrades were not easy (upgrading from "Jessie" 8 or later is comparatively easy). A VM running the current version of Debian, Ubuntu, or your favorite, regularly updated, Linux-based distro would probably be the least invasive way of moving forward with OpenWRT.

You might want to consider activating ''ccache'' so that you can make the most of the core or two you can give the VM.

Edit: See if https://stackoverflow.com/questions/36327805/how-to-install-gcc-5-3-with-yum-on-centos-7-2 helps you on getting a more-current host toolchain.

I tried the stackoverflow update but still get the same error. I'm sure it's because I need to call the correct gcc as there are two now, I think.

Anyhow, I think I'll go with a new Debian as you suggested and not get into running multiple this and that.

I'll give it a try and update this with a confirmation.

1 Like

Installed and fully updated Debian 9. All files required installed for building.

Tested lede using simply 'make image'

Downloading http://downloads.lede-project.org/releases/17.01.4/targets/ramips/mt7620/packages/Packages.gz
wget: error while loading shared libraries: libssl.so.10: cannot open shared object file: No such file or directory
*** Failed to download the package list from http://downloads.lede-project.org/releases/17.01.4/targets/ramips/mt7620/packages/Packages.gz

# apt-get install libssl1.0.0 libssl-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package libssl1.0.0 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'libssl1.0.0' has no installation candidate

Now what's going on?
Am I missing libssl.so.10 or is the repo site down? Some combination?

Do you have libssl-dev installed?

Yes, libssl-dev is installed.

libssl-dev is already the newest version (1.1.0f-3+deb9u1).

https://askubuntu.com/questions/339364/libssl-so-10-cannot-open-shared-object-file-no-such-file-or-directory/339370

Pretty much your issue

That's what I was looking at actually. The problem is this;

Package libssl1.0.0 is not available, but is referred to by another package

Package libssl1.0.0 is not available, but is referred to by another package

Simple, find a package which contains this.

You have searched for paths that end with libssl1.0.0 in suite stretch, all sections, and architecture(s) amd64.

Sorry, your search gave no results

Have you run the ./scripts/feeds update -a and ./scripts/feeds install -a process yet?

Did you check make menuconfig or the equivalent?

# ./scripts/feeds update -a
Unable to open feeds configuration at ./scripts/feeds line 46.

# ./scripts/feeds install -a
Unable to open feeds configuration at ./scripts/feeds line 46.

# make menuconfig
make: *** No rule to make target 'menuconfig'.  Stop.

Ah, my mistake on those commands -- you've got the Image Buider, not the full build environment.

suggests that you've got connectivity issues in your VM. http://downloads.lede-project.org/releases/17.01.4/targets/ramips/mt7620/packages/ gives me a page on my browser here.

sudo apt-get update && sudo apt-get upgrade and/or a reinstall of wget and its dependencies on your VM may help.

Edit: Trying a "dumb" install of Debian 9 on VirtualBox right now. "Dumb" in that I basically just took defaults. "Dumb" also in that it's taking forever to install the GUI packages that I didn't really need.

Edit: After figuring out how to get sudo to work (need to su root to get things going), installing the packages as outlined on https://openwrt.org/docs/guide-user/additional-software/imagebuilder#prerequisites, installing the Image Builder for ar71xxx from https://downloads.lede-project.org/snapshots/targets/ar71xx/generic/openwrt-imagebuilder-ar71xx-generic.Linux-x86_64.tar.xz and unpacking it, make image seemed to be proceeding smoothly until I ran out of the 8 GB disk. Starting over with 16 GB as the VirtualBox resize resulted in a hung Debian VM.

Edit: Followed the above steps with a 16 GB virtual disk, just "Standard system utilities" installed, and can build the ar71xx images without any issues. With a single core of a MacBook Pro, t's not terribly fast compared to native on a relatively recent i3-7100T CPU @ 3.40GHz, but it seems completely functional.

Edit: Same result with https://downloads.lede-project.org/releases/17.01.4/targets/ramips/mt7620/lede-imagebuilder-17.01.4-ramips-mt7620.Linux-x86_64.tar.xz

I re-installed wget and no change.
I can compile the openwrt version but not the lede.

No connectivity issues... checked that the very first time and consistently reach all but the lede repo only when running make.

Then it gets weird.

Downloading -------------lede-project.org/releases/17.01.4/targets/ramips/mt7620/packages/Packages.gz
wget: error while loading shared libraries: libssl.so.10: cannot open shared object file: No such file or directory
*** Failed to download the package list from ------------lede-project.org/releases/17.01.4/targets/ramips/mt7620/packages/Packages.gz

I can manually download the same darn file.
wget ---------lede-project.org/releases/17.01.4/targets/ramips/mt7620/packages/Packages.gz

Confused.

(Had to edit the links since I'm not allowed to enter two+)

As I just created a fresh VirtualBox VM, installed Debian 9, installed the pre-reqs, dowloaded the LEDE 17.0.4 Image Builder that appears to correspond to the one you're using, and built an image without any issues, I think it has to be an issue with your VM. I'd start fresh if I were in your shoes. You did build a 64-bit VM and install 64-bit Debian, yes?