SCons pour faire une bibliothèque partagée (.donc) avec une bibliothèque statique (.a)

Je vais essayer d'obtenir SCons pour faire une bibliothèque partagée. L'un des éléments allant dans le .so est un .a statique lib.

J'ai une ligne comme:

env_2.SharedLibrary('libstuff.so', \
  Split("""stuff.cxx mylib/libMine.a""")

Et lors de l'exécution, j'ai cette erreur:

scons: *** Source file: mylib/libMine.a \
is static and is not compatible with shared target: libstuff.so

Cependant, je sais qu'une bibliothèque partagée peut être fait à partir de la .a via une commande comme:

g++ -m32 -shared -o libstuff.so stuff.o mylib/libMine.a

Des idées sur l'obtention de ce travail ou de solution de contournement serait grandement apprécié.

Liés à la question: Comment puis-je obtenir scons pour mettre une corde de plus -shared sur la ligne de commande de LIAISON pour la Program() appel? Si je pouvais faire cela, je pense que ça pourrait répondre à mes besoins.

OriginalL'auteur xavjuan | 2010-02-11

10

Essayer de mettre env['STATIC_AND_SHARED_OBJECTS_ARE_THE_SAME']=1 dans votre SConstruct.

C'est la magie vaudou qui le fait fonctionner.
Cette "magie vaudou' a fonctionné pour moi. Je suis surpris parce que je ne vois pas la différence dans la compilation des options de commande après l'ajout de la de la SConstruct. J'espère que le féticheur qui est venu avec cette magie nous l'explique le commun des mortels.
Le SharedLibrary générateur vérifie si tous les fichiers objets ont été construits avec les SharedObject constructeur (et donc avec -fPIC). env['STATIC_AND_SHARED_OBJECTS_ARE_THE_SAME']=1 désactive cette case. Vous devez décider vous-même si c'est effectivement une bonne idée...

OriginalL'auteur Liang Wul
1

Ce problème n'est pas spécifique à scons. Pour construire une bibliothèque partagée, vous aurez besoin des objets qui sont compilés avec le code indépendant de la position (-fPIC). Votre meilleur pari est de faire de la bibliothèque partagée à partir des fichiers sources compilé avec les bonnes options.

Dans SCons, vous pouvez définir une liste d'objectifs qui est utilisé pour construire à la fois libMine.un et libShared..

Mise à jour: pour votre deuxième question, la SharedLibrary constructeur pourrait faire ce que vous avez besoin de:
```
SharedLibrary('foo', ['f1.c', 'f2.c', 'f3.c'])
```
Si pas, LINKFLAGS définit les indicateurs transmis à un lien de commande.

Je pense que vous avez raison que le .un a de .o fichiers qui ne sont PAS réalisés à l'aide de -fPIC. Cependant, le g++ -m32 -partagé .... fonctionne encore en quelque sorte.
Je suis retourné et avait les fichiers dans le .un être compilé avec-fPIC, mais cela ne semble pas aider.
Le LINKFLAGS a été utile. thx.

OriginalL'auteur Dave Bacher
0

J'ai le même problème sous cygwin. J'ai passé '-fPIC " options de gcc lors de la construction des objets et a obtenu le message d'avertissement suivant:

avertissement: -fPIC ignoré pour cible (tout le code est indépendant de la position)

Moi aussi j'ai passé de "partagés" à la commande de liaison. Et j'ai finalement obtenu l'erreur

"***.lib est statique et n'est pas compatible avec la cible commune: myso.dll"

Il semble scons ne permet pas de créer directement à partir obj ou fichiers lib, et on peut créer à partir d'une liste de fichiers sources (à l'aide de SharedLibrary()) ou un fichier source + 'LIBS' option comme dummytaurus dit. Je suis curieux à propos de ça.

OriginalL'auteur NovelX
0
```
env_2.SharedLibrary('libstuff.so', Split("""stuff.cxx"""), LIBS='libMine.a', LIBPATH='mylib')
```
Cela devrait fonctionner.

Cela fonctionne, mais ne crée pas de dépendance à libMine.a
Oui, c'est fait. Le SharedLibrary builder utilise ProgramScanner à la recherche pour les dépendances spécifiées via LIBS.

OriginalL'auteur
0

Le problème est dans la fonction SharedFlagChecker (Default.py), qui vérifie que pour un interne "partagé" pavillon. Le SCons documentation mène à croire qu'il maintient la distinction entre les objets partagés et les objets statiques via le suffixe (SHOBJSUFFIX), mais n'est pas. La solution est facile. Dans le fichier scons-local.../SCons/Default.py trouver le SharedFlagCheckeret edit:
```
def SharedFlagChecker(source, target, env):
    same = env.subst('$STATIC_AND_SHARED_OBJECTS_ARE_THE_SAME')
    if same == '0' or same == '' or same == 'False':
        for src in source:
            try:
                shared = src.attributes.shared
            except AttributeError:
                # Replace this line: shared = None
                shared = env.Dictionary()['SHOBJSUFFIX'] == src.suffix
            if not shared:
                raise SCons.Errors.UserError("Source file: ...") 
```
Maintenant des objets fabriqués par les SharedObject constructeur pourront être couplés dans une bibliothèque partagée.

Vous devez utiliser env['STATIC_AND_SHARED_OBJECTS_ARE_THE_SAME']=Vrai et pas pirater le code pour désactiver cette.. C'est dans la page du manuel.

OriginalL'auteur M. A. Moshier

La solution pour résoudre ce problème ont été utilisés un 'SharedObject' comme suit:

ASN1CObjectFile = envCProcesses.SharedObject(target = "OTCMsg.os",
                                             source = "OTCMsg.c",
                                             CFLAGS = envCProcesses["CFLAGS"] + ["-Wno-unused"])

et:

OTCLibSharedLibrary = envCProcesses.SharedLibrary(env["OTC_LIBPATH"] + "/libOTCLib" + env["SHLIBSUFFIX"],
                                              ASN1CObjectFile +
                                              [ASN1AllocatorSource,
                                               "OTCLib.c"],
                                              LIBPREFIX = "")

Cordialement,

env["OTC_LIBPATH"] + "/libOTCLib" + env["SHLIBSUFFIX"] peut être réécrite comme "${OTC_LIBPATH}/libOTCLib$SHLIBSUFFIX"

OriginalL'auteur L-Sebastien

Vous devez vous connecter pour publier un commentaire.