FreeBSD buildfixes

[XVilka]

Taken from https://svnweb.freebsd.org/ports/head/devel/radare2/Makefile?revision=463925&view=markup

1. Documentation building patch:

post-patch-DOCS-off:
--
34 | @${REINPLACE_CMD} -e 's\| install-doc \|\|g' \
35 | ${WRKSRC}/Makefile

2. SDB HOST_CC is not autodetected properly

MAKE_ENV+= HOST_CC=${CC}

Without it it tries to use GCC.

[radare]

Can we have the freebsd maintainer to send a pullreq for this? Killing install-doc is a bad idea

And the sdhostcc problem should be affecting other platforms if changed. So better have a pr

[MaskRay]

Alternatively, you can advocate meson and ask them to switch from configure to meson.

meson . release --buildtype=release --prefix=~/.config/radare2/prefix -Db_lundef=false
# b_lundef=false because `environ` is not in libc.so but in crt1.o, r_util .so will have an undefined reference

[unixfreaxjp]

ask them to switch from configure to meson.

That will never gonna happen.

[Maijin]

Here are some findings regarding MESON and freebsd:

• Keyword of MESON in freebsd doc - https://www.freebsd.org/doc/en/books/porters-handbook/uses-meson.html
• Link for MESON port - https://svnweb.freebsd.org/ports/head/devel/meson/
• Discussion about MESON - https://reviews.freebsd.org/D10409
• There are few projects thare are using it alreayd - https://github.com/freebsd/freebsd-ports/search?p=4&q=USES%3Dmeson&unscoped_q=USES%3Dmeson

It may worth investigating the possibilities of using MESON in freebsd, testing it and discussing it.

[unixfreaxjp]

I guess I am starting to script my own stages build scheme on r2 compilation for BSD, just in case some future problem. Just in case.

[XVilka]

Met this problem during setting up the autobuilds for FreeBSD here: https://builds.sr.ht/~xvilka/radare2

>>>>>>>>>>>>>>>>
NATIVE BUILD SDB
>>>>>>>>>>>>>>>>

