Re: strange filesystem dll behaviour (Beman Dawes)
Hi, I guess, you don't define BOOST_ALL_DYN_LINK Rgds -- Christian Hoffmann Trema Laboratories SARL -----Original Message----- From: boost-users-request@lists.boost.org [mailto:boost-users-request@lists.boost.org] Sent: Friday, January 21, 2005 6:12 PM To: boost-users@lists.boost.org Subject: Boost-users Digest, Vol 437, Issue 3 Send Boost-users mailing list submissions to boost-users@lists.boost.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.boost.org/mailman/listinfo.cgi/boost-users or, via email, send a message with subject or body 'help' to boost-users-request@lists.boost.org You can reach the person managing the list at boost-users-owner@lists.boost.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Boost-users digest..." Today's Topics: 1. Re: strange filesystem dll behaviour (Beman Dawes) 2. Re: unordered_map/hash_table bug? (Daniel James) 3. Re: Re: (newbie) Linking problem using unit testframework(Mac OSX 10.3.7 gcc 3.3 XCode 1.5). (Gennadiy Rozental) ---------------------------------------------------------------------- Message: 1 Date: Fri, 21 Jan 2005 10:18:02 -0500 From: Beman Dawes <bdawes@acm.org> Subject: Re: [Boost-users] strange filesystem dll behaviour To: boost-users@lists.boost.org, boost-users@lists.boost.org Message-ID: <6.0.3.0.2.20050121100502.049f35e0@mailhost.esva.net> Content-Type: text/plain; charset="us-ascii"; format=flowed At 01:12 AM 1/20/2005, Paul wrote:
I looked deeper into the problem, and hacked up boost a little to find out that the problem is the following check:
if ( (checker == no_check || checker == native) && src.size() = 2 ) at path_posix_windows.cpp:243
specifically checker==native.
I had constructed path with boost::filesystem::native, but when I hacked it up to do the following:
# ifdef BOOST_WINDOWS std::stringstream ss; ss << "checker=" << reinterpret_cast<unsigned long>(checker) << std::endl << "native=" << reinterpret_cast<unsigned long>(native) << std::endl; boost::throw_exception( filesystem_error( "boost::filesystem::path", ss.str() ));
if ( (checker == no_check || checker == native) && src.size() = 2 )
I got the following results from calling the line: boost::filesystem::path p(s,boost::filesystem::native);
linking to libboost_filesystem-mgw-d-1_32.lib: checker=4201048 native=4201048
linking to boost_filesystem-mgw-d-1_32.dll: checker=4263776 native=1649966248
so, it appears that testing the checker using the address of a function is unreliable in a DLL context? Have I compiled my program/library incorrectly? I am not too familiar with DLL details etc, can someone else please shed some light on this?
I'm not a DLL expert either, but it certainly looks like there is some problem with address of functions across DLL boundaries. This code will be going away in the next version of the library, so I'm not sure if it is worth putting a lot of effort into fixing it. But I'll try to reproduce the problem here. If it does reproduce, it shouldn't be too hard to come up with an interim fix. Thanks for the report, --Beman ------------------------------ Message: 2 Date: Fri, 21 Jan 2005 16:15:48 +0000 From: Daniel James <daniel@calamity.org.uk> Subject: [Boost-users] Re: unordered_map/hash_table bug? To: boost-users@lists.boost.org Message-ID: <csr9ro$ma$1@sea.gmane.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Thorsten Ottosen wrote:
"Martin Wartens" <martin.wartens@my-mail.ch> wrote in message news:380-22005121815022188@my-mail.ch... Hi, has anybody tried the implementation of unordered map that can be found at
http://groups.yahoo.com/group/boost/files/jtc1-sc22-wg21-2003-n1456.tar. gz ?
I believe there is a bug in the rehash function of the underlying hash_table. The new bucket indices are computed using the old number of buckets. That means that the items stored in these buckets cannot be found anymore later. -------
Btw, would you mind to submit a patch to me to fix this bug?
Thanks
Thorsten
Hi Thorsten, I'm working a new version which fixes this (and a few other) bugs. I'll upload it the file vault soon. Daniel ------------------------------ Message: 3 Date: Fri, 21 Jan 2005 11:21:43 -0500 From: "Gennadiy Rozental" <gennadiy.rozental@thomson.com> Subject: [Boost-users] Re: Re: (newbie) Linking problem using unit testframework(Mac OSX 10.3.7 gcc 3.3 XCode 1.5). To: boost-users@lists.boost.org Message-ID: <csra6n$1sg$1@sea.gmane.org>
c++filt _ZTv0_n12_NSoD0Ev virtual thunk to std::basic_ostream<char, std::char_traits<char> ::~basic_ostream()
Then I tried to run just this: #include <iostream>
int main (int arc, char** argv) { std::cout << "test"; }
... and it failed with the same error. However, if I remove from the project the unit test framework files, it runs fine.
Hmm...
I am using libstdc++.a. I don't understand what is happening.
Why when I add the unit test framework code it doesn't find the standard
So do I. library ~basic_ostream() anymore ? Most probably looks like compiler bug
It seems these last 5 years doing only Java got me really rusty with C++ (I'd rather work with C++ but the market forced me to go to Java).
I don't think 'last 5 years doing only Java' has anything to do with this. Let's try couple more thigs: 1. Could you locate where this undefined symbol referenced from? 2. Could you build framework as a standalone library and link with it? Gennadiy ------------------------------ _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users End of Boost-users Digest, Vol 437, Issue 3 ******************************************* This message, including any attachments, is intended only for the person(s) to whom it is addressed. If you received it in error, please let us know and delete the message from your system. This message may be confidential and may fall under the duty of non-disclosure. Any use by others than the intended addressee is prohibited. Trema shall not be liable for any damage related to the electronic transmission of this message, such as failure or delay of its delivery, interception or manipulation by third parties, or transmission of viruses or other malicious code.
Hi, I assume you are talking about defining that when compiling my test program? I tried it, it didn't work, it gave the same behaviour as before. Any more ideas? Has anyone tried my example? Thanks Paul Christian Hoffmann wrote:
Hi,
I guess, you don't define
BOOST_ALL_DYN_LINK
Rgds -- Christian Hoffmann Trema Laboratories SARL
-----Original Message----- From: boost-users-request@lists.boost.org [mailto:boost-users-request@lists.boost.org] Sent: Friday, January 21, 2005 6:12 PM To: boost-users@lists.boost.org Subject: Boost-users Digest, Vol 437, Issue 3
Send Boost-users mailing list submissions to boost-users@lists.boost.org
To subscribe or unsubscribe via the World Wide Web, visit http://lists.boost.org/mailman/listinfo.cgi/boost-users or, via email, send a message with subject or body 'help' to boost-users-request@lists.boost.org
You can reach the person managing the list at boost-users-owner@lists.boost.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Boost-users digest..."
Today's Topics:
1. Re: strange filesystem dll behaviour (Beman Dawes) 2. Re: unordered_map/hash_table bug? (Daniel James) 3. Re: Re: (newbie) Linking problem using unit testframework(Mac OSX 10.3.7 gcc 3.3 XCode 1.5). (Gennadiy Rozental)
----------------------------------------------------------------------
Message: 1 Date: Fri, 21 Jan 2005 10:18:02 -0500 From: Beman Dawes <bdawes@acm.org> Subject: Re: [Boost-users] strange filesystem dll behaviour To: boost-users@lists.boost.org, boost-users@lists.boost.org Message-ID: <6.0.3.0.2.20050121100502.049f35e0@mailhost.esva.net> Content-Type: text/plain; charset="us-ascii"; format=flowed
At 01:12 AM 1/20/2005, Paul wrote:
I looked deeper into the problem, and hacked up boost a little to find out that the problem is the following check:
if ( (checker == no_check || checker == native) && src.size()
= 2
)
at path_posix_windows.cpp:243
specifically checker==native.
I had constructed path with boost::filesystem::native, but when I hacked it up to do the following:
# ifdef BOOST_WINDOWS std::stringstream ss; ss << "checker=" << reinterpret_cast<unsigned long>(checker) << std::endl << "native=" << reinterpret_cast<unsigned long>(native) << std::endl; boost::throw_exception( filesystem_error( "boost::filesystem::path", ss.str() ));
if ( (checker == no_check || checker == native) && src.size()
= 2
)
I got the following results from calling the line: boost::filesystem::path p(s,boost::filesystem::native);
linking to libboost_filesystem-mgw-d-1_32.lib: checker=4201048 native=4201048
linking to boost_filesystem-mgw-d-1_32.dll: checker=4263776 native=1649966248
so, it appears that testing the checker using the address of a
function
is unreliable in a DLL context? Have I compiled my program/library incorrectly? I am not too familiar with DLL details etc, can someone else please shed some light on this?
I'm not a DLL expert either, but it certainly looks like there is some problem with address of functions across DLL boundaries.
This code will be going away in the next version of the library, so I'm not sure if it is worth putting a lot of effort into fixing it. But I'll try to reproduce the problem here. If it does reproduce, it shouldn't be too hard to come up with an interim fix.
Thanks for the report,
--Beman
------------------------------
Message: 2 Date: Fri, 21 Jan 2005 16:15:48 +0000 From: Daniel James <daniel@calamity.org.uk> Subject: [Boost-users] Re: unordered_map/hash_table bug? To: boost-users@lists.boost.org Message-ID: <csr9ro$ma$1@sea.gmane.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Thorsten Ottosen wrote:
"Martin Wartens" <martin.wartens@my-mail.ch> wrote in message news:380-22005121815022188@my-mail.ch... Hi, has anybody tried the implementation of unordered map that can be
found at
http://groups.yahoo.com/group/boost/files/jtc1-sc22-wg21-2003-n1456.tar. gz ?
I believe there is a bug in the rehash function of the underlying hash_table. The new bucket indices are computed using the old number
of
buckets. That means that the items stored in these buckets cannot be
found
anymore later. -------
Btw, would you mind to submit a patch to me to fix this bug?
Thanks
Thorsten
Hi Thorsten,
I'm working a new version which fixes this (and a few other) bugs. I'll upload it the file vault soon.
Daniel
------------------------------
Message: 3 Date: Fri, 21 Jan 2005 11:21:43 -0500 From: "Gennadiy Rozental" <gennadiy.rozental@thomson.com> Subject: [Boost-users] Re: Re: (newbie) Linking problem using unit testframework(Mac OSX 10.3.7 gcc 3.3 XCode 1.5). To: boost-users@lists.boost.org Message-ID: <csra6n$1sg$1@sea.gmane.org>
c++filt _ZTv0_n12_NSoD0Ev virtual thunk to std::basic_ostream<char, std::char_traits<char> ::~basic_ostream()
Then I tried to run just this: #include <iostream>
int main (int arc, char** argv) { std::cout << "test"; }
... and it failed with the same error. However, if I remove from the project the unit test framework files,
it runs fine.
Hmm...
I am using libstdc++.a. I don't understand what is happening.
So do I.
Why when I add the unit test framework code it doesn't find the
standard library ~basic_ostream() anymore ?
Most probably looks like compiler bug
It seems these last 5 years doing only Java got me really rusty with
C++ (I'd rather work with C++ but the market forced me to go to Java).
I don't think 'last 5 years doing only Java' has anything to do with this.
Let's try couple more thigs:
1. Could you locate where this undefined symbol referenced from? 2. Could you build framework as a standalone library and link with it?
Gennadiy
------------------------------
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
End of Boost-users Digest, Vol 437, Issue 3 *******************************************
This message, including any attachments, is intended only for the person(s) to whom it is addressed. If you received it in error, please let us know and delete the message from your system. This message may be confidential and may fall under the duty of non-disclosure. Any use by others than the intended addressee is prohibited. Trema shall not be liable for any damage related to the electronic transmission of this message, such as failure or delay of its delivery, interception or manipulation by third parties, or transmission of viruses or other malicious code.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (2)
-
Christian Hoffmann -
Paul