Cannot Attach in a Plan where CFLAGS, LIBRARY_PATH, or LD_LIBRARY_PATH are modified

Habitat Help
1

When trying to debug a plan where I need to modify the value of CFLAGS, LIBRARY_PATH, or LD_LIBRARY_PATH, I am getting the following:

### Attaching to debugging session

From: /src/plan.sh @ line 32 :

/hab/pkgs/core/hab-plan-build/0.57.0/20180614232105/bin/hab-plan-build: line 837: 31634 Segmentation fault      (core dumped) awk '{printf "%d: %s\n", NR, $0}' "$src"
     31635                       (core dumped) | sed -e "$((${lnum}-${context})),$((${lnum}+${context}))!d" -e 's,^,    ,g'
     31636                       (core dumped) | sed -e "$((${context}+1))s/^   / =>/"
2

@smacfarlane @fnichol Any ideas on this?

3

I think this is likely more fallout from the recent package refresh. The studio is still
shipping executables built on the pre-refresh packages (glibc 2.22).

[1][default:/src:0]# cat /hab/pkgs/core/grep/2.22/20170513213444/TDEPS 
core/gcc-libs/5.2.0/20170513212920
core/glibc/2.22/20170513201042
core/linux-headers/4.3/20170513200956
core/pcre/8.38/20170513213423

If your LD_LIBRARY_PATH or similar variables causes the loader to pick up newer
libraries, all sorts of fun ensues. For example:

[6][default:/src:127]# hab pkg install core/glibc
» Installing core/glibc
☁ Determining latest version of core/glibc in the 'stable' channel
☛ Verifying core/glibc/2.27/20180608041157
☛ Verifying core/linux-headers/4.15.9/20180608041107
✓ Installed core/linux-headers/4.15.9/20180608041107
✓ Installed core/glibc/2.27/20180608041157
★ Install of core/glibc/2.27/20180608041157 complete with 2 new packages installed.
[7][default:/src:0]# grep --version
grep (GNU grep) 2.22
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Mike Haertel and others, see <http://git.sv.gnu.org/cgit/grep.git/tree/AUTHORS>.
[8][default:/src:0]# LD_LIBRARY_PATH="$(hab pkg path core/glibc)/lib" grep --version
grep: relocation error: /hab/pkgs/core/glibc/2.27/20180608041157/lib/libpthread.so.0: symbol __tunable_get_val, version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference
4

Hi,

A quick follow-up. This type of problem is always /technically/ possible when using tools with LD_LIBRARY_PATH and similar variables set.

However, because of the refresh, we are now in a situation where most of the executables on disk were built against libraries that are older than those that will be resolved during the build. This is why we’ve now seen a few reports of similar errors in the context of attach .

In the case of attach, the user is using a tool built with the pre-refresh versions of a library and is executing commands in the context of their plan.sh where they are most likley to have variables such as LD_LIBRARY_PATH set.

I think rebuilding the studio to include the most recent versions of all the packages should improve the situation for most users.

Cheers,

Steven