Creëer een enkele statische (convenience?) Bibliotheek met Autotools en meerdere build-directories

Ik onderhoud een bibliotheekproject met een "front-end" -bibliotheek en meerdere "back-end" -bibliotheken. Het project maakt gebruik van de Autotools-suite (die ik aan het leren ben en het vinden van de implementatie van ons project is aan onderhoud toe) inclusief Libtool. Als gedeelde bibliotheken werkt alles heel goed. We hebben een applicatie-ontwikkelaar die de bibliotheek gebruikt en die het liefst met behulp van statische bibliotheken bouwt voor zijn gemak van softwaredistributie over meerdere platforms (ik wil zijn motieven niet bespreken).

Hij heeft me verteld dat hij op een eerder moment in staat was om een ​​enkele grote statische bibliotheek te bouwen met behulp van ons build-systeem, maar dat niet langer lukt. Ik heb niet precies kunnen traceren wanneer dit gebeurde, maar vermoed dat dit verband kan houden met een van de twee wijzigingen. De eerste wijziging was het verwijderen van een gebundelde libtool-brondirectory. De tweede was het plaatsen van de back-endbibliotheken in/usr/local/lib/project in plaats van ze te verspreiden zoals voorheen in/usr/local/lib (standaardlocaties).

Wat ik niet heb kunnen leren, is hoe je de frontend-bibliotheek combineert met de backends in één gemaksbibliotheek onder/usr/local/lib en dit doet binnen het Autotools-framework. Dit lijkt mogelijk, maar ik heb geen voorbeeld gevonden om van te leren.

Terzijde: de projecten bouwen verschillende hulpprogramma's als onderdeel van onze testsuite. Ik heb de configuratie uitgevoerd met de optie --disable-shared, make en de hulpprogramma's zijn statisch gekoppeld aan de projectbibliotheek. Nu is mijn zoektocht om deze functionaliteit beschikbaar te maken voor toepassingen van derden.

1
Heb je het equivalent van je versiebeheer van git bisect uitgevoerd om er zeker achter te komen welke commit verantwoordelijk was?
toegevoegd de auteur ptomato, de bron
Nee. Ik ben niet zeker van de commando's die hij gebruikte en of hij op dat moment zijn eigen script gebruikte. Ook heb ik de bibliotheek nooit op die manier zelf gebouwd omdat ik niet om een ​​statische bibliotheek gaf. Ik hoorde dit voor het eerst ongeveer een jaar geleden en ben op zoek naar een antwoord of op zijn minst enkele aanwijzingen.
toegevoegd de auteur Nate B., de bron

1 antwoord

In het Libtool-jargon is een bibliotheek met voorzieningen een bibliotheek die niet is geïnstalleerd. Het moet worden gedeclareerd aan Automake met het voorvoegsel noinst _ .

Wanneer u een bibliotheek L bouwt uit meerdere gemaksbibliotheken: alle gemaksbibliotheken worden verzameld om een ​​enkele bibliotheek L te bouwen die zal worden geïnstalleerd. Dit gebeurt ongeacht of L een gedeelde bibliotheek of een statische bibliotheek is.

Mijn gok is dat je een derde verandering hebt: misschien waren al je backend-bibliotheken in het verleden gemak (dwz noinst_ ) bibliotheken, dus je was effectief in het installeren van slechts één .so en een .a uiteindelijk; maar op een gegeven moment werd besloten om al deze back-endbibliotheken op zichzelf te installeren (dwz de noinst _ in pkglib _ of iets dergelijks te veranderen), daarom zijn deze bibliotheken niet meer gemaksbibliotheken en ze zijn niet langer opgenomen in de frontend.

Merk op dat als de geïnstalleerde back-endbibliotheken nog steeds worden weergegeven als een _LIBADD voor de frontend-bibliotheek, deze afhankelijkheid nog steeds wordt vastgelegd door Libtool. Wanneer u een koppeling maakt naar het geïnstalleerde frontend.la -bestand (dit vereist dat u libtool gebruikt om te linken, zelfs als een gebruiker van de bibliotheek), moet Libtool ook de back-endbibliotheken bevatten , ongeacht of frontend.la is gecompileerd als een statische of gedeelde bibliotheek.

PS: De zaak zou iets anders zijn als uw back-endbibliotheken in werkelijkheid Libtool-modules (a.k.a.-plug-ins) zijn die door de frontend worden doorgevoerd.

2
toegevoegd
Bedankt voor de info. Naarmate ik meer leer, zal het voor mij logischer zijn. Ik zal die zoekwoorden in de gaten houden terwijl ik de configure.ac en verschillende Makefile.am-bestanden bestudeer.
toegevoegd de auteur Nate B., de bron
Tussen haakjes, voor iedereen die een kijkje wil nemen, is de Git-repository op hamlib.git.sourceforge.net/git/gitweb.cgi?p=hamlib/… , een LGPL/GPL-bibliotheek voor het vertalen van verschillende radiocontroleprotocollen naar een uniforme API. Een beetje grepping onthult dat alle backend-bibliotheken zijn opgegeven als pkglib_LTLIBRARIES = hamlib-backend.la /
toegevoegd de auteur Nate B., de bron