From: someproblems <oko...@ex...> - 2007-10-26 19:32:15
|
Hi, I'm going to be honest and say that after several years of on and off C++ programming, this is the first time I've actually solicited assistance. Normally I either figure it out myself or I look around online. But I'm going crazy here. I'm trying to build STLport for MinGW (I'm using Dev-C++) so I can use wide streams (since I found out they haven't been added to MinGW yet). For this purpose I'm using MSYS to process the makefiles. The setup is, the STLport folder, or STLport-4.6.2, is positioned as a subfolder in C:/MSYS. MinGW is in C:/MinGW. Following some old instructions I found on the net (http://www.codeguru.com/forum/showthread.php?t=247545) (http://alanning.freeshell.org/text/text.php?guide=make_STLport-4.5.3_with_mingw-2.4_and_gcc-3.2.htm), I've been using these commands with MSYS: cd c: cd STLport-4.6.2 cd src make -f gcc-mingw32.mak all make -f gcc-mingw32.mak install Both of these make commands hit errors. To begin with, I had, at the end of a long series of messages, the following: ../stlport/stl/_string.h:692: instantiated from `_STL::basic_string<_CharT, _Traits, _Alloc>& _STL::basic_string<_CharT, _Traits, _Alloc>::insert(size_t, const _CharT*, size_t) [with _CharT = char, _Traits = _STL::char_traits<char>, _Alloc = _STL::allocator<char>]' dll_main.cpp:188: instantiated from here ../stlport/stl/_string.h:790: error: 'struct _STL::basic_string<char, _STL::char_traits<char>, _STL::allocator<char> >' has no member named '_M_end_of_storage' ../stlport/stl/_string.h:799: error: 'struct _STL::basic_string<char, _STL::char_traits<char>, _STL::allocator<char> >' has no member named '_M_end_of_storage' ../stlport/stl/_string.h:805: error: 'struct _STL::basic_string<char, _STL::char_traits<char>, _STL::allocator<char> >' has no member named '_M_end_of_storage' make: *** [../lib/obj/MINGW32/ReleaseD/dll_main.o] Error 1 I was able to fix this by modifying C:\msys\STLport-4.6.2\stlport\stl_user_config.h, and removing the comment marks from // define _STLP_NO_OWN_IOSTREAMS 1 I'm not sure that's the right thing to have done (the guy who recommended it, in the first link I gave, later rescinded his suggestion). Still, it worked... Anyways, I ran MSYS again and this time I got this: ../stlport/stl/_string.h:98: error: call of overloaded `find_if(const char* const&, const char* const&, _STL::_Eq_char_bound<std::char_traits<char> >)' is ambiguous ../stlport/stl/_algobase.c:194: note: candidates are: _InputIter _STL::find_if(_InputIter, _InputIter, _Predicate) [with _InputIter = const char*, _Predicate = _STL::_Eq_char_bound<std::char_traits<char> >] c:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/stl_algo.h:330: note: _InputIterator std::find_if(_InputIterator, _InputIterator, _Predicate) [with _InputIterator = const char*, _Predicate = _STL::_Eq_char_bound<std::char_traits<char> >] make: *** [../lib/obj/MINGW32/ReleaseD/dll_main.o] Error 1 I'm assuming this is a reference to what include path is used, or what the environment variables pointing to MinGW are. My set environment variables are: MINGDIR c:\mingw %PATH% c:\mingw\bin PATH c:\mingw\bin Which are all set in both User variables and System variables. Well, with PATH I just added the MinGW directory to the end of the list in System variables because there was already stuff there. I tried editing C:\msys\STLport-4.6.2\stlport\config\stl_gcc.h and changing references to "../g++-v3" to "C:/MinGW/include/c++/3.4.5/", as well as several other variations, but it didn't work. Anyway, I have no idea what to do next. Any help would be much appreciated. -- View this message in context: http://www.nabble.com/Building-STLport-on-MinGW-tf4699301.html#a13433840 Sent from the MinGW - User mailing list archive at Nabble.com. |
From: Vincent T. <vt...@un...> - 2007-10-26 20:21:26
|
Hey, On Fri, 26 Oct 2007, someproblems wrote: > I'm trying to build STLport for MinGW (I'm using Dev-C++) so I can use wide > streams (since I found out they haven't been added to MinGW yet). For this > purpose I'm using MSYS to process the makefiles. The setup is, the STLport > folder, or STLport-4.6.2, is positioned as a subfolder in C:/MSYS. MinGW is > in C:/MinGW. STLport 4.6.2 is not supported anymore. Is there a reason not to try to compile STLport 5.1.* About STLport 5.1.3, there is a compilation problem with MinGW + MSYS. There is a patch somewhere in svn. I don't know if STLport 5.1.4 fix that problem. regards Vincent Torri |
From: Tim S. <sta...@ve...> - 2007-10-26 21:15:46
|
someproblems wrote: > > cd c: > cd STLport-4.6.2 > cd src > make -f gcc-mingw32.mak all > make -f gcc-mingw32.mak install > > Both of these make commands hit errors. To begin with, I had, at the end of > a long series of messages, the following: > I would suggest trying STLPort 5.0, it works with MinGW GCC 3.4.5. http://sourceforge.net/project/showfiles.php?group_id=146814&package_id=162032&release_id=483468 I had some issues with STLPort 5.1. Tim S |
From: someproblems <oko...@ex...> - 2007-10-26 23:52:04
|
Thanks for the responses guys. The reason I was using STLport 4.6.2 was because that's the version listed as the latest release on stlport.org. Anyways, I've now tried both STLport 5.1.4 and STLport 5.0.3, using these steps: make -f gcc-mingw32.mak clean make -f gcc-mingw32.mak install And I've also tried make -f gcc-mingw32.mak depend make -f gcc-mingw32.mak install In both cases, everything seems to go well and I get no error messages, but I can't connect the libraries, etc., to Dev-C++, or at least when I do they have no effect. I've tried sending this as a compiler parameter: -ID:\MinGW\include\STLport\stlport -lstlport_mingw32_static (I've since moved the STLport external directory to C:\Mingw\include) and I've tried adding the inner stlport directory to the top of the list in C and C++ includes in the compiler options (the only other item there at the moment is MinGW's include dir), in addition to adding ../../../../MinGW/include/STLport/lib/libstlport.5.0.dll.a ../../../../MinGW/include/STLport/lib/libstlportg.5.0.dll.a ../../../../MinGW/include/STLport/lib/libstlportstlg.5.0.dll.a to Dev-C++'s Linker list, and nothing! Furthermore, and probably explaining all that, the tests the STLport INSTALL file says to do after the installation don't work: cd build/test/unit make -f gcc.mak install The make command fails, ending with a bizarre and unreadable message that seems to indicate that everything is failing: obj/gcc/shared/sstream_test.o:sstream_test.cpp:(.text$_ZN8stlp_std10_M_get_numIc NS_11char_traitsIcEEjEEiRNS_13basic_istreamIT_T0_EERT1_[int stlp_std::_M_get_num <char, stlp_std::char_traits<char>, unsigned int>(stlp_std::basic_istream<char, stlp_std::char_traits<char> >&, unsigned int&)]+0x3f6): undefined reference to ` _imp___ZN8stlp_std8ios_base16_M_throw_failureEv' obj/gcc/shared/sstream_test.o:sstream_test.cpp:(.text$_ZN8stlp_std18basic_string streamIcNS_11char_traitsIcEENS_9allocatorIcEEEC1ERKNS_12basic_stringIcS2_S4_EEi[ stlp_std::basic_stringstream<char, stlp_std::char_traits<char>, stlp_std::alloca tor<char> >::basic_stringstream(stlp_std::basic_string<char, stlp_std::char_trai ts<char>, stlp_std::allocator<char> > const&, int)]+0x10a): undefined reference to `_imp___ZN8stlp_std8ios_baseD2Ev' obj/gcc/shared/string_test.o:string_test.cpp:(.text$_ZN8stlp_stdlsIcNS_11char_tr aitsIcEENS_9allocatorIcEEEERNS_13basic_ostreamIT_T0_EES9_RKNS_12basic_stringIS6_ S7_T1_EE[stlp_std::basic_ostream<char, stlp_std::char_traits<char> >& stlp_std:: operator<< <char, stlp_std::char_traits<char>, stlp_std::allocator<char> >(stlp_ std::basic_ostream<char, stlp_std::char_traits<char> >&, stlp_std::basic_string< char, stlp_std::char_traits<char>, stlp_std::allocator<char> > const&)]+0x209): undefined reference to `_imp___ZN8stlp_std8ios_base16_M_throw_failureEv' obj/gcc/shared/string_test.o:string_test.cpp:(.text$_ZN8stlp_stdlsIcNS_11char_tr aitsIcEENS_9allocatorIcEEEERNS_13basic_ostreamIT_T0_EES9_RKNS_12basic_stringIS6_ S7_T1_EE[stlp_std::basic_ostream<char, stlp_std::char_traits<char> >& stlp_std:: operator<< <char, stlp_std::char_traits<char>, stlp_std::allocator<char> >(stlp_ std::basic_ostream<char, stlp_std::char_traits<char> >&, stlp_std::basic_string< char, stlp_std::char_traits<char>, stlp_std::allocator<char> > const&)]+0x283): undefined reference to `_imp___ZN8stlp_std8ios_base16_M_throw_failureEv' obj/gcc/shared/string_test.o:string_test.cpp:(.text$_ZN8stlp_stdlsIcNS_11char_tr aitsIcEENS_9allocatorIcEEEERNS_13basic_ostreamIT_T0_EES9_RKNS_12basic_stringIS6_ S7_T1_EE[stlp_std::basic_ostream<char, stlp_std::char_traits<char> >& stlp_std:: operator<< <char, stlp_std::char_traits<char>, stlp_std::allocator<char> >(stlp_ std::basic_ostream<char, stlp_std::char_traits<char> >&, stlp_std::basic_string< char, stlp_std::char_traits<char>, stlp_std::allocator<char> > const&)]+0x3ab): undefined reference to `_imp___ZN8stlp_std8ios_base16_M_throw_failureEv' obj/gcc/shared/vector_test.o:vector_test.cpp:(.text$_ZNK8stlp_std12_Vector_baseI iNS_9allocatorIiEEE21_M_throw_length_errorEv[stlp_std::_Vector_base<int, stlp_st d::allocator<int> >::_M_throw_length_error() const]+0xc): undefined reference to `_imp___ZN8stlp_std24__stl_throw_length_errorEPKc' obj/gcc/shared/vector_test.o:vector_test.cpp:(.text$_ZNK8stlp_std12_Vector_baseI iNS_9allocatorIiEEE21_M_throw_out_of_rangeEv[stlp_std::_Vector_base<int, stlp_st d::allocator<int> >::_M_throw_out_of_range() const]+0xc): undefined reference to `_imp___ZN8stlp_std24__stl_throw_out_of_rangeEPKc' collect2: ld returned 1 exit status make: *** [obj/gcc/shared/stl_unit_test.exe] Error 1 I couldn't find anything useful on SVN (http://stlport.svn.sourceforge.net/viewvc/stlport/) either; in fact, I wouldn't even know where to begin to look. Also, when the installation guide talks about building STLport as a static library, does it mean I can condense the entire folder and all its contents to a single linkable .a file? How would I do that? I tried appending release-static one space after the install command when I was using make, but that doesn't seem to have had any effect. Sorry for the continued questions, but I'm very confused here. If anyone's built STLport personally using MinGW and MSYS, could you post the steps you took? -- View this message in context: http://www.nabble.com/Building-STLport-on-MinGW-tf4699301.html#a13437400 Sent from the MinGW - User mailing list archive at Nabble.com. |
From: Tim S. <sta...@ve...> - 2007-10-27 01:15:04
|
I wrote done these steps the last time I built STLport-5.0. Tim S cd /mingw/STLport-5.0/build/lib configure --compiler gcc make -f gcc.mak clean make -f gcc.mak install How I use STLPort 5.1 to build wxWidgets 2.9.x mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 CXXFLAGS="-isystem C:\Apps\MinGW_GCC3_STLPort\STLport-5.1\stlport -isystem C:\Apps\MinGW_GCC3_STLPort\include" LDFLAGS="-LC:\Apps\MinGW_GCC3_STLPort\STLport-5.1\lib -lstlport.5.1.dll" I had to add CXXFLAGS and LDFLAGS to use STLPort. Note, stlport must be before normal MinGW include folder in the search list. I used -isystem which seems to do it OK. Tim S |
From: Greg C. <gch...@sb...> - 2007-10-27 01:33:12
|
On 2007-10-27 01:14Z, Tim Stahlhut wrote: > I wrote done these steps the last time I built STLport-5.0. Thanks for posting your [snipped] recipe. What I'd really like to ask is... > How I use STLPort 5.1 to build wxWidgets 2.9.x ...what advantage do you find in building wx with stlport instead of with libstdc++? Is it that you can link the C++ standard library as a dll? Have you noticed any other advantages or disadvantages? I use wx heavily, so I'm curious. |
From: Vincent T. <vt...@un...> - 2007-10-27 06:24:20
|
On Sat, 27 Oct 2007, Greg Chicares wrote: > ...what advantage do you find in building wx with stlport > instead of with libstdc++? Is it that you can link the C++ > standard library as a dll? Have you noticed any other > advantages or disadvantages? I use wx heavily, so I'm > curious. I use STLport only for portability. You can maybe try to see if some implementations are not better with STLport. For example, see: http://complement.sourceforge.net/compare.pdf (it's on http://stlport.sourceforge.net/, news from 2006-10-18) there may be other improvments. See etc/ChangeLog-5.1 regards Vincent Torri |
From: Tim S. <sta...@ve...> - 2007-10-27 01:47:41
|
Greg Chicares wrote: > > ...what advantage do you find in building wx with stlport > instead of with libstdc++? Is it that you can link the C++ > standard library as a dll? Have you noticed any other > advantages or disadvantages? I use wx heavily, so I'm > curious. I have not ever used it; I am working with code::blocks and wished to see what areas of it was not STL valid code. It was a lot of code. I build and fix wxWidgets for many minor compile and link issues. I use it mainly with wxWidgets samples and Code::Blocks. Tim S |
From: Vincent T. <vt...@un...> - 2007-10-27 06:17:45
|
On Fri, 26 Oct 2007, someproblems wrote: > > Thanks for the responses guys. The reason I was using STLport 4.6.2 was > because that's the version listed as the latest release on stlport.org. the new home page is now http://stlport.sourceforge.net/ > Anyways, I've now tried both STLport 5.1.4 and STLport 5.0.3, using these > steps: > > make -f gcc-mingw32.mak clean > make -f gcc-mingw32.mak install > > And I've also tried > > make -f gcc-mingw32.mak depend > make -f gcc-mingw32.mak install I use gcc.mak when I compile with MSYS, I've never used dev-c++ what I do : make -f gcc.mak depend make -f gcc.mak install If I already have compiled STLport and I want to recompile it: make -f gcc.mak clobber make -f gcc.mak depend make -f gcc.mak install > In both cases, everything seems to go well and I get no error messages, but > I can't connect the libraries, etc., to Dev-C++, or at least when I do they > have no effect. I've tried sending this as a compiler parameter: > > -ID:\MinGW\include\STLport\stlport -lstlport_mingw32_static have you tried to add -LD:\MinGW\include\STLport\lib ? anyway, afaik, the library is only used for iostream. If you want to use iostream from gcc and not STLport, no need to use the STLport library. If you want to use iostream from STLport, I would suggest that you link against the shared library (at least, I've had a lot of problems when I linked against the static lib). And that's what he lead dev of STLport give to me as advice. regards Vincent Torri |
From: someproblems <oko...@ex...> - 2007-10-27 23:05:54
|
Sorry, in my last message I meant to put gcc.mak instead of gcc-mingw32.mak. I finally decided to just move STLport to its own directory in C:\ because I was getting confused where it was and which copy of the folder I was using. I've now tried three different configurations with MSYS: Attempt 1: cd c:/STLport/build/lib make -f gcc.mak depend make -f gcc.mak install Attempt 2: cd c:/STLport/build/lib configure --compiler gcc make -f gcc.mak clean make -f gcc.mak install Attempt 3: cd c:/STLport/build/lib ./configure make -f gcc.mak depend make -f gcc.mak install In all three cases, everything works fine except when I go on to test it with cd c:/STLport/build/test/unit make -f gcc.mak install In which case I get very bizarre and unreadable errors like I said in the last message. Maybe my problem is that there's some component I don't have installed. Does STLport require anything else besides MinGW and a make program (or in my case MSYS) to get it running? I updated my MinGW installation with the Automated MinGW Installer yesterday before I started any of this. My installed packages: binutils-2.17.50-20060824-1.tar.gz gcc-core-3.4.5-20060117-1.tar.gz gcc-g++-3.4.5-20060117-1.tar.gz mingw-runtime-3.13.tar.gz w32api-3.10.tar.gz At this point, I'm trying to cut out as many unnecessary things as possible, so I've removed Dev-C++ from consideration for the moment by just directly passing the parameters to g++.exe. Using the Windows command line, I've tried both: g++ C:\test.cpp -o test -ID:\STLport\stlport -ID:\MinGW\include -mthreads -LD:\STLport\lib -LD:\MinGW\lib -libstlport.5.1.dll.a And the same thing with an -isystem before each -ID, as suggested in Tim's message where he mentions his wxWindows makefile (I think it was a makefile). I'm using -mthreads because in STLport's INSTALL file it mentions that using STLport means your exe should be multi-threaded, and -mthread and -pthread show unrecognized command errors. Anyway, what happens is that I get this error: C:\MinGW\bin>g++ C:\test.cpp -o test -ID:\STLport\stlport -ID:\MinGW\include -mt hreads -LD:\STLport\lib -LD:\MinGW\lib -libstlport.5.1.dll.a c:\mingw\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot fin d -libstlport.5.0.dll.a collect2: ld returned 1 exit status Since I've been trying both STLport 5.0.3 and STLport 5.1.4, I've used libstlport.5.0.dll.a for the former and libstlport.5.1.dll.a for the latter, but neither one works. I've also tried a variety of different commands in place of that final lib reference, including cutting out the "lib" section of the name and replacing it with just "l", and just using -lstlport; g++ displays the same library-not-found message for all of them. The libraries, though, are right there in C:\STLport\lib. I don't know what's wrong. I'm having a lot of trouble finding good information on compiler flags and command line syntax for MinGW, too. Best I could do was this: http://www.cs.chalmers.se/~augustss/hbc/compiling.html. Incidentally, this is my test .cpp: #define UNICODE #include <windows.h> #include <iostream> int main(int argc, char *argv[]) { std::cout << "Cout."; //std::wcout << "Wcout."; getchar(); return 0; } The whole reason I'm using STLpoint is so I can use wide streams, like wcout. I've commented it out for the time being because STLport isn't linking correctly, so the compiler has no clue what wcout is. -- View this message in context: http://www.nabble.com/Building-STLport-on-MinGW-tf4699301.html#a13448397 Sent from the MinGW - User mailing list archive at Nabble.com. |
From: Greg C. <gch...@sb...> - 2007-10-28 02:48:12
|
On 2007-10-27 23:05Z, someproblems wrote: > > I'm having a lot of trouble finding good information on compiler flags and > command line syntax for MinGW, too. Best I could do was this: > http://www.cs.chalmers.se/~augustss/hbc/compiling.html. You're using C++, but isn't that Haskell documentation? Try this: http://www.google.com/search?q=gcc+manual |
From: someproblems <oko...@ex...> - 2007-10-28 03:32:43
|
It's Haskell, but it contains several of the same flags. I meant that statement ironically to indicate that I wasn't able to find anything better than that. I actually just searched for gcc compiler flags and found several pretty helpful pages -- for some reason I was thinking before that just because there are a few differences, gcc and MinGW would have mostly different flags, so I only used MinGW, not gcc, as a search term. Greg Chicares-2 wrote: > > On 2007-10-27 23:05Z, someproblems wrote: >> >> I'm having a lot of trouble finding good information on compiler flags >> and >> command line syntax for MinGW, too. Best I could do was this: >> http://www.cs.chalmers.se/~augustss/hbc/compiling.html. > > You're using C++, but isn't that Haskell documentation? Try this: > > http://www.google.com/search?q=gcc+manual -- View this message in context: http://www.nabble.com/Building-STLport-on-MinGW-tf4699301.html#a13449783 Sent from the MinGW - User mailing list archive at Nabble.com. |
From: Vincent T. <vt...@un...> - 2007-10-28 07:19:20
|
On Sat, 27 Oct 2007, someproblems wrote: > Attempt 1: > > cd c:/STLport/build/lib > make -f gcc.mak depend > make -f gcc.mak install this is the good one > Attempt 2: > > cd c:/STLport/build/lib > configure --compiler gcc > make -f gcc.mak clean > make -f gcc.mak install > > Attempt 3: > > cd c:/STLport/build/lib > ./configure > make -f gcc.mak depend > make -f gcc.mak install calling configure is useless. I've never used it and it works perfectly. Nevertheless, use clobber instead of clean, when you rebuild. > cd c:/STLport/build/test/unit > make -f gcc.mak install > > In which case I get very bizarre and unreadable errors like I said in the > last message. i've never compiled the unit tests, so I can't say much. > At this point, I'm trying to cut out as many unnecessary things as possible, > so I've removed Dev-C++ from consideration for the moment by just directly > passing the parameters to g++.exe. Using the Windows command line, I've > tried both: > > C:\MinGW\bin>g++ C:\test.cpp -o test -ID:\STLport\stlport -ID:\MinGW\include > -mt > hreads -LD:\STLport\lib -LD:\MinGW\lib -libstlport.5.1.dll.a > c:\mingw\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot > fin > d -libstlport.5.0.dll.a > collect2: ld returned 1 exit status in a MSYS terminal: C:\MinGW\bin> g++ -mthreads -o test c:\test.cpp -ID:\STLport\stlport D:\STLport\lib\stlport.5.1.dll It should work. -L ise useless if you compile against the shared lib. why did you put test.cpp in the bin dir ? I would put it in the HOME dir. > > #define UNICODE > #include <windows.h> is windows.h necessary in that test ? > #include <iostream> > > int main(int argc, char *argv[]) > { > std::cout << "Cout."; > //std::wcout << "Wcout."; > > getchar(); > return 0; > } hth Vincent Torri |
From: John B. <joh...@ho...> - 2007-10-28 10:56:18
|
On Sat, 27 Oct 2007 16:05:51 -0700, someproblems wrote: > > C:\MinGW\bin>g++ C:\test.cpp -o test -ID:\STLport\stlport -ID:\MinGW\incl= ude > -mt > hreads -LD:\STLport\lib -LD:\MinGW\lib -libstlport.5.1.dll.a > c:\mingw\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: can= not > fin > d -libstlport.5.0.dll.a > collect2: ld returned 1 exit status Did you copy-and-paste this command? Not that it really matters, but you are running g++ in C:\MinGW\bin, but you are adding D:\MinGW\include and D:\MinGW\lib to your search paths. You asked for 5.1 but it tells you that it cannot find 5.0. You say: >The libraries, > though, are right there in C:\STLport\lib. I don't know what's wrong. but you add D:\STLport\stlport and D:\STLport\lib to your search paths. Anyway: Assuming that: STLport 5.1 include files are in D:\STLport\stlport STLport 5.1 libraries are in D:\STLport\lib You have a working MinGW installation in C:\MinGW C:\MinGW\bin is not in your %PATH%, but Your current directory is C:\MinGW\bin then: g++ C:\test.cpp -o test -ID:\STLport\stlport -mthreads -LD:\STLport\lib -lstlport.5.1 should work -l expands to -libname.a (among other things), so that -lkernel32 =3D libkernel32.a, so -libstlport.5.1.dll.a tells gcc to try filenames such as: libibstlport.5.1.dll.a.dll.a libibstlport.5.1.dll.a.a etc. _________________________________________________________________ Climb to the top of the charts!=A0 Play Star Shuffle:=A0 the word scramble = challenge with star power. http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_oc= t= |
From: someproblems <oko...@ex...> - 2007-10-28 21:49:26
|
Very good news: a large part of my problems are fixed. As John Brown pointed out: why am I using the D:\ drive? Answer: I'm not. Not knowing the proper g++ syntax, I copied commands off the net from people who were using different drive letters than I am, assuming the usage of the drive letters was part of the commands. It seems ridiculous in retrospect that I didn't realize -- and I did notice, but I just sort of assumed that -ID:\Mingw\etc defaulted to the base drive, then MinGW from there. Looking back, it's imbecilic, but I saw a couple different people using it, I assumed the -I: variant was for GCC only, not MinGW, and the usage stuck. I thought D stood for directory. Ah well. So -ID commands becomes -I and the -LD become -L. I was really hoping that would be the end of it, but there are two further incidents. My current command line, by the way: g++ test.cpp -o test -Wall -mthreads -IC:\STLport\stlport -LC:\STLport\lib -lstlport.5.1 First of all, running test.exe produces this error message box: "This application has failed to start because libstlport.5.1.dll was not found." I managed to fix that by one of two methods: copying libstlport.5.1.dll into the MinGW\bin directory, or by adding C:\STLport\bin to my PATH. According to the INSTALL file, this indicates that I'm using the shared library. Does that mean I have to heft this 600KB DLL file around with every copy of my program? Second incident. Once the DLL has been moved, very very bizarre things happen with wcout. wfstream works fine, cout works fine. But quite simply, what happens is that regardless of where they were sent, wcout messages only show up at the end of the program, just before the return, after everything else but in the order in which they were sent. The first wcout message will have its first character sent in the proper place, but the rest of the message will only appear later. It's crazy. Here's the C++ file. #include <iostream> #include <string> #include <cstdio> using std::cout; using std::wcout; using std::string; using std::wstring; using std::wfstream; using std::ios; int main(int argc, char *argv[]) { cout << "\n1)Initial cout.\n"; cout << ">>"; wcout << L"2)First wcout"; cout << "<<\n"; wstring wstringTest = L"3)First wstring.\n"; wcout << wstringTest; string stringTest = "4)First string.\n"; cout << stringTest; wcout << L"5)Second wcout.\n"; wstring wstringTest2 = L"6)Second wstring.\n"; wcout << wstringTest2; string stringTest2 = "7)Second string.\n"; cout << stringTest2; cout << "......End of program.\n"; getchar(); return 0; } Here's the command line extract (I'm running the program from the command line, so the window won't close after I finish running it; you'll see why in a second). C:\MinGW\bin>g++ test.cpp -o test -Wall -mthreads -IC:\STLport\stlport -LC:\STLport\lib -lstlport.5.1 C:\MinGW\bin>test 1)Initial cout. >>2<< 4)First string. 7)Second string. ......End of program. (I'm typing this from the command line to end getchar().) )First wcout3)First wstring. 5)Second wcout. 6)Second wstring. As you can see, the "2" of the first wcout is flanked by >> << symbols, while the rest of the string appears only later minus the 2. The rest of the wcouts just appear at the end of the program in chronological order. I can only conclude that there's something horribly wrong here. A couple answers to previous questions: John Brown wrote: > > Did you copy-and-paste this command? Not that it really matters, but you > are running g++ in C:\MinGW\bin, but you are adding D:\MinGW\include > and D:\MinGW\lib to your search paths. You asked for 5.1 but it tells you > that it cannot find 5.0. > Yeah, copy and paste. I didn't realize that mistake until after I sent the message. Vincent Torri-2 wrote: > > why did you put test.cpp in the bin dir ? I would put it in the HOME dir. > No reason in particular. As you can see from the latest command line entry, I ended up moving it to the MinGW\bin dir after all. -- View this message in context: http://www.nabble.com/Building-STLport-on-MinGW-tf4699301.html#a13458330 Sent from the MinGW - User mailing list archive at Nabble.com. |
From: <ra...@ed...> - 2007-10-28 22:04:58
|
Hello! > using std::cout; using std::wcout; using std::string; using std::wstring; > using std::wfstream; using std::ios; Havn't tested it but "using std" should be enough? > int main(int argc, char *argv[]) > { > cout << "\n1)Initial cout.\n"; > > cout << ">>"; > wcout << L"2)First wcout"; > cout << "<<\n"; > > wstring wstringTest = L"3)First wstring.\n"; > wcout << wstringTest; [...] Please don't use "\n" for line formatting in output streams - especially not under Windows/DOS. Please use std::endl instead. Good chance that this does correctly handle new line character sequences and internal buffering. -- Gruß... Tim (never worked with STLport though). |
From: John B. <joh...@ho...> - 2007-10-28 22:37:55
|
On Sun, 28 Oct 2007 14:49:17 -0700, someproblems wrote: > > > Very good news: a large part of my problems are fixed. As John Brown poin= ted > out: why am I using the D:\ drive? Answer: I'm not. Not knowing the prope= r > g++ syntax, I copied commands off the net from people who were using > different drive letters than I am, assuming the usage of the drive letter= s > was part of the commands. OK. I didn't realize that the lack of knowledge was as bad as that. You can= get a summary of gcc command line options like this: gcc -v --help> gcchelp.txt 2>&1 This will redirect all the output of gcc -v --help (verbose help) into gcch= elp.txt. I should probably point out that spaces are not required between options and their arguments, so that gcc -IC:\STLport\stlport /* add C:\STLport\stlport to INCLUDE search path *= / is the same as gcc -I C:\STLport\stlport > > > I was really hoping that would be the end of it, but there are two furthe= r > incidents. My current command line, by the way: > > g++ test.cpp -o test -Wall -mthreads -IC:\STLport\stlport -LC:\STLport\li= b > -lstlport.5.1 > > First of all, running test.exe produces this error message box: "This > application has failed to start because libstlport.5.1.dll was not found.= " I > managed to fix that by one of two methods: copying libstlport.5.1.dll int= o > the MinGW\bin directory, or by adding C:\STLport\bin to my PATH. Accordin= g > to the INSTALL file, this indicates that I'm using the shared library. Do= es > that mean I have to heft this 600KB DLL file around with every copy of my > program? > Assuming that when you built STLPort, you built static libraries as well as= DLLs, then add -static to your command line. Gcc tries to link to dynamic librari= es first, so that if you have libstlport.5.1.a (static library) and libstlport= .5.1.dll.a (import library for linking to DLL), then -lstlport.5.1 will match the .dll= .a file. The -static flag tells it to prefer static libraries. > Second incident. Once the DLL has been moved, very very bizarre things > happen with wcout. wfstream works fine, cout works fine. But quite simply= , > what happens is that regardless of where they were sent, wcout messages o= nly > show up at the end of the program, just before the return, after everythi= ng > else but in the order in which they were sent. Sorry, can't help. I have never used STLport. _________________________________________________________________ Windows Live Hotmail and Microsoft Office Outlook =96 together at last. =A0= Get it now. http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=3DCL10062= 6971033= |
From: someproblems <oko...@ex...> - 2007-10-30 06:35:33
|
Folks: thank you all for replying. Mystery's solved. John and Tim solved both my ridiculous problems. I'm wcouting up a storm in here. -static didn't work, but adding a STLport-specific define tag with an installation that included the static libs prevents the need to include the DLL. cd /c/STLport/build/lib make -f gcc.mak depend make -f gcc.mak install-release-static make -f gcc.mak install-dbg-static make -f gcc.mak install-stldbg-static ... g++ test.cpp -o test -Wall -mthreads -I C:\STLport\stlport -L C:\STLport\lib -lstlport.5.1 -D _STLP_USE_STATIC_LIB John Brown wrote: > > OK. I didn't realize that the lack of knowledge was as bad as that. You > can get a > summary of gcc command line options like this: > gcc -v --help> gcchelp.txt 2>&1 > Yeah, I was confused to begin with, and since you folks were copying my usage of -ID and -LD, I thought it was the right thing to do after all. Outside of basic testing for curiosity's sake, until yesterday I had never used GCC directly at all, always just relying on the IDE's include/library sections. I didn't know the first thing about any of GCC's flags except -o and -Wall. I guess I assumed that I would get a directory-doesn't-exist error (my DVD drive doesn't have a STLport directory), and I didn't realize I was using the D drive because based on some usage I'd seen I thought that -LD was for linking to library directories and -L was for linking to the libraries themselves. And, I kind of expected for there to be a space between the command and the start of the drive letter, the way people usually put a space between -o and the exe filename. I've generally always used MinGW, but I've used it just like I would any other IDE-combo-compiler, not from the command line. Tim Teulings wrote: > > Havn't tested it but "using std" should be enough? > using namespace std? Sure, doesn't matter. I just prefer to tabulate exactly what features I'm using. Tim Teulings wrote: > > Please don't use "\n" for line formatting in output streams - especially > not > under Windows/DOS. Please use std::endl instead. Good chance that this > does > correctly handle new line character sequences and internal buffering. > Thanks -- you're completely correct. It normally never matters because I'm just outputting ASCII. I've since learned that it's a classic problem, outputting strings with wide characters on a traditional console, even with wcout. I'm done. Thank you all for helping me overcome my problems, which were, in order: -Using an incorrect version of the software because I clicked on the first Google search result instead of the third and went to the old, no longer updated official site. -Having next to no knowledge of GCC syntax and using the incorrect drive letter, making all my tests invalid. -Not having known the practical difference between std::endl and '\n' for Unicode. I ended up spending countless trying a ton of different build configurations and reading old and generally misleading info on the net. Pretty severe penance for my deficiencies in GCC flags and std::endl knowledge, I think. -- View this message in context: http://www.nabble.com/Building-STLport-on-MinGW-tf4699301.html#a13483163 Sent from the MinGW - User mailing list archive at Nabble.com. |