Błąd linkowania do msvcprtd.lib

Po konwersji z VS2003 na VS2008 projekt przestał działać. Dziś chciałabym się skupić na błędzie:

error LNK2005: "public: __thiscall std::basic_string<unsigned short,struct std::char_traits<unsigned short="short">,class std::allocator<unsigned short="short"> >::basic_string<unsigned short,struct std::char_traits<unsigned short="short">,class std::allocator<unsigned short="short"> >(unsigned short const *)" (??0?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@QAE@PBG@Z) already defined in EPICDLL.obj

W kolumnie File mam podane, że problem dotyczy msvcprtd.lib

Przybliżmy trochę, jak wygląda solucja. Mamy trzy projekty, każdy z ma Runtime Library: Multi-threaded Debug DLL. Projekt, na którym wywala błąd, jest kompilowany jako drugi.

Gdy sobie kombinowałam z przeróżnymi ustawieniami, doszłam do sytuacji, w której projekt kompilował się jako Multi-treaded Debug - ale nie jest to dobre rozwiązanie, gdyż tutaj akurat potrzebujemy uzyskać DLL.
I tutaj mam pytanie z ciekawości wynikające - czy to normalne, że mimo iż ustawiłam /MTd wciąz powstawały pliki dll...? Czy nie powinny wtedy powstać pliki lib...?

Znalazłam taką informację, że VS2003 dopisuje RuntimeLibrary również do konkretnych plików, i wtedy ustawienia globalne ich nie nadpisują. W związku z tym pousuwałam w notatniku wszystkie wpisy "RuntimeLibrary=" ze wszsytkich plików vcproj, po czym ustawiłam już normalnie pod IDE takie Runtime jak chciałam. Niestety, nie pomogło (choć faktycznie nadmiarowe/różniące się wpisy były).

Teraz brak mi już pomysłu, a i google zwraca uwagę głównie na to, by wszystkie projekty miały to samo ustawienie - mają.

Command Line Linkera:

/OUT:"./../../../Doctypes/distributions\epic/epiclex.dll" /INCREMENTAL:NO /NOLOGO /LIBPATH:"./../../STools/lib" /LIBPATH:"C:\Program Files\boost\boost_1_40\lib" /DLL /MANIFEST /MANIFESTFILE:"./../work/Debug/\epiclex.dll.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"./../lib/epiclex.pdb" /DYNAMICBASE:NO /IMPLIB:"./../lib/epiclex.lib" /MACHINE:X86 /ERRORREPORT:PROMPT msxml2.lib comctl32.lib wininet.lib htmlhelp.lib odbc32.lib odbccp32.lib shlwapi.lib stools_debug.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib

Za pomocą tej nie ustawiasz tego, co produkuje linker - statycznej czy dynamicznej biblioteki (za to odpowiada opcja "Configuration Type" w sekcji "General") tylko sposób linkowania runtime C/C++. "DLL" w nazwie opcji to dynamiczne, bez niej - statyczne. Jeżeli nie masz bardzo dobrego powodu, żeby zlinkować je statycznie, odradzam.

Problem o którym piszesz powstaje generalnie wtedy, gdy różne object files mają różnie zlinkowane runtime. Spójrz również na biblioteki, które sama statycznie linkujesz, być może one różnią się konfiguracją.

Czy słusznie rozumiem, że biblioteki polinkowane statycznie w projekcie znajdę w Linker > Input > Additional Dependencies...?
Jeżeli tak:

msxml2.lib
comctl32.lib
wininet.lib
htmlhelp.lib
odbc32.lib
odbccp32.lib
shlwapi.lib
stools_debug.lib

Z tych wszystkich bibliotek, tylko stools_debug.lib jest jakkolwiek ode mnie zależna... ale i ona ma w Runtime Library: Multi-threaded Debug DLL... (jest w tej samej solucji).

already defined in EPICDLL.obj

plik epicdll.obj został skompilowany z innym ustawieniem Runtime Library niż cały projekt. Jeśli ten plik jest częścią projektu, przekompiluj wszystko od zera.
Ale jeśli jest częścią jakiejś biblioteki na którą nie masz wpływu, będzie ciężko.

