$include_dir="/home/hyper-archives/boost-users/include"; include("$include_dir/msg-header.inc") ?>
From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-12-05 22:20:24
>>>>>
"Alo Sarv" <alo.sarv_at_[hidden]> wrote in message 
news:14a0620d0512031455q8977f2ao4bdd08b56783e38c_at_mail.gmail.com...
The topic itself is already few months old, namely the fact that 
Boost.Filesystem
library breaks on Mingw in DLL builds. As I see from regression tests, this 
issue
hasn't been fixed yet. The reason I'm bringing this up again is that while 
originally
it was concluded that static builds should be used on Mingw instead of DLL 
builds,
it is becoming an increasing problem for me, since default_name_check 
doesn't work
across DLL boundaries when B.FS is linked statically to one of the DLL's, 
which
results unexpected exceptions being thrown all over my codebase unless I 
explicitly
construct paths using native name-checker, but tracking all those places is 
a constant
headache.
Is there any plans on addressing this issue, or are there any additional 
workarounds
to have default_name_check functioanlity working across DLL boundaries when
Boost.Filesystem is linked statically? My experience has been that mixing 
dynamic
and static libraries is a really bad idea...
<<<<<
A major upgrade to the filesystem library now on the i18n branch will get 
merged into CVS HEAD in a few days. Once that happens it should hopefully be 
easier to track down the Mingw problems if they still exist.
--Beman