Building with an old version installed and LDFLAGS set

[stevecheckoway]

When building with LDFLAGS set, radare2 may link against an old installed version (see #492).

If the old version is 3.0.1, then building 3.1.0's rasm2 fails due to a missing symbol. See https://trac.macports.org/ticket/57688

Work environment

Questions	Answers
OS/arch/bits (mandatory)	macOS x86_64 64
File format of the file you reverse (mandatory)	N/A
Architecture/bits of the file (mandatory)	N/A
r2 -v full output, not truncated (mandatory)	N/A because it won't build

Expected behavior

I expect radare2 to build and link against the just built version of its libraries.

Actual behavior

_ht_pp_foreach is undefined in 3.0.1's libr_util.dylib so linking rasm2 fails.

gcc  -MD -fno-common   -fPIC -g -Wall -D__UNIX__=1 -I/private/tmp/radare2/libr/../shlr/zip/include -pie -I/private/tmp/radare2/libr/..//libr/include rasm2.o -L.. -o rasm2 -L/tmp/local/lib  -lpthread -lm    -L/private/tmp/radare2/libr/asm -L/private/tmp/radare2/libr/parse -L/private/tmp/radare2/libr/syscall -L/private/tmp/radare2/libr/anal -L/private/tmp/radare2/libr/reg -L/private/tmp/radare2/libr/hash -L/private/tmp/radare2/libr/flag -L/private/tmp/radare2/libr/cons -L/private/tmp/radare2/libr/lang -L/private/tmp/radare2/libr/util -L/private/tmp/radare2/libr/search -L/private/tmp/radare2/libr/crypto -lr_asm -lr_parse -lr_syscall -lr_anal -lr_reg -lr_hash -lr_flag -lr_cons -lr_lang -lr_util -lr_search -lr_crypto -fPIC /private/tmp/radare2/libr/../shlr/zip/librz.a
clang: warning: argument unused during compilation: '-pie' [-Wunused-command-line-argument]
Undefined symbols for architecture x86_64:
  "_ht_pp_foreach", referenced from:
      _print_assembly_output in rasm2.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Steps to reproduce the behavior

Here's a script to reproduce the behavior. It installs 3.0.1 into /tmp/local and then attempts to build 3.1.0 with LDFLAGS=-L/tmp/local/lib set.

#!/bin/sh
set -e

log() {
	printf "\e[32;1m%s\e[0m\n" "$1"
}

log 'Cloning radare2'
git clone 'https://github.com/radare/radare2.git'

log 'Checking out 3.0.1'
cd radare2
git checkout 3.0.1

log 'Building 3.0.1'
./configure --prefix=/tmp/local
make

log 'Installing 3.0.1'
make install

log 'Cleaning and checking out 3.1.0'
make clean
git checkout 3.1.0

log 'Building 3.1.0 with LDFLAGS set'
LDFLAGS=-L/tmp/local/lib ./configure --prefix=/tmp/local
LDFLAGS=-L/tmp/local/lib make

[ipatch]

Just installed radare2 from tag 3.1.0 on macOS 10.13.6 and was running into a similar issue with ld until I removed binutils which was installed via homebrew.

[Maijin]

Same as #12044 ?

[stevecheckoway]

@Maijin That bug doesn't look related. That seems to be about old object files. This is about linking against an already installed version of the libraries rather than the just-built version of the libraries.

[Maijin]

I meant for the binutils removal of @ipatch both issues had this

[radare]

enotime for this release, i prefer to move to 3.3 to properly look at it and not do a quick fix now

[radare]

moving to 3.4, enotime again

[radare]

Trying to reproduce. with cflags i had no problems, so maybe iits an LDFLAGS only issue

also i found the script is testing 3.0.1 vs 3.1.0 .. will be good to chk if ths is still happening with 3.5, or maybe add a travis task to build the last release and then build r2 from git, will require 3 more min to run but we will be sure that the release build fine if u had a previous versoin installed.

may help us also to cleanup deprecated files and such

[i0ntempest]

Just got similar errors upgrading 4.3.1 -> 4.4.0:

Undefined symbols for architecture x86_64:
  "_r_file_abspath_rel", referenced from:
      _main in r2r.o
  "_r_getopt_init", referenced from:
      _main in r2r.o
  "_r_getopt_next", referenced from:
      _main in r2r.o
  "_r_str_version", referenced from:
      _main in r2r.o
  "_r_strbuf_drain_nofree", referenced from:
      _r2r_subprocess_drain in run.o
      _r2r_run_asm_test in run.o
      _replace_cmd_kv in r2r.o
ld: symbol(s) not found for architecture x86_64

Removing the old version fixed it.

[Maijin]

ok thanks for rechecking, closing here.

[mopihopi]

@Maijin : The problem is that new versions aren't built correctly when an old version is currently installed, and i0ntempest reported that this is still a problem.

[Maijin]

right reopening

[ret2libc]

I suggest to use meson to build/install, if you have these kind of issues.

[ryandesign]

I suggest to use meson to build/install, if you have these kind of issues.

Sure, if you'd like to trade the set of problems you already know about for a whole new unknown set of problems. Just fixing the current build system would be simpler for everyone.

[trufae]

I think the best way to track this is to write a script that runs 2 builds of r2 with incompatible API changes and run it in the CI. Anyone have some time to write a reproducer script for this? I'm a bit short in time but i do believe this issue should be fixed, r2 is not suposed to build only on clean environments

[ryandesign]

It's easy enough to reproduce by placing unreadable empty files with the same names as the libraries into any folder and setting LDFLAGS to that folder when configuring.

$ cd /tmp
$ tar xf radare2-5.1.1.tar.gz
$ cd radareorg-radare2-a86f807
$ mkdir foo
$ cd foo
$ for rlib in libr_anal.a libr_asm.a libr_cons.a libr_crypto.a libr_flag.a libr_hash.a libr_lang.a libr_parse.a libr_reg.a libr_search.a libr_syscall.a libr_util.a; do touch $rlib; chmod 000 $rlib; done
$ cd ..
$ LDFLAGS=-L$(PWD)/foo ./configure
...
$ make -j8
...
ld: can't open file, errno=13 file '/tmp/radareorg-radare2-a86f807/foo/libr_util.a' for architecture x86_64

[trufae]

thats a great reproducer. ill find some spare time and do the ci changes and the fix. thanks for sharing that quickly :)

[trufae]

added the ci task here, #18542