Hi Kees, > Am 22.05.2019 um 08:02 schrieb H. Nikolaus Schaller <h...@goldelico.com>: > > It turns out that HOSTCC and HOSTCXX are a gcc-4.9.4 installed through > MacPorts. > And CC is the self-bootstrapped cross-gcc-4.9.2 toolchain for arm. > > The problem is likely that they do not know of each other, i.e. the required > include and library search paths. Therefore HOSTCXX can't build plugins > compatible > with CC because it does not even know its existence. Or the gcc-4.9.4 from > MacPorts > is missing the gcc-plugin library to link against which would explain the > HOSTLLD > error message as well. > > This seems not to be found by the tests of scripts/gcc-plugin.sh. I have to > check why...
Well, here are some findings: * gcc-plugin.sh does not check if the g++ is really capable of linking a gcc-plugin * it only syntax-checks if g++ supports the designated initializer GNU extension * my gcc from MacPorts passes this test * but seems not to be able to properly build any gcc-plugin.so * I also get the similar linker errors when trying this gcc-plugin example: https://thinkingeek.com/2015/08/16/a-simple-plugin-for-gcc-part-1/ * the step that fails with the MacPorts gcc is linking the gcc-plugin.so from the gcc-plugin.o file * I have not found any hint where this step should get the missing symbols from There is no lgcc or similar available So I'd suggest to expand gcc-plugin.sh to not only syntax-check but also test if a plugin.so can be successfully linked. Maybe something like $2 -std=gnu++98 -shared -o /tmp/plugin.so -I"${srctree}"/gcc-plugins -I"${gccplugins_dir}"/include 2>&1 Maybe the test source code should reference plugin_default_version_check() to trigger the linker. BR and thanks, Nikolaus
