Posting on behalf of @bixu, who’s currently having issues logging in to the forums
 api(do_before)> ldd $(hab pkg path core/pcre)/lib/libpcre.so.1 linux-vdso.so.1 (0x00007fff955c6000) libpthread.so.0 => /hab/pkgs/core/glibc/2.27/20180608041157/lib/libpthread.so.0 (0x00007fd1ca979000) libc.so.6 => /hab/pkgs/core/glibc/2.27/20180608041157/lib/libc.so.6 (0x00007fd1ca5c5000) /hab/pkgs/core/glibc/2.22/20170513201042/lib64/ld-linux-x86-64.so.2 (0x00007fd1cae1e000)
The issues around
core/glibcare completely blocking us at the moment so I’m trying to figure out the root cause/how to disentangle…
We ended up removing PCRE from our uWSGI build config. This is a workaround, not a fix (if we needed regular expressions in uWSGI we’d be back to a broken build. Does anyone have any ideas about how to solve the core problem, which seems to be around conflicting glibc versions?
I’ll likely have to solve similar problems soon. I think your
lddoutput might be a bit misleading though, the version of ld-linux is just based on whatever version of ldd you have binlinked, not baked into the so
@bixu Is this an issue you are getting in Bldr or in your own build process or both?
And, if it is a build process outside of bldr, do you happen to be using a custom HAB_BLDR_CHANNEL?
we see it in both Builder and in Studio builds.
We are using 0.58.0
Heya hab-team. I think we need to figure out some advice for people about what to do about the kind of build issues @bixu is hitting, at least until the work that allows us to unpin the backline packages is done.
The crux of his issue seems to be this:
- His build requires setting LD_LIBRARY_PATH
- Some of the libraries in the LD_LIBRARY_PATH includes libraries used by
grepused by hab-plan-build is pinned to the old packages and thus incompatible with the library in LD_LIBRARY_PATH.
This isn’t a grep-specific problem. It can occur with any of the tools required by hab-plan-build if you happen to set LD_LIBRARY_PATH or other variables via your build.
Anyway, that is the summary of the issue. It is the same basic issue as people were seeing with attach() and 0.58 didn’t fix it because we had to pin backline packages because of the breaking changes in glibc.
I believe the
attach thread @ssd is referring to is Cannot Attach in a Plan where CFLAGS, LIBRARY_PATH, or LD_LIBRARY_PATH are modified