Summary: | wxWidgets not enabling wxUSE_STD_IOSTREAM | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Tommy McDaniel <tommstein> |
Component: | [OLD] Library | Assignee: | Gentoo wxWidgets project <wxwidgets> |
Status: | RESOLVED INVALID | ||
Severity: | blocker | CC: | leio, tommstein |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Sample file that doesn't compile
config.log configure output |
Description
Tommy McDaniel
2005-07-10 09:10:27 UTC
Created attachment 63075 [details]
Sample file that doesn't compile
Try to compile with: g++ `wx-config --cxxflags --libs` -o wxtest wxtest.cpp
My output is:
wxtest.cpp:11: error: ISO C++ forbids declaration of `wxLogStream' with no type
wxtest.cpp:11: error: expected `;' before '*' token
wxtest.cpp: In member function `virtual bool App::OnInit()':
wxtest.cpp:17: error: `log_stream_ptr' undeclared (first use this function)
wxtest.cpp:17: error: (Each undeclared identifier is reported only once for
each function it appears in.)
wxtest.cpp:17: error: `wxLogStream' has not been declared
wxUSE_STD_IOSTREAM is default in 2.6.1. Just not in case of cygwin, mingw32, os2, darwin and macos as I read out of 2.6.2's configure.in, and I recall this changing prior to 2.6.0 (wxUSE_STD_IOSTREAM becoming the default). Could you take a look at config.log, configure output for relevant bits and/or attach em here? Please reopen the bug when you post the information Mart asked for (if this is still a problem) I still have the same problem, with wxGTK-2.6.2-r1. I couldn't think of an especially smooth way to get the requested information, so I just started the emerge and hit Ctrl-C when it started compiling files. If that was a no-no and there's a more-correct way to get the information, just let me know. I'll attach the goods following this comment. Created attachment 84930 [details]
config.log
This is /var/tmp/portage/wxGTK-2.6.2-r1/work/wxWidgets-2.6.2/gtk2_build/config.log.
Created attachment 84931 [details]
configure output
Copied and pasted from the beginning of the emerge until right before it started compiling.
Ok, from the logs I can see this: checking for --enable-std_iostreams... yes checking iostream usability... yes checking iostream presence... yes checking for iostream... yes checking for std::istream... yes checking for std::ostream... yes | #define wxUSE_STD_IOSTREAM 1 ac_cv_use_std_iostreams=wxUSE_STD_IOSTREAM=yes ## ----------- ## ## confdefs.h. ## ## ----------- ## <snip> #define wxUSE_STD_IOSTREAM 1 wxUSE_STD_IOSTREAM you are definately getting enabled... Does that not show in gtk2_build/lib/wx/include/gtk2-ansi-release-2.6/wx/setup.h, or what? Or is the problem something completely different? Perhaps you are picking up wx-2.4 headers - do you have wxGTK-2.4 installed too (they can co-exist)? You could use "equery l wxGTK" for that (small L) and see if it outputs more than one wxGTK. Well I'll be. That equery command you mentioned returned this: [ Searching for package 'wxGTK' in all categories among: ] * installed packages [I--] [M ] x11-libs/wxGTK-2.4.2-r3 (2.4) [I--] [ ] x11-libs/wxGTK-2.6.2-r1 (2.6) I don't know what the M means, but apparently there are two wxGTK versions installed. So I got to pondering whether wx-config was using the old version. It turns out that it is. For the new version, you have to use wx-config-2.6, which I didn't even know existed. I tried compiling using that, and it worked. I guess the "problem" is with the confusing way that the config programs are named. We can presumably close this bug. (In reply to comment #8) > Well I'll be. That equery command you mentioned returned this: > > [ Searching for package 'wxGTK' in all categories among: ] > * installed packages > [I--] [M ] x11-libs/wxGTK-2.4.2-r3 (2.4) > [I--] [ ] x11-libs/wxGTK-2.6.2-r1 (2.6) > > I don't know what the M means, I think that in this case it means that the ebuild doesn't exist in portage anymore (we are at 2.4.2-r4 now). Sounds like it would mean "hard masked" otherwise. > but apparently there are two wxGTK versions installed. They are slotted different, so you probably had wxGTK-2.4 from old times. > So I got to pondering whether wx-config was using the old version. > It turns out that it is. For the new version, you have to use wx-config-2.6, > which I didn't even know existed. I tried compiling using that, and it worked. Yeah, it picked up old 2.4 headers where wxUSE_STD_IOSTREAM wasn't the default. > I guess the "problem" is with the confusing way that the config programs are > named. We can presumably close this bug. We need to think how to solve the wx-config issues that seem to come up. All seems sorted not too bad for wx applications installed through ebuilds, where the eclass helps the ebuild select which wx version and wx-config to use, but users compiling wx apps on their own end up using some random wx-config symlink. My own goal is to just get rid of wxGTK-2.4 from the tree after ensuring nothing needs it if that works out, but that doesn't people to uninstall the old slotted 2.4, IIRC. Alright, so this isn't really a problem, and at a future date we can address the wx-config stuff. Thanks :) We could use the format wx-config-VERSION for every version of wx-config. Or we could let the most recent one be called wx-config and make older ones have version numbers. Or we could do the first thing and add a plain wx-config symlink that always points to the most recent one. Then there's the possibility that all my ideas just plain suck. Surely we're not the only people who have ever had to deal with this, so maybe we can see how the problem has been solved successfully before. We already have multiple wx-config files with changed names: /usr/lib/wx/config/gtk2-{ansi,unicode}-{debug,release}-2.<minor ver> /usr/bin/wx-config-2.<minor ver> /usr/bin/wx-config The problem is that wx-config is used by applications either directly or through wxwin.m4 aclocal macros. While we select the correct config out of /usr/lib/wx/config when installing a wx application through an ebuild with the help of the eclass, applications compiled manually use wx-config (and they are supposed to), and that symlink is a rather random one. Probably whatever slotted wx was installed the latest. That's what we need to take care of. I don't really want to suggest an eselect module here. But anyhow, I have this in horizon, but a specialized bug report on this might be useful. |