hi, I'm new to boost, stlport and programming on linux in general, so I apologise now for any obvious beginner errors! I'm using mandrake 10 and gcc 3.3.2, and using root I created STLport 4.6.2 libraries, and then created all the boost 1.31.0 libraries using bjam -sTOOLS=gcc-stlport -sBUILD="debug release <stlport-iostream>on" install I had to have this little lot in my bashrc file to do it; export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib export STLPORT_VERSION=4.6.2 export STLPORT_ROOT=/home/ncain export STLPORT_LIB_DIRECTORY=/usr/local/lib export STLPORT_INCLUDE_DIRECTORY=/usr/local/include/ export PYTHON_VERSION=2.3 export PYTHON_ROOT=/usr Everything seemed to build ok, apart from an "../lib/libstlport_gcc_debug.so does not exist" error in the final part of the stlport build and a continual "warning: "_POSIX_C_SOURCE" redefined" warning during the boost build. Both the stlport and boost libraries are in /usr/local/lib ok, and building thread/test passed fine too. I altered one of the tutorial files to use _STL and also created a makefile (since bjam is a bit beyond me at the moment), and these appear as; testboost.cpp: #include <boost/thread/thread.hpp> #include <boost/thread/xtime.hpp> #include <iostream> using namespace _STL; struct thread_alarm { thread_alarm(int secs) : m_secs(secs) { } void operator()() { cout << "alarm sounded..." << endl; } int m_secs; }; int main(int argc, char* argv[]) { int secs = 5; thread_alarm alarm(secs); boost::thread thrd(alarm); thrd.join(); } makefile: .PHONY: all clean ALL = testboost INCS = -I"/usr/local/include/stlport" \ -I"/usr/local/include/boost-1_31" LIBS=-L"/usr/local/lib" -lstlport_gcc -lboost_thread-gcc-mt-p -lpthread .cpp: ${CXX} ${INCS} -pthread -o $@ $^ ${LIBS} all: ${ALL} clean: ${RM} core* *.o ${RM} ${ALL} make returns this error; g++ -I"/usr/local/include/stlport" -I"/usr/local/include/boost-1_31" -pthread -o testboost testboost.cpp -L"/usr/local/lib" -lstlport_gcc -lboost_thread-gcc-mt-p -lpthread /home/ncain/tmp/ccZWBPnj.o(.text+0x4b): In function `main': : undefined reference to `boost::thread::thread[in-charge](boost::function0<void, _STL::allocator<boost::function_base> > const&)' collect2: ld returned 1 exit status make: *** [testboost] Error 1 using -lboost_thread-gcc-mt-gdp makes no difference, however changing the cpp to use the std libraries works fine (builds and runs correctly). Have I made a mistake in building the boost libraries or possibly in my makefile? thanks, nik
Hi, I posted this a while ago but with no response, so I'm trying again. If anyone is using the boost::threads library with gcc & STLPort and has no problems, perhaps they could let me know - at least then I know its worth perservering with (or at least try compiling my example?) If I try to compile the example below with a makefile (also below), then I get this linker error: /home/ncain/tmp/ccaK5aes.o(.text+0x4b): In function `main': : undefined reference to `boost::thread::thread[in-charge](boost::function0<void, _STL::allocator<boost::function_base> > const&)' If I don't use the _STL namespace it compiles. Looking at the libboost libraries, they contain references to _STL stuff, so I assume I compiled them ok (bjam -sTOOLS=gcc-stlport -sBUILD="<stlport-iostream>on" ) Does anyone know what could be wrong? (or how I can change a bjam file to include the /usr/local/include/stlport path? so I could try that) nik testboost.cpp: #include <iostream> #include <boost/thread/thread.hpp> #include <boost/thread/xtime.hpp> using namespace _STL; struct thread_alarm { thread_alarm(int secs) : m_secs(secs) { } void operator()() { cout << "alarm sounded..." << endl; } int m_secs; }; int main(int argc, char* argv[]) { int secs = 5; thread_alarm alarm(secs); boost::thread thrd(alarm); thrd.join(); } Makefile: .PHONY: all clean ALL = testboost LIBS= -I/usr/local/include/stlport -I/home/ncain/boost_1_31_0 -L/usr/local/lib -lstlport_gcc -lboost_thread-gcc-mt-gdp .cpp: ${CXX} -lpthread -o $@ $^ ${LIBS} all: ${ALL} clean: ${RM} core* *.o ${RM} ${ALL}
I had a similar problem. Thanks to Dave, Using the shared library for threads that got built while build+installing boost solved my problem. - Raja
Hi, I posted this a while ago but with no response, so I'm trying again. If anyone is using the boost::threads library with gcc & STLPort and has no problems, perhaps they could let me know - at least then I know its worth perservering with (or at least try compiling my example?)
If I try to compile the example below with a makefile (also below), then I get this linker error:
/home/ncain/tmp/ccaK5aes.o(.text+0x4b): In function `main': : undefined reference to `boost::thread::thread[in-charge](boost::function0<void, _STL::allocator<boost::function_base> > const&)'
If I don't use the _STL namespace it compiles. Looking at the libboost libraries, they contain references to _STL stuff, so I assume I compiled them ok (bjam -sTOOLS=gcc-stlport -sBUILD="<stlport-iostream>on" )
Does anyone know what could be wrong? (or how I can change a bjam file to include the /usr/local/include/stlport path? so I could try that)
nik
testboost.cpp: #include <iostream> #include <boost/thread/thread.hpp> #include <boost/thread/xtime.hpp>
using namespace _STL;
struct thread_alarm { thread_alarm(int secs) : m_secs(secs) { } void operator()() { cout << "alarm sounded..." << endl; }
int m_secs; };
int main(int argc, char* argv[]) { int secs = 5; thread_alarm alarm(secs); boost::thread thrd(alarm); thrd.join(); }
Makefile: .PHONY: all clean ALL = testboost LIBS= -I/usr/local/include/stlport -I/home/ncain/boost_1_31_0 -L/usr/local/lib -lstlport_gcc -lboost_thread-gcc-mt-gdp
.cpp: ${CXX} -lpthread -o $@ $^ ${LIBS}
all: ${ALL}
clean: ${RM} core* *.o ${RM} ${ALL}
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Regards Raja
I saw yours and Davids posts, and thought it looked the same, but then I realised yours was std::allocator< ... etc, while mine is _STL::allocator<... . I find that when I use the normal std everything works, but not when I try to use STLPort, so I'm confident I'm linking to the libraries, but they don't contain_STL::allocator<boost::function_base> I don't know if this is a problem in the way I built boost or STLPort, or with my makefile or environment. thanks for noticing though! nik Raj wrote:
I had a similar problem. Thanks to Dave, Using the shared library for threads that got built while build+installing boost solved my problem.
- Raja
Hi, I posted this a while ago but with no response, so I'm trying again. If anyone is using the boost::threads library with gcc & STLPort and has no problems, perhaps they could let me know - at least then I know its worth perservering with (or at least try compiling my example?)
If I try to compile the example below with a makefile (also below), then I get this linker error:
/home/ncain/tmp/ccaK5aes.o(.text+0x4b): In function `main': : undefined reference to `boost::thread::thread[in-charge](boost::function0<void, _STL::allocator<boost::function_base> > const&)'
If I don't use the _STL namespace it compiles. Looking at the libboost libraries, they contain references to _STL stuff, so I assume I compiled them ok (bjam -sTOOLS=gcc-stlport -sBUILD="<stlport-iostream>on" )
Does anyone know what could be wrong? (or how I can change a bjam file to include the /usr/local/include/stlport path? so I could try that)
nik
testboost.cpp: #include <iostream> #include <boost/thread/thread.hpp> #include <boost/thread/xtime.hpp>
using namespace _STL;
struct thread_alarm { thread_alarm(int secs) : m_secs(secs) { } void operator()() { cout << "alarm sounded..." << endl; }
int m_secs; };
int main(int argc, char* argv[]) { int secs = 5; thread_alarm alarm(secs); boost::thread thrd(alarm); thrd.join(); }
Makefile: .PHONY: all clean ALL = testboost LIBS= -I/usr/local/include/stlport -I/home/ncain/boost_1_31_0 -L/usr/local/lib -lstlport_gcc -lboost_thread-gcc-mt-gdp
.cpp: ${CXX} -lpthread -o $@ $^ ${LIBS}
all: ${ALL}
clean: ${RM} core* *.o ${RM} ${ALL}
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Regards
Raja _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Mon, 23 Aug 2004 23:32:14 +0200, Nicholas Cain <nik.cain.boost@noos.fr> wrote:
I saw yours and Davids posts, and thought it looked the same, but then I realised yours was std::allocator< ... etc, while mine is _STL::allocator<... . I find that when I use the normal std everything works, but not when I try to use STLPort, so I'm confident I'm linking to the libraries, but they don't contain_STL::allocator<boost::function_base> I don't know if this is a problem in the way I built boost or STLPort, or with my makefile or environment.
thanks for noticing though!
nik
I've seen this exact problem on Windows, in various forms: basically one of a) the application I was working on or b) boost was not linked against STLPort, but with the STL included with the compiler. To confirm this I looked at the dependencies of my project and the boost libraries (depends.exe on Windows, "otool -L" on OS X, otherwise "nm -j a.out | c++filt -_" and "nm -j a.out | c++filt-n" have been helpful. To solve this I specifically added the path the the STLPort includes (.h) first in the extra includes list (CFLAGS) and the path to the STLPort libraries (.[dll|dylib|so|a]) first in the extra libaries list (LDFLAGS). -- Matthew Peltzer -- goochrules@gmail.com
goochrules! <goochrules@gmail.com> writes:
On Mon, 23 Aug 2004 23:32:14 +0200, Nicholas Cain <nik.cain.boost@noos.fr> wrote:
I saw yours and Davids posts, and thought it looked the same, but then I realised yours was std::allocator< ... etc, while mine is _STL::allocator<... . I find that when I use the normal std everything works, but not when I try to use STLPort, so I'm confident I'm linking to the libraries, but they don't contain_STL::allocator<boost::function_base> I don't know if this is a problem in the way I built boost or STLPort, or with my makefile or environment.
thanks for noticing though!
nik
I've seen this exact problem on Windows, in various forms: basically one of a) the application I was working on or b) boost was not linked against STLPort, but with the STL included with the compiler.
To confirm this I looked at the dependencies of my project and the boost libraries (depends.exe on Windows, "otool -L" on OS X, otherwise "nm -j a.out | c++filt -_" and "nm -j a.out | c++filt-n" have been helpful.
To solve this I specifically added the path the the STLPort includes (.h) first in the extra includes list (CFLAGS) and the path to the STLPort libraries (.[dll|dylib|so|a]) first in the extra libaries list (LDFLAGS).
When you build the Boost libraries for use with STLPort, pass the -d+2 option so you can see the command lines bjam issues. Make sure you replicate the STLPort-related -D options when compiling your own code. In particular, one of those options has an impact on what namespace the standard library ends up in. The most reliable way, of course, is to use Boost.Build to build your own project and reference the Boost project libraries. That will always make sure the options are compatible. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
goochrules! <goochrules@gmail.com> writes:
On Mon, 23 Aug 2004 23:32:14 +0200, Nicholas Cain <nik.cain.boost@noos.fr> wrote:
I saw yours and Davids posts, and thought it looked the same, but then I realised yours was std::allocator< ... etc, while mine is _STL::allocator<... . I find that when I use the normal std everything works, but not when I try to use STLPort, so I'm confident I'm linking to the libraries, but they don't contain_STL::allocator<boost::function_base> I don't know if this is a problem in the way I built boost or STLPort, or with my makefile or environment.
thanks for noticing though!
nik
I've seen this exact problem on Windows, in various forms: basically one of a) the application I was working on or b) boost was not linked against STLPort, but with the STL included with the compiler.
To confirm this I looked at the dependencies of my project and the boost libraries (depends.exe on Windows, "otool -L" on OS X, otherwise "nm -j a.out | c++filt -_" and "nm -j a.out | c++filt-n" have been helpful.
To solve this I specifically added the path the the STLPort includes (.h) first in the extra includes list (CFLAGS) and the path to the STLPort libraries (.[dll|dylib|so|a]) first in the extra libaries list (LDFLAGS).
When you build the Boost libraries for use with STLPort, pass the -d+2 option so you can see the command lines bjam issues. Make sure you replicate the STLPort-related -D options when compiling your own code. In particular, one of those options has an impact on what namespace the standard library ends up in.
The most reliable way, of course, is to use Boost.Build to build your own project and reference the Boost project libraries. That will always make sure the options are compatible.
The only -D options I saw were -DBOOST_THREAD_BUILD_DLL=1 and -D_STLP_USE_DYNAMIC_LIB=1 - aren't they for windows compilers only though? Anyway, I tried rearranging path orders on my makefile, and adding in the -Ds, but no luck still. I'm pretty much a beginner to makefiles, so whether I learn make or boost::build involves some investing some time either way, and I might as well do the boost::build way. Give me a few days and hopefully I'll get there. But I'd like to know I'm not wasting my time here - sticking in a using namespace _STL into the boost::threads example (see my earlier post) on linux *should* work, shouldn't it? nik
David Abrahams wrote:
goochrules! <goochrules@gmail.com> writes:
On Mon, 23 Aug 2004 23:32:14 +0200, Nicholas Cain <nik.cain.boost@noos.fr> wrote:
I saw yours and Davids posts, and thought it looked the same, but then I realised yours was std::allocator< ... etc, while mine is _STL::allocator<... . I find that when I use the normal std everything works, but not when I try to use STLPort, so I'm confident I'm linking to the libraries, but they don't contain_STL::allocator<boost::function_base> I don't know if this is a problem in the way I built boost or STLPort, or with my makefile or environment.
thanks for noticing though!
nik
I've seen this exact problem on Windows, in various forms: basically one of a) the application I was working on or b) boost was not linked against STLPort, but with the STL included with the compiler.
To confirm this I looked at the dependencies of my project and the boost libraries (depends.exe on Windows, "otool -L" on OS X, otherwise "nm -j a.out | c++filt -_" and "nm -j a.out | c++filt-n" have been helpful.
To solve this I specifically added the path the the STLPort includes (.h) first in the extra includes list (CFLAGS) and the path to the STLPort libraries (.[dll|dylib|so|a]) first in the extra libaries list (LDFLAGS).
When you build the Boost libraries for use with STLPort, pass the -d+2 option so you can see the command lines bjam issues. Make sure you replicate the STLPort-related -D options when compiling your own code. In particular, one of those options has an impact on what namespace the standard library ends up in.
The most reliable way, of course, is to use Boost.Build to build your own project and reference the Boost project libraries. That will always make sure the options are compatible.
After a day of persistence I've got my projects to build with bjam, although I still get the error: undefined reference to `boost::thread::thread[in-charge](boost::function0<void, _STL::allocator<boost::function_base> > const&)' However, I'm not sure that I'm implementing your last suggestion properly. Do I just have a dependency on the libboost_thread shared object, and Boost.Build figures it out the options, or do I need to bring in something from the threads src folder (like threads.jam or something)? - at the moment my bjam files look like; -------in /Development -------- project mainProj : requirements <threading>multi <include>/usr/include/python2.3 <include>/usr/local/include/stlport <include>Common <include>Common/ErrorReporting <include>/usr/local/include/boost-1_31 <include>/home/ncain/xerces-c-src_2_5_0/include ; build-project Core/XMLConfigParser ; build-project Core/ScriptingInterface ; build-project Core/TimedVariableQueue ; ---------------------------------- -------in /Development/Core/TimedVariableQueue/-------- project theTimedVariableQueue ; lib TimedVariableQueue : TimedVariableQueue.cpp : <include>../XMLConfigParser ; build-project TimedVariableQueueUnitTests ; ---------------------------------- -------in /Development/Core/TimedVariableQueue/TimedVariableQueueUnitTests---------- project theTimedVariableQueueUnitTest ; exe TimedVariableQueueUnitTest : TimedVariableQueueUnitTest.cpp /usr/local/lib/libstlport_gcc.a /usr/local/lib/libxerces-c.so ../../../lib/XMLConfigParser.so /usr/local/lib/libboost_thread-gcc-mt-p.so TimedVariableQueue.so : (that's a lazy sym link in the unittests folder) <include>../../TimedVariableQueue <include>../../XMLConfigParser ;
Nicholas Cain wrote:
David Abrahams wrote:
goochrules! <goochrules@gmail.com> writes: On Mon, 23 Aug 2004 23:32:14 +0200, Nicholas Cain
<nik.cain.boost@noos.fr> wrote:
I saw yours and Davids posts, and thought it looked the same, but then I realised yours was std::allocator< ... etc, while mine is _STL::allocator<... . I find that when I use the normal std everything works, but not when I try to use STLPort, so I'm confident I'm linking to the libraries, but they don't contain_STL::allocator<boost::function_base> I don't know if this is a problem in the way I built boost or STLPort, or with my makefile or environment.
thanks for noticing though!
nik
I've seen this exact problem on Windows, in various forms: basically one of a) the application I was working on or b) boost was not linked against STLPort, but with the STL included with the compiler.
To confirm this I looked at the dependencies of my project and the boost libraries (depends.exe on Windows, "otool -L" on OS X, otherwise "nm -j a.out | c++filt -_" and "nm -j a.out | c++filt-n" have been helpful.
To solve this I specifically added the path the the STLPort includes (.h) first in the extra includes list (CFLAGS) and the path to the STLPort libraries (.[dll|dylib|so|a]) first in the extra libaries list (LDFLAGS).
When you build the Boost libraries for use with STLPort, pass the -d+2 option so you can see the command lines bjam issues. Make sure you replicate the STLPort-related -D options when compiling your own code. In particular, one of those options has an impact on what namespace the standard library ends up in.
The most reliable way, of course, is to use Boost.Build to build your own project and reference the Boost project libraries. That will always make sure the options are compatible.
After a day of persistence I've got my projects to build with bjam, although I still get the error: undefined reference to `boost::thread::thread[in-charge](boost::function0<void, _STL::allocator<boost::function_base> > const&)'
However, I'm not sure that I'm implementing your last suggestion properly. Do I just have a dependency on the libboost_thread shared object, and Boost.Build figures it out the options, or do I need to bring in something from the threads src folder (like threads.jam or something)? ...
Something just crossed my mind - while looking at the bjam build with the -d+2 set, it seemed to have all the stlport paths etc. Does boost build with the gcc-stlport setting redefine _STL as std, and so even though the examples have std:: in them, it's really STLPort? (and I shouldn't be doing using namespace _STL)? nik
participants (4)
-
David Abrahams -
goochrules! -
Nicholas Cain -
Raj