Brian Dessent wrote: > Paul Brook wrote: > >> If you really want to solve this then you could always stop using PE/COFF. >> The ARM EABI (and in particular the arm-none-symbianelf target) demonstrates >> how this can be done. Basically the toolchain generates ELF objects, >> executables and DSOs, then you feed them through a postlinker to generate >> target (PE/COFF) images. > > Using ELF as an intermediary format doesn't really change the situation > facing the design of plugins in any meaningful way though. If the end > result is still PE/COFF executables and DLLs then the same problems and > restrictions still exist that would make the current proposed design > unworkable on these Windows targets. If you recall the issue is that > plugins want unfettered access to the full symbol table of the > executable. Doing this with PE/COFF is possible, but it binds the > plugin DLL to the specific name of the executable that it was linked > against, such that the same plugin wouldn't be loadable from cc1.exe, > cc1plus.exe, f951.exe, etc. To get around this you'd have to either > link a separate copy of the plugin for each executable,
So do that, then. Where's the problem? Andrew.
