Mam plik biblioteki statycznej o nazwie libunp.a, Wiem, że mogę użyć gcc -lunp xx do połączenia z biblioteką.#pragma komentarz (lib, "xxx.lib") odpowiednik pod Linuksem?
Mogę użyć #pragma comment(lib,"xxx.lib"), aby powiedzieć kompilatorowi Microsoft C/C++, aby dołączyć bibliotekę; jak mogłem to zrobić pod Linuksem/GCC?
Prosta; nie możesz. GCC nie ma takiego odpowiednika. Podaj -l jako parametr gcc, stwórz skrypt linkera, zadzwoń pod numer ld, zadzwoń pod numer 911 lub cokolwiek innego.
Nie, że taka pragma ma nawet sens. Biblioteki powinny być określone podczas etapu łączenia. Takie informacje po prostu nie należą do jednostki tłumaczeniowej. Jednostka tłumaczeniowa może być wstępnie przetworzona, skompilowana i złożona nawet bez etapu łączenia. Łańcuch narzędzi używany przez Visual Studio pozwala na to, ponieważ jest to braindead i wykonuje łączenie.
Może chcesz zaoszczędzić sobie trochę żmudne wpisywanie i stworzyć Makefile dla danego projektu: GNU Make Manual
Nie ma żadnej wzmianki o równoważnym pragmie w GCC manual's page on pragmas.
Jednym z powodów, dla których widziałem, że GCC nie obsługuje łączenia w kodzie źródłowym, było to, że czasami, correct linking depends on link order; a to wymagałoby upewnienia się, że kolejność linków odbywa się poprawnie bez względu na kolejność kompilacji. Jeśli masz zamiar pójść na tak dużo pracy, równie dobrze możesz po prostu przekazać argumenty linkera w wierszu poleceń (lub inaczej), jak przypuszczam.
To samo dotyczy niektórych, jeśli nie wszystkich kompilatorów systemu Windows. Ale tak, takie pragmy są __bad__ –
"poprawna kompilacja zależy od kolejności linków." - Nie, jak wskazuje powiązany artykuł, prawidłowe LINKING zależy od kolejności linków. –
Biblioteki powinny być określone na etapie łączenia. Takie informacje po prostu nie należą do jednostki tłumaczeniowej. Jednostka tłumaczeniowa może być wstępnie przetworzona, skompilowana i złożona nawet bez etapu łączenia.
Po prostu dlatego, że #pragma comment(lib,"xxx.lib") znajduje się w pliku źródłowym, nie oznacza, że kompilator je zużywa. W rzeczywistości jest to komentarz, który jest następnie używany przez linker. Nie różni się niczym od * nix.
Nie masz do końca racji, istnieją pewne przypadki, takie jak użycie ROOT (root.cern.ch), gdzie może to być bardzo pomocne. – RSFalcon7
W ciągu ostatnich dziesięcioleci programiści zaczęli tworzyć pliki .h i pliki .lib, aby mieć ze sobą jakiś związek. W takim przypadku TO ma sens, aby plik .h zawierał pragmę informującą linker o powiązaniu odpowiedniego pliku .lib. Oczywiście, że gcc go nie ma, ale to nie znaczy, że nie ma sensu. –
Następnie zakładasz, że biblioteki nie wymagają żadnych dodatkowych ścieżek ani flag podczas łączenia. Dotyczy to głównie Windows, dlatego też pragma "działa" w środowisku Visual Studio. Inne pragma gcc są co najmniej jednolite w różnych wersjach systemu Linux/Solaris/BSD, o ile korzystasz z tej samej wersji gcc. Ścieżki jednak nie są. Dlatego całkowicie uzasadnione jest oddzielenie etapu budowy w skryptach konfiguracyjnych lub plikach Makefile. Nie ma nic wspólnego z jednostkami tłumaczeniowymi. Spróbuj czasami przesłać oprogramowanie ;-) –
@Mads: Fakt, że Unix jest platformą, która wymaga złamania, która wymaga oddzielenia faz budowania i łączenia, oraz cały związany z tym ból, nie jest uzasadnieniem dla niszczenia sposobu, w jaki robi to Windows, co jest łatwiejsze w obsłudze i pozwala realizatorom bibliotek na usunięcie tego bólu z ich użytkowników. Idea, że podejście Unix jest trudniejsze, ale lepsze, to czysty, irracjonalny masochizm. –