New subject: strange filesystem dll behaviour (Beman Dawes)

21 Jan 2005

      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 
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 
Subject: [Boost-users] Re: unordered_map/hash_table bug?
To: boost-users@lists.boost.org
Message-ID: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Thorsten Ottosen wrote:
...
"Martin Wartens"  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" 
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: 
...
c++filt _ZTv0_n12_NSoD0Ev
virtual thunk to std::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.

Re: strange filesystem dll behaviour (Beman Dawes)

Christian Hoffmann

Paul

tags

participants (2)