Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 25 Mar 2018 23:54:30 -0400
From:      Theron Tarigo <theron.tarigo@gmail.com>
To:        Ryan Stone <rysto32@gmail.com>
Cc:        "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>
Subject:   Re: GSoC Idea: Fakechroot on FreeBSD; Ports building in clean non-root environment
Message-ID:  <cbbab747-9f8c-23c4-5a7d-f91d60526a09@gmail.com>
In-Reply-To: <CAFMmRNxZA0f7bpUQ51Qef5ve19KBkNOYopUp4m4PPFoM3oP8pA@mail.gmail.com>
References:  <eb52f1f7-8802-6571-865c-7d238b704797@gmail.com> <CAFMmRNxZA0f7bpUQ51Qef5ve19KBkNOYopUp4m4PPFoM3oP8pA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 03/25/18 22:17, Ryan Stone wrote:
> Hi Theron,
>
> Earlier in the year I experimented with a similar idea, although my
> goal was quite different.  I eventually hit a roadblock that I wasn't
> able to overcome: on FreeBSD, /usr/bin/cc and /usr/bin/c++ are
> statically linked binaries.  The makes it impossible to intercept any
> system calls made by the "victim" binary.  Would this be a problem for
> what you're trying to do?  I'm not very familiar with the ports build
> process.
Hi Ryan,

Thanks for pointing this out.  This will somewhat complicate the process 
- the fakechroot component will need to be statically linked into these 
binaries, which then would need to live somewhere as modified copies to 
achieve the goal of providing a solution that may be used without 
modification of the base installed system.  However, the number of these 
static binaries is small - apart from a few exceptions which aren't 
involved in compiling ports (devd, init), it seems to be limited to the 
compiler toolchain.  Within the realm of software provided by ports, 
"pkg-static" is the only statically linked binary I can find in my 
system.  Appropriately modified static toolchain binaries may be 
provided as a port, which has the additional advantage of further 
decoupling the ports building process from the local base system.  Using 
the existing llvm60 port might be another way, as these binaries are all 
dynamically linked, however many existing ports are tested to work with 
the toolchain from base, not with the one from the llvm port.

Theron



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cbbab747-9f8c-23c4-5a7d-f91d60526a09>