error: undefined symbol: main in poudriere jail

[Ed Maste]

On 25 September 2018 at 09:29, blubee blubeeme <gurenchan at gmail.com> wrote:
> On Tue, Sep 25, 2018 at 5:27 PM Lorenzo Salvadore via freebsd-ports <
> freebsd-ports at freebsd.org> wrote:
>
>> > > That's the problem, the same code works for earlier version of FreeBSD.
>> >
>> > You can try switching back to the old GNU ld via something like "ln
>> > -fs ld.bfd /usr/bin/ld" and building the port on 12. (Or, set
>> > WITHOUT_LLD_IS_LD in src.conf.) If that works I'll try to suggest some
>> > further steps.
>
> going into the jail on this failed poudiere build making the symlink and
> building; the build succeeds.

Ok - it is very strange that using BFD ld vs lld causes main() to
appear or not in one of the objects being linked; I suspect this is a
2nd-order effect of some build-time test that's failing for some
reason with lld.

Briefly, at a high-level there are two ways to approach a case like
this: get the port linking with GNU ld, or find and fix the root
cause. Ports has a knob LLD_UNSAFE that should cause base ld.bfd or
one from the binutils package to be used, but it does not work in some
cases (generally, ports with old embedded libtool or that otherwise do
not honour LDFLAGS or CFLAGS).

To take this to root cause there's probably a straightforward (if
long/tedious) path to be taken in comparing the results of building in
two jails, one with ld is ld.bfd and one with ld is ld.lld. The link
is failing with ld.lld, so compare the objects passed to the link
invocations between the two cases and find one that contains main() in
the bfd case and not in the lld case, and work backwards from there.

You can set LLD_REPRODUCE=_something_.tar in the environment and lld
will create a tarball of all inputs, command line, etc. for further
investigation.