Epicdll to jest właśnie ten projekt, co się nie kompiluje. Runtime Library ma ustawione na Multi-threaded Debug DLL. Przekompilowywałam wszystko od zera już 5 milionów razy, z tymże zwykłam najpierw robić jakąś zmianę... Bo tak bez zmienienia czegokolwiek, ciężko spodziewać się innego efektu niż przed chwilą...

zwykłam najpierw robić jakąś zmianę...
Dlaczego zmianę? Opcja "Rebuild" czyli połączenie "Clean" i "Build" powinna zrobić co należy.

Z dodatkowych informacji - nawet jeśli usunę wszystkie Additional Dependencies, błąd wciąż pozostaje, czyli błąd nie tutaj.

Utwórz nowy projekt z tymi samymi plikami już bezpośrednio w nowym środowisku.

Łoho. Przy przepisywaniu znalazłam dokładny moment, w którym zaczyna pojawiać się błąd - dzieje się to w chwili dodania do Additional Libraries (Linker->General) wpisu "C:\Program Files\boost\boost_1_40\lib"

Czyżby wniosek z tego, że zainstalowałam sobie złą wersję boosta...? (Tak pytam, ale w międzyczasie biorę się za przeinstalowywanie - tylko już wiem, że to zajmie ładnych kilka godzin...).

Najlepiej będzie jak sama sobie go skompilujesz.

Po przeniesieniu projektu (utworzona nowa świeżutka solucja, wszystkie pliki pododawane jak należy, aż normalnie porządek w folderach przy okazji zrobiłam...) i przeinstalowania boosta wracam z tym samym problemem.