gmake -C sdb clean
gmake[3]: Entering directory '/usr/home/build/radare2/shlr/sdb'
rm -f src/sdb_version.h
cd src && gmake clean
gmake[4]: Entering directory '/usr/home/build/radare2/shlr/sdb/src'
rm -rf cdb.o buffer.o cdb_make.o ls.o sdbht.o ht_uu.o sdb.o num.o base64.o match.o json.o ns.o lock.o util.o disk.o query.o array.o fmt.o journal.o dict.o ht_pp.o ht_up.o cdb.o.o buffer.o.o cdb_make.o.o ls.o.o sdbht.o.o ht_uu.o.o sdb.o.o num.o.o base64.o.o match.o.o json.o.o ns.o.o lock.o.o util.o.o disk.o.o query.o.o array.o.o fmt.o.o journal.o.o dict.o.o ht_pp.o.o ht_up.o.o main.o libsdb.a a.out sdb sdb.dSYM
rm -rf *.d *._d json/*.d json/*._d *.sdb *.db *.so *.so.*
gmake[4]: Leaving directory '/usr/home/build/radare2/shlr/sdb/src'
cd memcache && gmake clean
gmake[4]: Entering directory '/usr/home/build/radare2/shlr/sdb/memcache'
gmake[4]: Nothing to be done for 'clean'.
gmake[4]: Leaving directory '/usr/home/build/radare2/shlr/sdb/memcache'
cd test && gmake clean
gmake[4]: Entering directory '/usr/home/build/radare2/shlr/sdb/test'
gmake[4]: Nothing to be done for 'clean'.
gmake[4]: Leaving directory '/usr/home/build/radare2/shlr/sdb/test'
gmake[3]: Leaving directory '/usr/home/build/radare2/shlr/sdb'
gmake -C sdb src/sdb_version.h
gmake[3]: Entering directory '/usr/home/build/radare2/shlr/sdb'
echo '#define SDB_VERSION "1.4.0"' > src/sdb_version.h
gmake[3]: Leaving directory '/usr/home/build/radare2/shlr/sdb'
gmake -C sdb/src CC=gcc LDFLAGS='' CPPFLAGS='' CFLAGS=' -fPIC' bin
gmake[3]: Entering directory '/usr/home/build/radare2/shlr/sdb/src'
gcc -c  -fPIC  -o cdb.o cdb.c
gmake[3]: gcc: Command not found
gmake[3]: *** [Makefile:75: cdb.o] Error 127
gmake[3]: Leaving directory '/usr/home/build/radare2/shlr/sdb/src'
gmake[2]: *** [Makefile:145: sdb/sdb] Error 2
gmake[2]: Leaving directory '/usr/home/build/radare2/shlr'
gmake[1]: *** [Makefile:126: targets] Error 2
gmake[1]: Leaving directory '/usr/home/build/radare2/shlr'
gmake: *** [Makefile:60: all] Error 2

[Maijin]

Oh nice! Great finding @XVilka

[XVilka]

TODO: also run regression tests with these

[radare]

release is tonight, i though 1 year and a half was enough time to fix this

[unixfreaxjp]

can't compile. see: https://twitter.com/malwaremustd1e/status/1174702479432474625
please use the version check for older freebsd. Again, P L E A S E.
@radare @XVilka

[unixfreaxjp]

log:

CC PIC ht_pp.c
CC PIC ht_up.c
CC PIC set.c
LIB libsdb.so.1.4.1
CC binheap.c
CC mem.c
CC unum.c
CC str.c
CC hex.c
CC file.c
CC range.c
CC tinyrange.c
CC prof.c
CC cache.c
CC sys.c
CC buf.c
CC w32-sys.c
sys.c:314:2: warning: #warning TODO: r_sys_bt : unimplemented
sys.c: In function 'r_sys_perror_str':
sys.c:877: warning: ignoring #pragma push_macro
sys.c:880: warning: ignoring #pragma pop_macro
sys.c: In function 'r_sys_run_rop':
sys.c:1042: error: expected string literal before ')' token
CC ubase64.c
gmake[2]: *** [/usr/home/TEST/radare/radare2-TEST/libr/../global.mk:36: sys.o] Error 1
gmake[2]: *** Waiting for unfinished jobs....
gmake[1]: *** [../rules.mk:62: all] Error 2
gmake: *** [Makefile:58: all] Error 2

Reason:
No legacies has that r_sys_bt or r_sys_run_rop on kernel, why not checking the version as previously done?

[devnexen]

@unixfreaxjp what you mention on Twitter is a different thing, what compiler and FreeBSD version are you using if you do not mind ? I ll try to have a look later unless someone else find it.

[unixfreaxjp]

@devnexen yes, I also just realized that now too, along with announcing below the investigation result of the bug:

I checked all source code:

git-5bb241711983c5d8b548c7980058f1dda67fb5d6 3.9.0 --> sys.c: In function 'r_sys_run_rop': sys.c:1042: error: expected string literal before ')' token
3.9.0 --> sys.c: In function 'r_sys_run_rop': sys.c:1042: error: expected string literal before ')' toke
3.8.0 --> sys.c: In function 'r_sys_run_rop': sys.c:1042: error: expected string literal before ')' toke
3.7.1 --> ctype.c:14: error: redefinition of typedef 'RParseCType'
radare2-3.7.1/libr/include/r_parse.h:79: error: previous declaration of 'RParseCType' was here
3.7.0 --> no build error, the "r2" command line is inaccessible (install script problem)
3.6.0 --> perfect!

The investigation result:

0. source code: radare2/libr/util/sys.c
1. function "r_sys_run_rop"
2. Start from mid August 2019
3. After 3.7.0 released.

The problem source:

Ragg rop chain #13609 #13609
by @scrapbird

The solution proposed:

I think we need to add _FREEBSD check to exclude it from R_SYS_ASM_START_ROP code below:

  :
#ifdef __x86_64__
# ifdef _MSC_VER

#  define R_SYS_ASM_START_ROP() \
	 eprintf ("r_sys_run_rop: Unsupported arch\n");
# else
  :

Issue is opened with suggested workaround

#15079

cc: @radare @XVilka

[unixfreaxjp]

Checked. My box & legacies doesn't support r_sys_run_rop and somehow it was undetected, or to be precised, the FreeBSD detection for this feature is none. Below ifdef may help to exclude it. And only put supported version under FREEBSD_SUPPORTED_ROP to do those new ROP code stuff..

# if __FreeBSD_version >= 1000000
# define FREEBSD_SUPPORTED_ROP

@radare @XVilka @devnexen @scrapbird @unixfreaxjp
cc: @tessyjp @sonodam

[devnexen]

I may have a "slightly" better idea, I m building under FreeBSD 9.2 and realised it does not support this form of inline assembly. If I modify slightly it does compile.

[unixfreaxjp]

@devnexen
Thank you for the reply.
Go for it, what’s good for 9.2 is good for mine too, got 9.3 custom here and above example works.
@radare @XVilka

[devnexen]

Ok so I ll try 9.3 i386 (did tested only amd64) just saw the details of your ticket.

[unixfreaxjp]

for freebsd 9.3 and 10.4 is needed for many software dev have both arch each, others are 11 and 12 on each arch, the rest are the "others" bsd's.

[radare]

still not closeable?

[unixfreaxjp]

I put crond watch for FreeBSD 9.3,10, 11,12. Should I proceed tests down to r2dec and/or r2ghidra plugin for this compatibility or just core codes? I am aiming for build error. Please advise. Thank you.
(has some error build)
@radare @XVilka

[radare]

@unixfreaxjp you may open issues in the r2dec and r2ghidra repos with a build error message. the plan is to switch to the new testsuite after 4.2, and then we will be able to enable the BSD testsuite and eventually automatically build r2dec and r2ghidra too

[radare]

i think we can close this now that we are building r2 in freebsd in CI

[unixfreaxjp]

I can not upgrade BSD servers to fir to my criteria of tests due to COVID19 emergency situation. Sorry for delay. Basically as workaround I slowly test all one by one booting systems locally under VM and it is super slow. I will post issue if significant bug is spotted. So far none of those level.
For committed OS on tests please kindy see: #11558 (comment)
I dropped all of my legacy machines from operational for this.