[GNU] Libraries cross-reference?

[LeonM]

Ik weet niet of de titel klopt, zo niet, dan zal dat ook de reden zijn waarom ik er niks over kan vinden


De situatie:
Ik heb een aantal libraries gemaakt, door de sources te compileren en met de GNU archiver (AR) te bundelen. Zeg voor het voorbeeld lib1.a lib2.a enz.

Nu is het probleem dat een aantal functies uit lib1.a functies uit lib2.a nodig hebben en vise versa. De libraries compileren prima, maar zodra ze worden toegevoegd aan een project, willen ze niet linken (undifined reference).

De functies uit lib1 kunnen de functies uit lib2 niet vinden (en vise versa), ook als ze beide worden toegevoegd aan het te compileren project.

Hoe kan ik dit het beste oplossen?

Toolchain:
GNU make 3.81
GCC 4.4.1 voor ARM targets
Binutils 2.19.1 voor ARM targets

[Verwijderd]

Misschien wat te simpel gedacht, maar als lib1 lib2 nodig heeft en andersom, waarom maak je er dan niet gewoon 1 library van?

[LeonM]

Verwijderd schreef op donderdag 08 oktober 2009 @ 16:18:
Misschien wat te simpel gedacht, maar als lib1 lib2 nodig heeft en andersom, waarom maak je er dan niet gewoon 1 library van?

Ik ben een bestaand product aan het porten, waarvoor ik een aantal libraries heb herschreven, maar de platform onafhankelijke code wil ik hiervoor niet aanpassen, dus de libraries moeten hun originele naam en functies behouden.

Wat ik niet begrijp, is dat als ik bijvoorbeeld doe:

code:

gcc foo.c lib1.a lib2.a

Dan zou dat naar mijn weten vertalen naar:

code:

gcc foo.c obj1a.o obj1b.o obj2a.o obj2b.o enz

Dus waarom ze niet naar elkaar kunnen refereren is mij een raadsel.

[bobo1on1]

code:

 gcc foo.c -Wl,--start-group lib1.a lib2.a -Wl,--end-group

Dat zou moeten werken.

[LeonM]

bobo1on1 schreef op donderdag 08 oktober 2009 @ 16:40:

code:

 gcc foo.c -Wl,--start-group lib1.a lib2.a -Wl,--end-group

Dat zou moeten werken.

Mijn held

[.oisyn]

De reden is dat de linker alle libs in 1 pass aandoet. Als je linkt met lib1.a en lib2.a dan zal hij de references van 1 naar 2 nog wel resolven, maar die terug niet meer, en dus eindig je met unresolved references van 2 naar 1. Dit kun je ook oplossen door lib1 opnieuw te noemen na lib2, hoewel je dan vervolgens weer andere reference errors kunt krijgen.

Het verschil tussen libraries en objects is dat hij alleen de objects uit een lib meeneemt waar referenties naar zijn. Oftewel, de objecten die jij meelinkt zullen sowieso in de executable terecht komen. De objecten van de libraries komen er alleen in als ze nodig zijn, en dat veroorzaakt ook meteen bovenstaand probleem - hij pakt alle objecten in lib1 waar de app een referentie naar heeft. Vervolgens kijkt hij in lib2, pakt daar weer alle benodigde objects uit, wat eventueel weer leidt naar nieuwe unresolved references. Als daar weer references inzitten naar objecten uit lib1 die nog niet zijn meegenomen dan moet hij opnieuw lib1 in, etc.

.edit: Dit is ook min of meer wat er in de docs staat:

--start-group archives --end-group
The archives should be a list of archive files. They may be either explicit file names, or `-l' options. The specified archives are searched repeatedly until no new undefined references are created. Normally, an archive is searched only once in the order that it is specified on the command line. If a symbol in that archive is needed to resolve an undefined symbol referred to by an object in an archive that appears later on the command line, the linker would not be able to resolve that reference. By grouping the archives, they all be searched repeatedly until all possible references are resolved. Using this option has a significant performance cost. It is best to use it only when there are unavoidable circular references between two or more archives.

Overigens werkt

-Wl,-( lib1.a lib2.a -Wl,-)

ook.

[ Voor 31% gewijzigd door .oisyn op 08-10-2009 17:21 ]

[bobo1on1]

Die haakjes waren bij mij niet zo'n success met automake.