O co kaman:
Z początku skorzystałam z instalatora boostpro (http://www.boostpro.com/download/) dla zwykłej wygody. Wybrałam wersję tylko vc90 (mam VS 2008) oraz zaznaczyłam Multithread DLL oraz Multithread DLL Debug.

W katalogu lib widzę, że pojawiły się biblioteki. Znaczna większość ma nazwę w formie: boost_regex-vc90-mt-gd-1_47.lib, co jak sprawdziłam w dokumentacji boosta oznacza, że jest to biblioteka dynamiczna, multi threading - czyli niby gites. (Wszystkie pliki są w wersji lib i dll, o tej samej nazwie)

A jednak, kompilator krzyczy:
LNK1104: cannot open file 'libboost_filesystem-vc90-mt-gd-1_47.lib'
A dlaczego on chce linkować statyczną bibliotekę, której nie ma...? Jest jej prawidłowa wersja: boost_filesystem-vc90-mt-1_47.lib

Próbowałam też kompilacji boosta ręcznie, ale nie mogę znaleźć opcji, która wymusiła by na nim tworzenie dynamicznych bibliotek - a w domyślnej konfiguracji pojawiły się TYLKO biblioteki statyczne. Linkowanie do statycznych bibliotek daje error jak w pierwszym poście.
Dokumentacja bardzo wdzięcznie pisze na ten temat: "For instructions on how to build only specific variants, please ask on the Boost.Build mailing list." :/

Mogę oczywiście spróbować zainstalować jeszcze jedną wersję boosta, ale wydaje mi się, że boostpro działa dobrze, i to nie w instalacji leży problem.

Wychodzę z komentarzy, bo nie ma sensu prowadzić w nich dyskusję dotyczą tematu.

Podsumowując - przekompilowywałam już boosta milion razy, ale widać za każdym razem muszę robić to źle. Próbowałam użyć boostpro, próbowałam odpalić po prostu bjam, próbowałam też np.:

bjam toolset=msvc-9.0 link=static runtime-link=shared threading=multi
Po powyższym powstały pliki z nazwami w stylu: libboost_system-vc90-mt-1_47.lib i dostaję błąd z pierwszego posta, czyli:

Error	2441	error LNK2005: "public: __thiscall std::basic_string<unsigned short,struct std::char_traits<unsigned short>,class std::allocator<unsigned short> >::basic_string<unsigned short,struct std::char_traits<unsigned short>,class std::allocator<unsigned short> >(unsigned short const *)" (??0?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@QAE@PBG@Z) already defined in EPICDLL.obj	msvcprtd.lib	epicdll
 

Azarien napisał(a)

jeśli cały projekt jest kompilowany z /MD, to boost musi też być z /MD. z nazwy pliku twojej libki wynika że Boost jest skompilowany z /MT — "vc90-mt"

Czy jesteś pewien, że mt w nazwie pliku oznacza właśnie, że boost został skompilowany ze statycznym RTL?
Dokumentacja mówi:

-mt
Threading tag: indicates that the library was built with multithreading support enabled. Libraries built without multithreading support can be identified by the absence of -mt.

Nie ma ani słowa o innych opcjach niż mt, tak jakby te dwie literki tutaj odnosiły się tylko do faktu, czy jest multithreading czy nie ma, bez zależności od RTL.
Jeżeli jesteś tego pewien, to przynajmniej da mi to pewność, że źle builduję boosta.

Jeżeli tak jest, czy wiecie może, jak prawidłowo zbuildować boosta z opcją /MD?

edit:
Dalej w dokumentacji jest:

-mt
Threading tag: indicates that the library was built with multithreading support enabled. Libraries built without multithreading support can be identified by the absence of -mt.

-d
ABI tag: encodes details that affect the library's interoperability with other compiled code. For each such feature, a single letter is added to the tag:

    Key 	Use this library when: 	Boost.Build option
    s 	linking statically to the C++ standard library and compiler runtime support libraries. 	runtime-link=static
    g 	using debug versions of the standard and runtime support libraries. 	runtime-debugging=on
    y 	using a special debug build of Python. 	python-debugging=on
    d 	building a debug version of your code.7 	variant=debug
    p 	using the STLPort standard library rather than the default one supplied with your compiler. 	stdlib=stlport

Czyli mt oznacza jedynie, że mamy multithreading, brak flagi s oznacza, że mamy runtime-link=shared (gdyby było s byłoby static). Czyli jakby boost był dobrze skompilowany niby....

Skompilowany jest dobrze, ale system autolink chce złą bibliotekę.

Przejdź do pliku boost\config\user.hpp i odkomentuj #define BOOST_ALL_DYN_LINK albo zdefiniuj to makro w swoim projekcie (jeżeli z nagłówków boosta w tej lokalizacji korzysta kilka projektów w różnej konfiguracji).

Sprecyzujmy jedną rzecz: Microsoftowskie multithreaded DLL oznacza, że runtime będzie dynamiczne, a proboostowskie multithreaded DLL oznacza, że boost będzie dynamiczny i dynamicznie będzie miał zlinkowane runtime (bo nie ma słówka static runtime).

Uściślijmy:

• boost ma być dynamicznie czy statycznie linkowany?
• boost ma mieć dynamicznie czy statycznie linkowane runtime?

Opis dla VS 2010, więc 10.0, dla VS 2008 jest 9.0:

Dwie komendy które używałem:

build_x86.cmd

bjam --toolset=msvc-10.0 --build-type=complete architecture=x86 stage

build_x64.cmd

bjam --toolset=msvc-10.0 --build-type=complete architecture=x86 address-model=64 stage

Oprócz tego mam jakieś "project-config.jam" w katalogu boost które nie wiem czy sam robiłem czy się wygenerowało:

import option ; 
 
using msvc ; 
 
option.set keep-going : false ; 

DLL-ki zrobiły mi się rozwalone po wszystkich katalogach:
\boost\bin.v2\libs\test\build\msvc-10.0\debug\architecture-x86\asynch-exceptions-on\threading-multi\boost_prg_exec_monitor-vc100-mt-gd-1_47.dll

dlatego kopiowałem je do:
\boost\stage\lib

To samo pliki LIB:
\boost\bin.v2\libs\test\build\msvc-10.0\debug\architecture-x86\asynch-exceptions-on\link-static\threading-multi\libboost_prg_exec_monitor-vc100-mt-gd-1_47.lib

W projekcie podajesz ścieżkę bibliotek do do:
\boost\stage\lib

No i widzę że mam w tym katalogu zarówno:
libboost_prg_exec_monitor-vc100-mt-gd-1_47.lib
jak i:
boost_prg_exec_monitor-vc100-mt-gd-1_47.lib

(pewnie sobie skopiowałem)

Jeśli chodzi o wielowątkowość / debugowanie to dla każdej biblioteki mam taki komplet:
libboost_filesystem-vc100-mt-1_47.lib
libboost_filesystem-vc100-mt-gd-1_47.lib
libboost_filesystem-vc100-mt-s-1_47.lib
libboost_filesystem-vc100-mt-sgd-1_47.lib
libboost_filesystem-vc100-s-1_47.lib
libboost_filesystem-vc100-sgd-1_47.lib

Uściślijmy:

1. boost ma być dynamicznie czy statycznie linkowany?
2. boost ma mieć dynamicznie czy statycznie linkowane runtime?

Ad. 1. Nie mam pojęcia, jak powinno być. Wydaje mi się, że w starej wersji było linkowane statycznie (jutro sprawdzę).
Dodam jeszcze, że absolutnie nie należy się przejmować użytkownikiem końcowym, wydajnością czy czymś takim.

Ad. 2. Boost ma mieć dynamicznie linkowane runtime.
Taki wniosek wysunęłam z tego, że otrzymuję błąd linkowania:
Error 2441 error LNK2005: "public: __thiscall std::basic_string<unsigned short,struct std::char_traits<unsigned short>,class std::allocator<unsigned short> >::basic_string<unsigned short,struct std::char_traits<unsigned short>,class std::allocator<unsigned short> >(unsigned short const *)" (??0?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@QAE@PBG@Z) already defined in EPICDLL.obj msvcprtd.lib epicdll

Googlając bardzo dużo na temat tego błędu, natrafiłam na mnóstwo podpowiedzi w stylu:
http://stackoverflow.com/questions/2728649/error-lnk2005-xxx-already-defined-in-msvcrt-libmsvcr100-dllc-something-libc
http://stackoverflow.com/questions/604484/linker-errors-between-multiple-projects-in-visual-c
gdzie zwracają uwagę na to, że wszystkie projekty i biblioteki załączone do projektów powinny być skompilowane z takim samym runtime.

Ja otrzymałam ten program jako solucję VS2003. Pod VS 2003 kompilował się i działał bez błędów. W tamtej konfiguracji było tak:

1. Tools - statyczna biblioteka, RTL /MT
2. DuzyProjekt - dll, RTL /MD
3. BardzoWaznyDuzyProjekt - dll, RTL /MD

W nowej konfiguracji, sugerując się podpowiedziami google'a ustawiłam i projektowi 1. /MD.
Gdy przepisywałam projekt krok po kroku do nowej, świeżej solucji, wyszło na jaw, że ten błąd zaczyna się pojawiać, gdy dodam do Additional Libraries ścieżkę do boosta.

Dodam, że program kompiluje się, gdy ustawię wszystkim projektom /MT, jednak nie działa prawidłowo: http://4programmers.net/Forum/C_i_C++/197079-comy_idispatch_i_nieprawidlowy_wskaznik?start=0

#define BOOST_ALL_DYN_LINK

Próbowałam tego... dodałam taką linijkę w stdafx.h, ale dostałam nowe błędy. Jutro wkleję, bo już nie mam tego projektu pod ręką.

Dodam, że ja niespecjalnie wiem co robię. Staram się aktualizować informacje na bieżąco i dlatego też tak uparłam się, żeby skompilować ten projekt jako MD. To powinno działać, jeżeli nie działa, to tylko dlatego, że jeszcze nie wiem co robię źle. Skoro nie wiem co robię źle na tym etapie, to nie mogę zgodzić się na rozwiązanie "skompiluj jako MT i daj se spokój", bo skutkuje to jedynie błędami na dalszym etapie, z którymi również sobie nie radzę.

Dalsze detale:

• w aplikacji symbole w wersji DEBUG:

BOOST_NO_RVALUE_REFERENCES
WIN32
_DEBUG
_CRTDBG_MAP_ALLOC
_CRT_SECURE_NO_WARNINGS

• w wersji RELEASE:

WIN32
_WINDOWS
_CRT_SECURE_NO_WARNINGS
_SECURE_SCL=0
BOOST_NO_RVALUE_REFERENCES

Runtime library:

• DEBUG: Multi-threaded Debug DLL (/MDd)
• RELEASE: Multi-threaded DLL (/MD)

Additional Library directories:

• jak napisałem wcześniej: boost\stage\lib

Additional dependencies:

• dla Boost nic

Cały czas to wygląda tak, jakby coś (być może Boost) było skompilowane inaczej niż reszta.
Zwróć uwagę na to, że jest jeszcze /MTd i /MDd, czyli debugowe odpowiedniki MT i MD, bo osobno ustawia się opcje dla kompilacji Debug i Release.

Żeby grało, dla Release wszystko powinno być /MD (Multithreaded DLL) a dla Debug /MDd (Multithreaded Debug DLL). To trochę komplikuje sprawę, bo oznacza że potrzebujemy osobnej biblioteki lib/dll dla debug i osobnej dla release.

Dodam, że program kompiluje się, gdy ustawię wszystkim projektom /MT
to oznacza że to coś (być może Boost) jest cały czas w /MT i tylko wtedy zaczyna się program kompilować.

Wracam do mojego ulubionego problemu, z nowym zapałem i energią do walki :P

Mam postępy. Obecnie jestem w stanie doprowadzić program do kompilacji w trybie /MTd. Mam wtedy oczywiście inne problemy, ale faktycznie są one zupełnie niezależne i wynikają z co najmniej dziwnej konstrukcji programu (wątki + STA/MTA - mam wersję półdziałającą, więc zostawiam to sobie na później).

Skupmy się jednak na próbie kompilacji w trybie /MDd. Okazuje się, że tryb /MTd jest niekompatybilny z trybem /clr, stąd mam większe ciśnienie na to by mieć działającą wersję /MDd. Jak już doprowadzę projekt do kompilacji z /clr to będzie w zasadzie sukces, i dalej będę mogła już sobie moduł po module przepisywać.

Ok, obecnie wygląda to tak:

1. Usunęłam biblioteki boosta z katalogu lib i odpaliłam na nowo instalację (wspomagam się boostpro, bo jak na razie to on instalował wszystko gites, a wszystkie błędy były po mojej stronie)
2. Wybrałam Visual C++ 9.0 (VS2008) oraz Multithread debug DLL i Multithread DLL - i nie instalowałam nic poza tym.
3. W efekcie w folderze boost\lib powstały mi pliki w stylu:

boost_regex-vc90-mt-1_47.dll
boost_regex-vc90-mt-1_47.lib
boost_regex-vc90-mt-gd-1_47.dll
boost_regex-vc90-mt-gd-1_47.lib

4. W projekcie mam dodaną ścieżkę do boosta w C++/General/Additional Include Directories oraz ścieżkę do boost\lib w Linker/General/Additional Library Directories

Błąd: fatal error LNK1104: cannot open file 'libboost_filesystem-vc90-mt-gd-1_47.lib'

Jakby... chciał mimo wszystko linkować do wersji, która do runtime library linkuje się statycznie...? Jakby nie wykrył sobie boost tego automatycznie prawidłowo...
Czy nie pitolę jakichś strasznych bzdur? Te pliki boosta wyglądają ok, prawda?
A może jednak boostpro jest skopany na amen i ja w ogóle złe pliki dostaję...?

Błąd: fatal error LNK1104: cannot open file 'libboost_filesystem-vc90-mt-gd-1_47.lib'

Jakby... chciał mimo wszystko linkować do wersji, która do runtime library linkuje się statycznie...?

Siedzisz nad tym już chyba z pół roku, masz problemy z podstawowym zrozumieniem konwencji nazewniczej boosta i dalej nawet nie spróbujesz sięgnąć do dokumentacji. Do pierwszego jej działu, który nazywa się "Getting started on Windows" (http://www.boost.org/doc/libs/1_49_0/more/getting_started/windows.html#library-naming).

W dalszym ciągu nie rozróżniasz również biblioteki skompilowanej statycznie od biblioteki ze statycznie zlinkowanym runtime.

Po zainstalowanych nazwach pliku można powiedzieć, że jest to: dynamiczna biblioteka (bo masz dllki, a te liby to są tylko import libraries - nie ma słówka lib na początku) z dynamicznie zlinkowanym runtime (bo nie ma literki s w środku).
Natomiast system autolink chce zlinkować statyczną bibliotekę z dynamicznie zlinkowanym runtime. Tak domyślnie działa właśnie boost i system autolink niestety nie wejdzie ci do głowy i nie domyśli się którą wersję chcesz użyć. Możesz sobie otworzyć plik nagłówkowy, który się tym zajmuje i zobaczyć na podstawie których makr tworzona jest nazwa biblioteki. Nie ma tam czarnej magii.

Z obecnymi zainstalowanymi bibliotekami powinnaś w swoim projekcie zdefiniować BOOST_ALL_DYN_LINK. Aczkolwiek odradzam dynamiczne linkowanie boosta, bo zdaje się, że i tak nie wszystkie komponenty boosta są do niego przystosowane.

@Rev, wiem wiem, o tej literce "s" doczytałam zaraz po napisaniu posta. Siedzę nad projektem pół roku, ale po może 2h tygodniowo, co jest sposobem mega nieefektywnym - a niestety, ani nie jest to projekt o wysokim priorytecie, ani w języku, w którym na co dzień piszę. Co mi się poukłada w głowie, to muszę przerwę robić (na bieżące zadania) i potem znowu walę gafy :/
Właśnie dlatego wspieram się forum i publikuję te moje wypociny, by mnie starsi, mądrzejsi koledzy poprawili chociaż w tych kluczowych kwestiach ;)

Mimo tego, że tak brzydko gafy walę, to chciałabym zauważyć, że w żadnej, ale to absolutnie żadnej instalowanej przeze mnie wersji boosta w nazwach plików nie pojawiała się literka "s". Mimo to, dostawałam komunikaty błędów takie, jak przytoczone wcześniej (sugerujące, że jednak jakaś biblioteka jest skompilowana do runtime-library statycznie):

Error 2441 error LNK2005: "public: __thiscall std::basic_string<unsigned short,struct std::char_traits<unsigned short="short">,class std::allocator<unsigned short="short"> >::basic_string<unsigned short,struct std::char_traits<unsigned short="short">,class std::allocator<unsigned short="short"> >(unsigned short const *)" (??0?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@QAE@PBG@Z) already defined in EPICDLL.obj msvcprtd.lib epicdll

Bardzo ci dziękuję za konkretną, jasną odpowiedź - odkomentowałam tego define'a w boost\config\user.hpp i projekt faktycznie się skompilował.
Euforia ma jednak nie trwała długo - skompilowane dllki odmawiają rejestracji.

RegSvr32 daje komunikat:

Funkcja LoadLibrary("nazwa_dllki.dll") nie powiodła się - Nie można odnaleźć określonego modułu.

Zaciekawiło mnie również, że rundll32.exe NazwaDlllki.dll, NazwaFunkcjiWystawionej dało taki oto komunikat:

Uruchomienie tej aplikacji nie powiodło się, ponieważ nie znaleziono boost_filesystem-vc90-mt-gd-1_47.dll. Ponowne zainstalowanie aplikacji może naprawić ten problem.

Choć nie wiem, czy w ogóle jest sens używać rundll32 na niezarejestrowanej dllce. Wskazany w komunikacie plik oczywiście znajduje się w boost\lib.

Aczkolwiek odradzam dynamiczne linkowanie boosta, bo zdaje się, że i tak nie wszystkie komponenty boosta są do niego przystosowane.

Mi nie zależy na tym, by boost był linkowany dynamicznie. Zależy mi, żeby działało. Co polecasz w takim razie zamiast?
Z boostem linkowanym statycznie dostaje komunikaty związane z msvcprtd.lib.
Z boostem zalinkowanym dynamicznie dostaję niedziałającą dllkę.
W żadnym z podejść nie używam plików boosta zawierających flagę "s" w nazwie.

Aurelka, to chyba nawet moja mama wie, że dllka, z której korzysta program nie może leżeć w jakimś randomowym miejscu (takim jak boost\lib) :(. Skopiuj je do katalogu z programem.

@Rev, zarejestrowana w systemie dllka może leżeć gdzie bądź :P
Niby wiem, a jakoś synapsy nie stykają :/

Tak czy siak obnaża to w takim razie kolejny problem - linkowanie dynamiczne jest złym pomysłem. Zaraz sobie sprawdzę jak to działa już tak tylko z ciekawości, ale prawdę powiedziawszy mało realne jest przekazywanie dllek boosta użytkownikom. Eh, a może... Nieee, raczej nie przejdzie. No tak, ale szarpię się między wersją, która nie działa, a wersją, która jest załamująca ze względu na ilość dynamicznie linkowanych bibliotek...

OMG działa! Dzięki, dzięki, dzięki!

To wspaniale. Mimo iż jestem C++sowym debilem mam już działający projekt w wersji /MTd i /MDd! Teraz muszę się przespać z faktem, że boost jest dynamicznie linkowany. Może się po prostu z tym pogodzę. Jeszcze się zastanowię.

Wciąż nie rozumiem, czemu nie można normalnie zalinkować boosta statycznie (w trybie /MDd), ale i tak wielkie dzięki za pomoc :)