> On 22 Jul 2021, at 20:41, Andrew Pinski via Gcc <gcc@gcc.gnu.org> wrote:
>
> On Thu, Jul 22, 2021 at 7:37 AM Marc <m...@mh-sec.de> wrote:
>>
>> I have a gcc plugin (for afl++,
>> https://github.com/AFLplusplus/AFLplusplus) that works fine when
>> compiled on Linux but when compiled on MacOS (brew install gcc) it fails:
>>
>> ~/afl++ $ g++-11 -g -fPIC -std=c++11
>> -I/usr/local/Cellar/gcc/11.1.0_1/lib/gcc/11/gcc/x86_64-apple-darwin20/11.1.0/plugin/include
>> -I/usr/local/Cellar/gcc/11.1.0_1/lib/gcc/11/gcc/x86_64-apple-darwin20/11.1.0/plugin
>> -I/usr/local//Cellar/gmp/6.2.1/include -shared
>> instrumentation/afl-gcc-pass.so.cc -o afl-gcc-pass.so
>
> A few things, You are not building the plugin with the correct options
> for darwin.
> Basically you need to allow undefined references
-Wl, -undefined, dynamic_lookup
but if you expect those to bind to the main exe (e.g. cc1plus) at runtime, then
you will need to build that with dynamic export. (-export_dynamic)
These things will *not* transfer to arm64 macOS and they will probably produce
build warnings from newer linkers.
===
I suspect that we will need to find a different recipe for that case (possibly
using the main exe as a "link library" on the plugin link line, I guess).
> and then also use
> dylib as the extension.
That’s a convention for shared libs but it won’t stop a plugin working (in fact
things like python use .so on macOS)
for pluign modules, (e.g. Frameworks) even omitting the extension completely
has been done.
(so this is not the source of the problem)
> A few other things too. I always forgot the exact options to use on
> Darwin really. GNU libtool can help with that.
perhaps, but I am not sure it’s maintained agressively .. so make sure to check
what you find is up to date.
cheers,
Iain.
