From: SourceForge.net <no...@so...> - 2006-02-16 18:37:21
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3580458 By: sloisel Addendum: I have just confirmed that this behavior is reproducible without QT. The octave embedding example (http://octave.sourceforge.net/octave_embed.tar.gz) has the same problem. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2006-02-16 21:58:11
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3580768 By: chicares > QT frontend for Octave (it links against > liboctave) [...] suspect that liboctave sees a > different cerr and cout than my frontend does. [...] > If I do cerr.rdbuf(), the cerr in my client > is redirected, but not the one in Octave. Have you compiled both liboctave and your frontend with the same version of the compiler? Have you tried linking liboctave statically? I wonder whether the low-level C approach (open() and dup2()) would work better. > This occurs whether I use -Wl,subsystem,windows > or -Wl,subsystem,console.[...] > this behavior is reproducible without QT Is it reproducible in a non-GUI application? ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2006-02-16 23:35:21
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3580887 By: sloisel Hi Greg, Thanks for the quick reply. I will answer all your questions, but I have one important question to ask first: Can anyone show me a "hello world" example of redirecting one's own stdout/stderr to a pipe (like they do in all the SetStdHandle examples) but without the CreateProcess/fork? That would rock. > I wonder whether the low-level C approach > (open() and dup2()) would work better. Not a possibility (I need fast function calls from Octave back to the GUI for plotting.) > Is it reproducible in a non-GUI application? Yes (with the standard octave embedding example.) > Have you compiled both liboctave and your > frontend with the same version of the compiler? The entire tree (MinGW+liboctave) is a zip of David Bateman's tree. So yes. > Have you tried linking liboctave statically? I'm not sure how to do that but I'll give it a shot. We noticed that when we do "ls" at the octave prompt, a cmd.exe briefly pops up on the screen. So we figure that in addition to capturing cerr, we're going to need to capture stdout and stderr and otherwise pose as a console. So if anyone can show me how to do that (SetStdHandle?) without the CreateProcess/fork (I want to capture my *own* stdout) that would rock. Thanks again for the quick reply, Sébastien Loisel ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2006-02-17 00:00:18
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3580915 By: chicares >> I wonder whether the low-level C approach >> (open() and dup2()) would work better. > >Not a possibility (I need fast function calls >from Octave back to the GUI for plotting.) I meant using a low-level C approach for redirection, instead of the rdbuf() technique. It shouldn't be slower. It might conceivably be more robust. >> Is it reproducible in a non-GUI application? > > Yes (with the standard octave embedding > example.) Probably not many people here have built octave. A minimal standalone test case would be easier for others to work with. But, since you have a command-line build, try running it with this program: http://www.delorie.com/djgpp/dl/ofc/simtel/v2/djlsr203.zip/src/utils/redir.c ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2006-02-17 10:22:29
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3581473 By: sloisel > I meant using a low-level C approach for > redirection, instead of the rdbuf() technique. > It shouldn't be slower. It might conceivably be > more robust. That's a good idea but there's something I don't know how to do with that. Octave will write stuff to its cerr using <<, which will end up on stderr, which I can redirect to a pipe with dup2 or something. However, my code is sequential, but I'd like to put the stuff that octave prints to cerr in the output window as soon as possible. If I'm using rdbuf(), I can put a custom bufstream object there and call into my GUI code. How would I do this with low-level C streams? > Probably not many people here have built octave. I would guess zero people did because it's very alpha right now. David Bateman used to have a 100MB tarball on his web page (MinGW+octave in one tarball) but it's gone now. If you want I can locate that for you. > A minimal standalone test case would be easier Here goes: $ cat dll.h #ifdef BUILD_DLL /* DLL export */ #define EXPORT __declspec(dllexport) #else /* EXE import */ #define EXPORT __declspec(dllimport) #endif EXPORT void hello(void); $ cat hello.cpp #include <iostream> #include <fstream> #include "dll.h" int main () { std::streambuf *stdbuf=std::cout.rdbuf(); std::ofstream out("foo.txt"); std::cout.rdbuf(out.rdbuf()); hello(); std::cout.rdbuf(stdbuf); return 0; } $ cat dll.cpp #include <iostream> #include "dll.h" EXPORT void hello(void) { std::cout<<"Hello"; } $ cat build.sh #!/bin/sh g++ -c hello.cpp -o hello.o g++ -c -DBUILD_DLL dll.cpp -o dll.o g++ -shared -o message.dll dll.o -Wl,--out-implib,libmessage.a g++ -o hello.exe hello.o -L./ -lmessage By the way, this fails in both Cygwin and MinGW. (In both cases, "Hello" goes to the console instead of the file.) If I link with $ g++ hello2.cpp dll2.cpp -o hello2 it works ("Hello" goes to the file.) Cheers, Sebastien Loisel ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2006-02-17 13:16:29
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3581706 By: chicares Thank you for the minimal test case. Now I think I see the problem and how to solve it. We think of std::cout as a Singleton--the C++ standard seems to require that--but the standard doesn't address shared libraries. The app and the dll would naturally have distinct cout objects, in msw land at least, with the "nifty counter" method for implementing cout etc. Anyway, if you redirect the dll's cout, it works. There may be a more elegant way, but I think this does what you want: ['build.sh' unchanged; all other files changed, and artificially limited to fifty-character width so that this web board doesn't mangle them] C:/tmp/sloisel[0]$cat dll.h #ifdef BUILD_DLL # define EXPORT __declspec(dllexport) #else # define EXPORT __declspec(dllimport) #endif EXPORT std::streambuf* dll_cout_rdbuf(); EXPORT std::ostream& dll_cout(); EXPORT void hello(); C:/tmp/sloisel[0]$cat dll.cpp #include <iostream> #include "dll.h" EXPORT std::streambuf* dll_cout_rdbuf() {return std::cout.rdbuf();} EXPORT std::ostream& dll_cout() {return std::cout;} EXPORT void hello() {std::cout<<"Hello";} C:/tmp/sloisel[0]$cat hello.cpp #include <iostream> #include <fstream> #include "dll.h" int main() { std::cout << "app's stdout" << std::endl; std::ofstream out("foo.txt"); std::streambuf* appbuf = std::cout.rdbuf(out.rdbuf()); std::cout << "in file foo.txt" << std::endl; std::cout.rdbuf(dll_cout_rdbuf()); std::cout << "dll's stdout" << std::endl; std::streambuf* dllbuf = dll_cout().rdbuf(out.rdbuf()); hello(); dll_cout() << "\nshould be in file foo.txt" << std::endl; dll_cout().rdbuf(dllbuf); std::cout << "dll's stdout" << std::endl; std::cout.rdbuf(appbuf); std::cout << "app's stdout" << std::endl; } C:/tmp/sloisel[0]$./build.sh Creating library file: libmessage.a C:/tmp/sloisel[0]$./hello app's stdout dll's stdout dll's stdout app's stdout C:/tmp/sloisel[0]$cat foo.txt in file foo.txt Hello should be in file foo.txt ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2006-02-17 14:06:04
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3581781 By: sloisel > The app and the > dll would naturally have distinct cout objects, Doesn't sound that natural to me! Thanks for the workaround idea. I was in the middle of recompiling liboctave with such a workaround when I saw your reply. However, that's sort of a problem. I have the cooperation of the Octave people and I can get a patch merged in, but you know it adds a symbol to liboctave for a really poor reason. You don't suppose there's a way of getting the dll's cerr without adding these functions? Sébastien Loisel ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2006-02-17 15:11:44
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3581910 By: chicares >> The app and the >> dll would naturally have distinct cout objects, > >Doesn't sound that natural to me! GNU/Linux shared libraries differ from dlls. A search engine will find this quote: | The ELF scheme uses a single name space per | program, while the PE scheme uses a name space | per library on a page that seems otherwise inaccessible. Maybe that explains why your code that works on one OS doesn't work the same way on another. std::cout is an object that wraps a system resource: ultimately, a FILE* . I think our msw test cases show that you have two such objects, one in the app and the other in the dll. (We could presumably prove that by printing the addresses of the objects.) They may wrap the same resource, but they're distinct objects, with distinct get and put areas, etc. > You don't suppose there's a way of getting the > dll's cerr without adding these functions? I doubt there's any clean way other than adding at least one function--either to give the dll's cout to the application, or to change the dll's cout streambuf from the application. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2006-02-17 15:24:22
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3581971 By: sloisel > I doubt there's any clean way other than adding > at least one function Well, that sucks. The good news is that the workaround works, even though it means a one-line patch to octave. Cheers, Sébastien Loisel ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |