Frage

Ich wurde gerade (ziemlich kaum) von einer nicht trivialen Warnung von Visual Studio 2010 (C ++) auf dem Kopf geschlagen.

Die Zusammenstellung ergab die folgende Ausgabe:

1 debug is.obj: Warnung LNK4042: Objekt mehr als einmal angegeben; Extras ignoriert
1 Debugug make.obj: Warnung LNK4042: Objekt mehr als einmal angegeben; Extras ignoriert
1 debug view.obj: Warnung LNK4042: Objekt mehr als einmal angegeben; Extras ignoriert
1 Identität.OBJ: Fehler LNK2019: ungelöstes externes Symbol void __cdecl test::identity::view(void) (?@identity@test @@ Yaxxz) in der Funktion verwiesen void __cdecl test::identity::identity(void) (? Identität@0test @@ Yaxxz)
1 Identität.OBJ: Fehler LNK2019: ungelöstes externes Symbol void __cdecl test::identity::make(void) (? Machen Sie@identity@test @@ yaxxz) auf die Funktion verwiesen void __cdecl test::identity::identity(void) (? Identität@0test @@ Yaxxz)
1 Bereich.obj: Fehler LNK2019: ungelöstes externes Symbol void __cdecl test::range::is(void) (? Wird@range@test @@ yaxxz) in der Funktion verwiesen void __cdecl test::range::range(void) (? Bereich@0test @@ Yaxxz)

Linkerfehler sind immer ein Schmerz für das Debuggen ... aber es gab ungelöste Referenzen, und so habe ich überprüft ... aber die Quelle ist gut geformt ... und schließlich traf es mich:

Meine Ordnerhierarchie sieht so aus:

src/
  identity/
    is.cpp
    make.cpp
    view.cpp
  range/
    is.cpp
    make.cpp
    view.cpp

Und die Hierarchie in der Lösung (ich habe sie immer so eingerichtet, dass sie die "echte" Ordnerstruktur nachahmt).

Und die diagnostischen Ausgänge:

Debug\is.obj
Debug\make.obj
Debug\view.obj

Zusammen mit einer Warnung, die sagt, dass die .obj wurde zweimal an den Linker übergeben und dieser wird ignoriert.

Suchen Sie nicht mehr: Visual hat meine Ordnerhierarchie ordentlich abgeflacht und kann die Quelle daher nicht ordentlich kompilieren.

Im Moment denke ich einfach daran, die Dateien umzubenennen, die das Problem behandeln sollten ...

... aber gibt es eine Möglichkeit, dass Visual Studio die Dateihierarchie nicht verflacht hat?

War es hilfreich?

Lösung

Ich wollte nur posten, was ich für die Antwort bin, wenn Sie die Eigenschaften für das gesamte Projekt öffnen, und die Änderung des Werts unter C/C++ -> Output Files -> "Object File Name" Folgendes sein:

$ (Intdir)/%(wiedererlangt)/

Nach VS 2010 wird dies glaube, dass dies alle Objektdateien (wie ich glaube, dass Windows Sie unter verrückten Umständen nicht zulässt, zwei Dateien mit den gleichen Namen im selben Verzeichnis haben). Bitte sehen Sie sich auch die Details an hier.

Andere Tipps

Ich hatte ein ähnliches Problem mit der Linker -Warnung LNK4042: Objekt mehr als einmal angegeben; Extras ignoriert. In meinem Fall versuchte Visual Studio, sowohl Header- als auch Quelldateien mit demselben Namen zu kompilieren - MyClass.h und MyClass.cpp. Es ist passiert, weil ich umbenannt habe .cpp Datei an .h Und Visual Studio wurde verwirrt. Ich bemerkte das Problem, indem ich mir die Compiler -Protokolle in der ansah Debug Verzeichnis. Um zu lösen, entfernen Sie einfach .h Datei aus dem Projekt fügen Sie es erneut hinzu.

Klicken Sie mit der rechten Maustaste auf die .CPP-Datei im Fenster Lösungsexplorer, Eigenschaften, C/C ++, Ausgabedateien und Einstellung von Objektdateinamen. Der Standard ist $(IntDir)\, Das ist es, was die Abflachung macht. Alle .OBJ -Datei werden in $ (intdir), das "Debug" -Verzeichnis in der Debug -Konfiguration, übernommen.

Sie können die Einstellung ändern, beispielsweise $(IntDir)\is2.obj. Oder wählen Sie alle Dateien aus einer Gruppe aus (verwenden Sie SHIFT+Klick) und ändern Sie die Einstellung auf beispielsweise. $(IntDir)\identity\

Oder Sie können den .CPP -Dateinamen so ändern, dass .OBJ -Dateien sich nicht gegenseitig überschreiben. Es ist etwas seltsam, Dateien mit dem gleichen Namen in zwei Verzeichnissen zu haben.

Oder Sie können mehrere Projekte erstellen und beispielsweise Projekte für die Dateien in Identität und Reichweite erstellen. Zum Beispiel in Makefile -Projekten häufig durchgeführt. Dies macht jedoch das Verwalten der Kompilier- und Verknüpfungseinstellungen eher zu einem Ärger, es sei denn, Sie verwenden Projekteigenschaften.

Klicken Sie mit der rechten Maustaste auf Header -Datei -> Eigenschaft -> itemType (wählen Sie C/C ++ -Header). Machen Sie dasselbe mit CPP -Datei, wählen Sie aber C/C ++ - Compiler (es ist Arbeit für mich)

Ich verwende $ (intdir) %(Verzeichnis) unter C/C ++ -> Ausgabedateien -> "Objektdateiname".

Ich hatte dieses Problem mit stdafx.cpp. Irgendwie wurde stdafx.cpp dupliziert, sodass es einen zweiten stdafx.cpp gab (der den anderen Fall ist).

Nachdem ich das stdafx.cpp entfernt hatte, hat alles gut funktioniert!

Verwenden von VS 2010.

Alternativ zum Löschen und Erstellen einer neuen Datei können Sie die Einstellungen kompilieren/einfügen.

Gehen Sie zu Ihrem project.vcxproj Datei, öffnen Sie es mit einem Editor, suchen Sie die HTML -ähnliche Zeile <ItemGroup>.

Es sollte ungefähr aussehen wie:

<ItemGroup>
<ClCompile Include="implementation.cpp" />
</ItemGroup>

und

<ItemGroup>
<ClInclude Include="declaration.hpp" />
</ItemGroup>`

Unter der Annahme, dass Ihre Implementierungsdateien .CPP und Ihre Erklärungen .HPP sind. Stellen Sie sicher, dass alle Ihre Implementierungsdateien zwischen dem ersten Abschnitt aufgeführt sind, wenn Sie mehr als einen und ebenfalls für den zweiten Abschnitt für mehrere Deklarationsdateien haben.

Ich hatte früher im selben Projekt .c und .Cpp Dateien mit die gleichen Dateinamen. Die Dateien befanden sich überall in Ordnern und die von anderen bereitgestellten Lösungen erzeugten ein Chaos und Ordnerhölle (in meinem Fall). Eben Veröffentlichung Builds würden überschreiben Debuggen baut!

Eine gute (nicht perfekte) Lösung wäre, $ (ParentName) zu verwenden, aber aus irgendeinem Grund wurde sie über das Verständnis von späteren Versionen von Visual Studio (2015+) entfernt.

Was ich jetzt erfolgreich verwende, ist: $ (intdir)%(Dateiname)%(Erweiterung) .OBJ

was zumindest trennt .c Erstellte Objektdateien von .Cpp.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top