Boost.Filesystem DLL builds on Mingw
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... Alo Sarv
"Alo Sarv"
wrote in message news:14a0620d0512031455q8977f2ao4bdd08b56783e38c@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
I was one of those who found the DLL problems in a painful way. Attached is a patch I use to work around the problem. Apply the patch and instead of using ::native, use ::get_native(). This returns the boost DLL's function pointer from the POV of the boost DLL. Works well. see ya Paul Alo Sarv wrote:
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...
Alo Sarv
------------------------------------------------------------------------
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (3)
-
Alo Sarv
-
Beman Dawes
-
Paul