2017-12-27 16 views
-1

Ich arbeite an einer statischen C-Bibliothek, die irgendwann Open Source sein wird, also kompiliere ich unter Windows und Ubuntu, um Portabilitätsprobleme zu vermeiden.Symbole, die in der statischen Linux-Bibliothek mit NetBeans fehlen

Das Problem, das ich habe, ist, dass die Symbole aus einer der Objektdateien aus dem Linux-Build weggelassen werden. Wenn ich die Bibliothek mit VS2015 unter Windows baue, sind alle Symbole vorhanden.

Ich bin meistens gewohnt, für Windows zu entwickeln, also bin ich ziemlich verwöhnt, eine IDE für die meisten Build-Szenarien zu verwenden. Unter Ubuntu verwende ich NetBeans, und ich bin mir nicht sicher, ob das Problem mit meinem Verständnis von gcc zusammenhängt oder ob ich NetBeans nicht korrekt eingerichtet habe.

Einzelheiten

Ubuntu 16.04LTS mit gcc (Ubuntu) 5.4.0

NetBeans IDE 8.1 C/C++

Die Bibliothek besteht aus drei Quelldateien und 2-Header-Dateien:

queue.c --> queue implementation 
memutil.c --> memory utilities 
mylib.c --> main library implementation 

queue.h --> included by queue.c and mylib.c 
mylib.h --> header file for the static library 

Die mylib.h Kopfzeile enthält die Kopfzeileninformationen für die memutil.c-Quelldatei, eingepackt in eine Bedingung, die von dem MEMCHECK Symbol in der Befehlszeile abhängt. Ebenso für den Code in der memutil.c Quelldatei. Das MEMCHECK Symbol wird beim Erstellen der Bibliothek definiert, aber wenn ich nach dem Linux-Build nm auf libmylib.a ausführen, werden keine Symbole für die memutil.o Objektdatei aufgeführt. Wenn ich mir die Datei mylib.lib unter Windows anschaue, sind alle Symbole für memutil.obj aufgeführt.

Jetzt, wenn ich eine ausgestempelte Quelldatei hinzufügen, die nur die mylib.h Header enthält, sind alle Symbole in der libmylib.a Bibliothek vorhanden. Ich vermute, es gibt eine Fehlfunktion bei der Header-Datei-Interaktion, aber ich suche nicht nach dem, was es ist oder wie ich es beheben kann. Ich habe das mit so vielen verschiedenen Phrasen, die ich mir vorstellen kann, rausgerissen, aber keine Freude.

Hier ist die NetBeans Ausgang bauen, weniger alle das Verzeichnis Lärm:

gcc -c -g -Wall -DMEMCHECK -MMD -MP -MF "build/queue.o.d" -o build/queue.o queue.c 
gcc -c -g -Wall -DMEMCHECK -MMD -MP -MF "build/memutil.o.d" -o build/memutil.o memutil.c 
gcc -c -g -Wall -DMEMCHECK -MMD -MP -MF "build/mylib.o.d" -o build/mylib.o mylib.c 

ar -rv dist/Debug/GNU-Linux/libmylib.a build/queue.o build/memutil.o build/mylib.o 
ar: creating dist/Debug/GNU-Linux/libmylib.a 
a - build/queue.o 
a - build/memutil.o 
a - build/mylib.o 
ranlib dist/Debug/GNU-Linux/libmylib.a 

BUILD SUCCESSFUL (total time: 3s) 

Stubbing in die Aufnahme-Header-Datei nicht die Lösung für dieses sein kann, kann es? Es funktioniert, aber es scheint schrecklich roh. Außerdem kann ich nicht wirklich anerkennen, dass es mit gcc und nicht notwendig mit VS2015 notwendig wäre.

+1

Es kann ein wenig haarig werden, aber Sie könnten in Betracht ziehen, mit der Option "-E" zu kompilieren. Dies zeigt den Quellcode nach dem Ausführen des Präprozessors. Sie sollten also sehen können, ob "DMEMCHECK" das tut, was Sie tun sollten. Ihr Code wird gegen Ende der '# include's sein. Sie können die Ausgabe in eine Datei umleiten. 'Gcc -E code.c> ppCode.c' https://stackoverflow.com/questions/3742822/preprocessor-output – yano

+0

empfiehlt außerdem, das Kompilieren mit dem' -Wextra'-Flag zu aktivieren mehr Warnungen. – yano

+0

@yano: Es scheint mir, dass, wenn es ein Problem mit der Bedingung gab, der Windows-Build auch wackelig wäre. –

Antwort

0

Nun, ich fand die Lösung, aber ich markiere dies nicht als die akzeptierte Antwort, weil ich nicht genau bin warum es ist die Lösung.

Ich bemerkte die -Mxx Flaggen auf den Compiler-Linien:

gcc -c -g -Wall -DMEMCHECK -MMD -MP -MF "build/... 

Also ging ich zu Google zurück und fand diese Seite: Auto-Dependency Generation, die Make behandeln die Erzeugung und Verfolgung von Bauabhängigkeiten deckt haben.

Dann starte ich in NetBeans durch jeden einzelnen Menüpunkt Kämme, bis ich diese gefunden:

Tools-> Optionen-> C/C++ -> [on/off] Abhängigkeit in generierten Makefiles Überprüfung aktiviert

Ich löschte diesen Schalter, und alle fehlenden Symbole erschienen in der Bibliothek. Die -Mxx Flags waren jedoch weiterhin in den Compiler-Zeilen in der Build-Ausgabe vorhanden. Die Makefile-Generierung für NetBeans verwendet nun ungefähr 5 separate Makefile-Vorlagen und 3 oder 4 verschiedene XML-Konfigurationsdateien, um das Makefile zur Build-Zeit basierend auf der Build-Konfiguration und dem Ziel zu generieren. Ich konnte nicht herausfinden, ob die Auto-Abhängigkeits-Flags inaktiv gemacht wurden, indem ich den Schalter umlegte oder nicht.

Aber, wenn ich die Informationen auf der oben genannten Website richtig lese, werden diese -Mxx Flags tatsächlich von GCC zur Unterstützung von Make verwendet, so dass ich nicht sicher bin, wie sie eine andere Interpretation basierend auf etwas hätten das hat NetBeans getan. Es gibt zwar eine Menge Substitutionen in diesen Makefile-Vorlagen, und da ich kein Autokonfig/Make-Assistent bin, habe ich es vielleicht einfach verpasst.

Offensichtlich, da keine der Quelldateien tatsächlich die Funktionsprototypen für die Speicherdienstprogramme enthielt - weil sie in der Bibliotheksheaderdatei enthalten sind, die keine der Bibliotheksquelldateien enthält (sie ist für die Aufnahme durch den Client gedacht) Code) - die NetBeans-Abhängigkeitsprüfung hat entschieden, dass diese Funktionen in der Bibliothek nicht benötigt werden.

Verwandte Themen