This is the mail archive of the firstname.lastname@example.org mailing list for the gas2 project.
|Index Nav:||[Date Index] [Subject Index] [Author Index] [Thread Index]|
|Message Nav:||[Date Prev] [Date Next]||[Thread Prev] [Thread Next]|
If a shared library defines a function foo, and your program defines a function foo, that does not cause any conflict. Your program's definition of foo is used. If functions in the shared library call foo, they will call your program's definition of foo rather than the shared library's definition. In this sense, shared libraries act just like archive libraries. This is not, in general, what archive libraries do. Archive libraries do this in the common case where each defined global is in a separate member. But if one member defines two different globals, the archive library does not work this way. It is good practice, in most situations, to put each global definition into a separate member, but it is not universal practice. If one member defines two global symbols X and Y, you can have a program which links with no complaint against the shared library, but would get an error if linked against the archive library. All the program needs to do is reference X and define Y as weak. The archive library would define Y and thus override the weak definition from the program. The shared library would, I expect, let the program override Y's definition. I think we should make the shared library work just like the archive in all cases. What is needed is a table of implications: If symbol foo is referenced, treat symbol bar as strong. If symbol bar is referenced, treat symbol foo as strong. If symbol quux is referenced, treat symbols foo and bar as strong. ... (In that example, I've assumed that one member defines both foo and bar, while another member defines quux and references foo.) This table would selectively override the default behavior, which is the same as now (each defined global symbol in the shared library acts as weak). Given this table, there would be no need to do anything special for common symbols. A common symbol in the library could be treated just like any other definition in the library: use it to resolve an undefined reference, or if forced by the table due to a reference to some other symbol. I don't think this would make linking much slower. I think it could be made quite fast by means of a table that parallels the main symbol table in the library, so that you reference it using the same index used in the main symbol table, rather than by looking up names,