Thanks for help! Ian Lance Taylor-3 wrote: > > Both these approaches assume that at compile time there is some way to > discover the naming convention used by an imported package. I don't > know if that is true of your language. > Packages can be shared without source, so if a file compiles, the compiler can't know which other packages will import this one. So it can't prevent being imported to a project where its symbols are already in use. The solution could be when that importing package (source_both in this case) is compiled: Maybe I can get the compiler to change the symbol tables in the already compiled files (source_a and _b) to have unique names. This would require an additional build-step between compiling and linking -> "preparing" the object files, by making their symbol names unique. I don't like my idea, though, sounds like "hacking" the object files. Ian Lance Taylor-3 wrote: > > In general, you will need a naming trick of this sort to make your > import statements work with the GNU linker. The GNU linker does not > rename symbols on the fly. > Renaming symbols sounds good, but I can't find unique names at compile time. I just "carefully skimmed through" the ELF specification: it looks like there's no way to specify the origin (the file) of an imported symbol. I'd be very happy if someone told me my last statement was a wrong conclusion! I assume, if ELF can't do that for me, COFF can't either? Maybe I could use linker scripts? I haven't read through the linker's manual, but it has a large section about scripting. Trojany -- View this message in context: http://old.nabble.com/Relative-imports-and-GNU-linker...---tp28712872p28749749.html Sent from the gcc - Help mailing list archive at Nabble.com.
