Hallo zusammen.
Ich wollte meine main.cpp mit Clang kompilieren, kriegte aber dieses:
clang-14: error: no such file or directory: 'libuser32.a'
clang-14: error: no such file or directory: 'libgdi32.a'
clang-14: error: no such file or directory: 'libadvapi32.a'
etc.
habe ich in der BAT gelinkt:
-L libkernel32.a libuser32.a libgdi32.a
etc.
Braucht er einen Pfad für die Libs, oder was kann ich da machen?
lG
MartinX
Also Martin, ich kann es dir auch nicht lösen aber vielleicht als erste Hilfestellung:
Der Linker meckert ja, dass er die 3 Dateien nicht findet.
Was sind .a Dateien? Und was soll der Linker damit tun? Sind das Objektdateien?
Ich kenne .o oder .lib … - aber .a hab ich noch nicht gehört.
(Bin aber auch vllt. nicht mehr ganz upToDate - falls du das mit .a so gezielt brauchst.)
Du musst ihn besser „führen“, dass er die Dateien findet. Oder die Dateien an andere Stellen verschieben, dass er sie findet.
Ich habe den Pfad im Ordner von Clang gesucht, auch einen Ordner „lib“ gefunden, die üblichen Verdächtigen sind aber dort nicht drin.
Ich kapier das nicht; habe ich doch bei MinGW immer so gemacht.
Die drei genannten sind nur Beispiele, es sind 17 lib*.a insgesamt.
Dann müsste ja ER wissen, wo er seine Libs begraben hat…
Sowas wie .o oder „Routine X“ habe ich nicht.
Ich habe jetzt dieses:
... -L /mnt/c/Windows/ -lkernel32.a etc.
Das geht genauso wenig. Ich geb es auf :-(.
lG Martin
PS: wer das nicht kennt: um bei Clang oder MinGW zu linken, ist dies die richtige Schreibweise:
libwinmm.a
bei MS kriegt man dieselbe mit:
winmm.lib
es muß -lkernel2 heißen, ohne die Endung. Der Linker nimmt dann wahlweise libkernel32.dll für dynamisches Linken oder libkernel32.a, falls statisches Linken gewünscht ist.
Das glaube ich nicht. Es sind zwar Linker-Profile eingebaut, aber die beziehen sich auf libc und libstdc++, oder (via -lm) libmath, etc.
clang-14: error: no such file or directory: 'c++'
clang-14: error: no such file or directory: 'libkernel32'
clang-14: error: no such file or directory: 'libuser32'
usw.
Die Götter wollen wohl nicht, dass ich das mache :-).
Danke schön für eure Hilfe.
Martin
Das -std=c++ hat er auch nicht wollen, da habe ich es entfernt. Die Rückgabe sieht jetzt um einiges besser aus:
main.cpp:18:2: error: no matching function for call to 'SetConsoleTitleA'
SetConsoleTitle((LPCWSTR) "Hello! two threads alternating:\n");
^~~~~~~~~~~~~~~
C:/upp-win-16660/upp/bin/clang/include/wincon.h:205:25: note: expanded from macro 'SetConsoleTitle'
#define SetConsoleTitle __MINGW_NAME_AW(SetConsoleTitle)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:/upp-win-16660/upp/bin/clang/include/_mingw_unicode.h:20:32: note: expanded from macro '__MINGW_NAME_AW'
# define __MINGW_NAME_AW(func) func##A
^~~~~~~
<scratch space>:147:1: note: expanded from here
SetConsoleTitleA
^~~~~~~~~~~~~~~~
C:/upp-win-16660/upp/bin/clang/include/wincon.h:263:29: note: candidate function not viable: no known conversion from 'LPCWSTR' (aka 'const wchar_t *') to 'LPCSTR' (aka 'const char *') for 1st argument
WINBASEAPI WINBOOL WINAPI SetConsoleTitleA(LPCSTR lpConsoleTitle);
^
1 error generated.
Jetzt komme ich langsam in den grünen Bereich :-).
Damit komme ich nun eher zurecht. Das SetConsoleTitle() hat er sonst immer genommen.
Danke für die Hilfe.
Das SetConsoleTitle() nimmt er jetzt, klasse. kriege jetzt:
lld: error: unable to find library -lkernel32-luser32
lld: error: unable to find library -lglaux
clang-14: error: linker command failed with exit code 1 (use -v to see invocation)
Dann diese Libs entfernt und die anderen nimmt er jetzt. Dafür kriege ich anderen Murks (was ja wohl auch eine Linker-Geschichte ist, Bsp.):
ld.lld: error: undefined symbol: operator new[](unsigned long long)
>>> referenced by C:/Users/HASSOB~1/AppData/Local/Temp/main-b378cd.o:(toLog(char const*, int const*, int))
>>> referenced by C:/Users/HASSOB~1/AppData/Local/Temp/main-b378cd.o:(toLog(char const*, double const*, int))
>>> referenced by C:/Users/HASSOB~1/AppData/Local/Temp/main-b378cd.o:(Clipboard::getText())
>>> referenced 4 more times