Wie kann ich eine statische Bibliothek kompilieren

Ich versuche zu kompilieren einer statischen Bibliothek. Ich folgte den Schritten, die gegeben wurden, in einer Antwort auf diese Frage aber es funktioniert nicht. Folgendes ist mein makefile.

PROJECT = lq.a
OBJECTS = dlmalloc.o queue.o.o
CFLAGS  = -o -Wall -pedantic

all: $(PROJECT)

.c.o:
    gcc -c $(CFLAGS) $<

$(PROJECT): $(OBJECTS)
    libtool -o  $(PROJECT) -static $(OBJECTS)

Und ich bekomme die folgende Fehlermeldung.

libtool: unrecognized option `-o'

Was ist die richtige Art und Weise des Schreibens dieses Makefiles?

InformationsquelleAutor pythonic | 2012-07-05
  1. 8

    Können Sie das Programm ar zum erstellen von statischen Bibliotheken mit der folgenden syntax:

     ar rcs my_library.a file1.o file2.o

    So, in Ihrem Fall:

    $(PROJECT): $(OBJECTS)
     ar rcs $(PROJECT) $(OBJECTS)

    Finden Sie eine Erläuterung der Optionen auf der Mann Seite, aber im Grunde:

    • r sagt legen Sie die Objekt-Dateien in das Archiv (ersetzt alle älteren Versionen der gleichen Sache)
    • c sagt, das Archiv, wenn es nicht bereits vorhanden ist (normalerweise geschieht dies sowieso, aber diese option unterdrückt die Warnung).
    • s sagt zum schreiben eines Objekt-index-Datei in dem Archiv.
    InformationsquelleAutor Timothy Jones
  2. 3

    Entweder libtool oder nicht. Wenn du gehst, es zu benutzen, dann sollten Sie kompilieren Sie die einzelnen Dateien mit libtool --mode=compile sowie die Verknüpfung mit libtool --mode=link. Wenn du nicht gehst, zu verwenden libtool, dann wird Ihr link sollte getan werden, mit gcc auch, wie schon in einer anderen Antwort. Auch haben Sie versucht man libtool?

    • Ich habe versucht man libtool, und es ist nicht offensichtlich, warum sollte -o eine nicht erkannte option auf Linux, aber mit der richtigen Reihenfolge der Argumente, es kann erkannt werden (siehe meine Antwort hier).
    • libtool akzeptiert keine option -o, so ist es eine "nicht erkannte option". Sobald Sie geben Sie eine --mode=<something> option zu sagen libtool was zu tun ist, dann weitere Optionen können übergeben werden an die Werkzeuge libtool ruft. So libtool --mode=link -o something vielleicht ok sein, aber libtool -o something ist nicht. Entweder Weg, verwenden Sie entweder libtool für den compile-und link-Stadien, oder nicht verwenden, es überhaupt nicht - Sie sind nur zu Fragen für die Verwirrung mit gcc zu kompilieren, aber libtool link.
    InformationsquelleAutor twalberg
  3. 2

    Die folgenden Befehle erstellen die statische Bibliothek:

    $gcc -c file1.c -o libfile.o
$ar rcs libfile.a libfile.o
    InformationsquelleAutor Aftnix
  4. 2

    Gut, das ist verwirrend, aber ich denke, dass die libtool -o $(PROJECT) -static $(OBJECTS) line (auch erwähnt in objective-c - Kombinieren statische Bibliotheken) kommt vom Mac, und anscheinend die libtool es ist NICHT die gleiche wie unter Linux:

    libtool oder ar & ranlib - idevgames Foren:

    War ich mit libtool zum erstellen einer statischen Bibliothek auf OS X, weil das ist, was mit Xcode zu tun war, das scheint gut zu funktionieren. Dann gehe ich über Linux und es drosseln auf meine libtool-Befehl sagen, "libtool: unrecognized option '-o'". Betrachten Sie, wie es scheint, libtool auf OS X und libtool auf Linux sind zwei völlig verschiedene Programme. ...

    Nachtrag: ja, es scheint, dass libtool auf Linux ist in der Tat glibtool auf OS X. ich bekomme im wesentlichen die gleiche Ausgabe, wenn dabei "glibtool --help" auf OS X als "libtool --help" auf Linux.

    Ok, das erklärt den Unterschied - aber immer noch nicht erklären, wie -o kann eine nicht erkannte option, wenn ich habe gerade gesehen, das es aus einem Makefile auf Linux! So fand ich dies:

    bug-libtool-mailing-Liste (2001): Re: bug in libtool?

    Müssen Sie stellen Sie den Modus ein, bevor Sie den Modus-Optionen:

    $ libtool --mode=link --help

    Verwendung: libtool [OPTION]... --mode=link LINK-BEFEHL...

    Oh je... nun, was macht es besonders verwirrend, ist dieser Hinweis in libtool --mode=link --help:

    $ libtool --mode=link --help
Usage: libtool [OPTION]... --mode=link LINK-COMMAND...
...

LINK-COMMAND is a command using the C compiler that you would use to create
a program from several object files.

The following components of LINK-COMMAND are treated specially: ...
  -all-static       do not do any dynamic linking at all ...
  -o OUTPUT-FILE    create OUTPUT-FILE from the specified objects ...
  -static           do not do any dynamic linking of uninstalled libtool libraries
...
All other options (arguments beginning with `-') are ignored.

