STL, streams and linker problem

Hi
i just dowloaded the fantastic STL port from Andy used in in my project when linker problems about duplicated stream-destructor symbols startet. So I prepared a little example which reproduces the problem (at least on my site). the example consists of 3 small files (sketch, foo.h, foo.cpp).
As soon as i use streams in different cpp files, the linker complains about duplicated destructors (see error msg below). To me, it lokks like the compiler doesnt regognices the forward declarations in as forwards but rather regular declarations.
Any idea what the problem might be ? Any help would be appriciated since the STL makes C++ much more convinient

sketch.cpp

#include <Arduino.h>

#include <iterator>
#include <sstream>
#include <pnew.cpp>

#include "Foo.h"

void setup()  { /* do nothing */}

void loop() {
	std::stringstream ss;
	ss << "hello";

	Foo f;
	f.bar();
}

foo.h

#ifndef FOO_H_
#define FOO_H_

#include <string>

struct Foo {
		std::string bar();
};

#endif

foo.cpp

#include "Foo.h"

#include <sstream>

std::string Foo::bar() {
	std::stringstream ss;
	return ss.str();
}

linker errors:

./loop.cpp.o: In function `virtual thunk to std::basic_iostream<char, std::char_traits<char> >::~basic_iostream()':
D:\stl\include/iosfwd:43: multiple definition of `virtual thunk to std::basic_iostream<char, std::char_traits<char> >::~basic_iostream()'
./Foo.cpp.o:D:\stl\include/iosfwd:43: first defined here
./loop.cpp.o: In function `non-virtual thunk to std::basic_iostream<char, std::char_traits<char> >::~basic_iostream()':

Using most STL classes on a embedded processor with limited RAM such as the Arduino is generally not a wise thing to do. This is because most STL classes relay on dynamic memory allocation, which is fine in a PC environment with lots of memory (including virtual memory), but generally a bad idea on an embedded processor. Even if you don’t have any memory leaks, you risk running out of memory due to fragmentation, or due to not rejecting inputs that you don’t have enough memory to process.