On 25 September 2018 at 09:29, blubee blubeeme <gurenc...@gmail.com> wrote: > On Tue, Sep 25, 2018 at 5:27 PM Lorenzo Salvadore via freebsd-ports < > freebsd-ports@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. _______________________________________________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