Every other argument is treated as a filename.  Files ending in `.la' are
treated as uninstalled libtool libraries, other files are standard or library
object files.
...
If OUTPUT-FILE ends in `.a' or `.lib', then a standard library is created
using `ar' and `ranlib', or on Windows using `lib'.

    So, wenn ich haben angeben LINK-COMMAND - und zur gleichen Zeit, ich geben Sie ein OUTPUT-FILE endet in .a; der Befehl sollte dann laufen, LINK-COMMAND - oder die ar+ranlib dass die Verlängerung .a gibt? Nun - hier ist ein terminal-snippet, nur testen das bash Skript Logik der libtool - ohne jede Zusammenstellung (obwohl eine leere Archiv wird erstellt):

    $ libtool -o test.a
libtool: unrecognized option `-o'
libtool: Try `libtool --help' for more information.

$ libtool --mode=link -o test.a
libtool: link: unrecognized option `-o'
libtool: link: Try `libtool --help' for more information.

$ libtool --mode=link gcc -o test.a
libtool: link: ar cru test.a
libtool: link: ranlib test.a

$ libtool --mode=link ar -o test.a
libtool: link: unable to infer tagged configuration
libtool: link: specify a tag with `--tag'

$ cat $(which libtool) | grep "^# ### BEGIN LIBTOOL TAG CONFIG:"
# ### BEGIN LIBTOOL TAG CONFIG: disable-shared
# ### BEGIN LIBTOOL TAG CONFIG: disable-static
# ### BEGIN LIBTOOL TAG CONFIG: CXX
# ### BEGIN LIBTOOL TAG CONFIG: F77
# ### BEGIN LIBTOOL TAG CONFIG: FC
# ### BEGIN LIBTOOL TAG CONFIG: GCJ
# ### BEGIN LIBTOOL TAG CONFIG: RC
# ### BEGIN LIBTOOL TAG CONFIG: BINCC
# ### BEGIN LIBTOOL TAG CONFIG: BINCXX

## CC tag is not listed, but it will (eventually) be accepted:

$ libtool --mode=link ar --tag CC -o test.a
libtool: link: unable to infer tagged configuration
libtool: link: specify a tag with `--tag'

$ libtool --mode=link --tag CC ar -o test.a
libtool: link: ar cru test.a
libtool: link: ranlib test.a

$ libtool --tag=CC --mode=link ar -o test.a
libtool: link: ar cru test.a
libtool: link: ranlib test.a

$ libtool --tag=XX --mode=link ar -o test.a
libtool: ignoring unknown tag XX
libtool: link: ar cru test.a
libtool: link: ranlib test.a

$ libtool --tag=XX --mode=link whatevar -o test.a
libtool: ignoring unknown tag XX
libtool: link: ar cru test.a 
libtool: link: ranlib test.a

$ ls -la test.a 
-rw-r--r-- 1 user user 8 2013-04-17 23:12 test.a

    Also - nicht nur, dass Sie angeben müssen --mode, aber wenn dieser Modus link, MÜSSEN Sie irgendeine Art von argument (LINK-KOMMANDO) bezogen auf ein Werkzeug; ABER das LINK-KOMMANDO argument braucht nicht einmal zu existieren als real Programm - da müssen Sie geben Sie eine Ausgabe-Datei ohnehin; und wenn die Ausgabe-Datei endet auf .a es erzwingt die Verwendung von ar/ranlib sowieso.

    Außerdem sollten Sie ein problem haben mit einem tag - bewegen Sie einfach die --tag argument vor dem LINK-BEFEHL - argument-und Sie können Kraft libtool zu laufen, mit einem nicht vorhandenen tag und einen nicht vorhandenen LINK-BEFEHL (wo es den Betrieb angegeben wird allein durch die Erweiterung .a von der Ausgabe-Datei) - solange die Argumente sind eingetragen in der richtigen Reihenfolge für die libtool syntax; das muss ich zugeben, ist nicht wirklich dokumentiert, die in das Skript selbst.

    Aber wieder zu kommen, um die Mac - libtool -o $(PROJECT) -static $(OBJECTS) Linie, die kombinieren statische Bibliotheken; wenn Sie versuchen, das gleiche zu tun mit der richtigen statischen Bibliothek .a Dateien, werden Sie feststellen, dass libtool schiebt die .a Archive als solche in der Ausgabe Archiv nicht Ihre Bestandteile Objekt-Dateien - also diese Ausgabe ist keine gültige ELF-Objekt mehr; hier ist ein Beispiel für eine entsprechende Linux - libtool Linie, mit zwei richtigen library-Dateien, die ich erzeugt haben:

    $ readelf --syms libmy1.a
File: libmy1.a(my1.o)
Symbol table '.symtab' contains 11 entries:
...
$ readelf --syms libmy2.a
File: libmy2.a(my2.o)
Symbol table '.symtab' contains 12 entries:
...
$ libtool --mode=link --tag=CC ar -o libtest.a -static libmy1.a libmy2.a 
libtool: link: ar cru libtest.a libmy1.a libmy2.a 
libtool: link: ranlib libtest.a

$ readelf --syms libtest.a
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
readelf: Error: libtest.a(libmy1.a): Failed to read file header
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
readelf: Error: libtest.a(libmy2.a): Failed to read file header

    So, als akzeptierte Antwort sagt - auf Linux, verwenden Sie ar manuell zu entpacken und pack wieder zu kombinieren statische Bibliotheken.

    Hoffe, dies hilft jemand,

    Prost!

    InformationsquelleAutor sdaau
Schreibe einen Kommentar