One question about GCC and GPL3.
Is it possible to use library's headers with BSD-like license inside GCC project(-fork)?
Suppose there is a BSD-library named A (libA), which describes some IR-A. The libA has a method compileModuleA. While working this method loads (dlopen) a some extern dynamic-libraryB (by path and name from text config-file) and call another compileModuleB-method (dlsym) from dynamic-libB.
Also there is a translator from GIMPLE to IR-A and a call of compileModuleA in GCC(-fork). GCC is linked with libA and includes libA-headers.
So libA knows nothing about GCC and libB projects and their headers. The libB uses only libA headers and realizes method compileModuleB. GCC uses only libA headers.
GCC libB \ / libA
So can the libA be under BSD-license, and the libB be under non-open source license? Is such scheme valid with GCC under GPL3?
(First posted question on stackoverflow. The proper way is to post or search on stackexchange.)
By following Can plugins for closed source software use GPL'd libraries? lets add some clarifications.
Substitutes libB to executable toolB, libA's callback to vfork/exec of toolB and a sending IR-A by a socket (as text for example). The toolB parses IR-A text (without linking with libA) and compiles it to a target assembler and send assembler back by socket.
(addition:) GCC-GPL prints assembler's text. Llvm-BSD prints assembler's text. So as for me assembler is "open" language. Assembler's text may be printend by GCC-GPL and then translated to object code by llvm-as-BSD (at theoretically). For usability just technically llvm-as may be called by vfork/exec and assembler's text/object code can be send by socketpair without temporary files. And now I think that it is a legal usage. For example if GCC-GPL prints llvm-IR (by internal GPL-module) and sends llvm-IR to llc it is a legal too, isn't it?
What was my mistake from the begining? (One of them :)) Llvm-IR is used by many passes and it is a "high-level" IR (in fact it is a very similar to C). So adding a bridge from llvm-IR to some another IR just before MachineCode-transformation gives a functional compiler "library".
In contrast, GIMPLE-IR, if I am rigth, has different stages (early, medium, later and etc). And also the huge part of common functionality (lowering) works on RTL (with different stages too). That is why I think now that a bridge from (early)-GIMPLE to "extern"-IR by printing a text is possible in legal sence. (Of course it is very hard work with certain circumstances, but not rocket sience at all.) But probably such scheme gives only a C/C++ frontend without many important functional parts.