wxGTK-2.6 and wxbase-2.6 install headers in /usr/include/wx-2.6/wx. These seem to conflict and cause problems with amule-2.0.0 (bug 71108) if both packages are installed. The conflict seems to be caused by the gcc4 patch that gets applied to wxGTK but not to wxbase (See bug 71108 for a gcc4 patch against wxbase). Isn't this conflict also going to cause problems in the future if one package is upgraded independantly of the other? Personally I see no reason to have two seperate packages here. Wouldn't it be better to just incorparate wxbase into the wxGTK ebuild ? As a (unrelated?) side note I haven't actually managed to compile anything against wxbase: /usr/lib64/libwx_baseu-2.6.so: undefined reference to `wxSoundData::DecRef()'
Thank Herbie. I'll package.mask this for now. I had originally declined to put wxbase in because I was afraid this might happen and it should be a blocker of wxAnythingElse. I think we could still add it without blocking, but we'd have to add a wxcommon with header files from all the various wx* versions so when you uninstall one you won't remove commone .h files etc. Another reason it was a separate package was because we were aiming to add wxbase, wxMacOS, wxMotif and wxX11 (maybe). They all build from the same wxWidgets tarball, but it just seemed clearer to make separate packages named wxbase etc. rather than have to come up with an odd combination of USE flags in wxGTK to end up with wxbase/wxMacOS etc. I'm open to suggestions, and if you can point me to an example to test compiling against wxbase, I'll get this done sooner than later. In that test that failed with wxSoundData is that with amule?
The only other option I can think of would be to install the headers into a package specific directory i.e wxGTK headers in /usr/include/wx-2.6/wxGTK and wxbase headers in /usr/include/wx-2.6/wxbase and have the wx-config scripts define the correct include path depending on what you're compiling against. This would obviously create some duplication if multiple wx* packages were installed. Yes, the failure was with amule which according to the developers should compile against wxbase-2.6 (with the gui components disabled). The ebuild I was using is here if it's any help: http://dev.gentoo.org/~herbs/amule-2.0.0.ebuild
Created attachment 58152 [details] Test of ld problem. This seems to be a problem with wxBase rather than aMule. You can use the attached sample to test it yourself (you'll probably have to fix the path in the makefile first): $ make clean all rm -f *.o minimal i386-pc-linux-gnu-c++ -c `/usr/lib/wx/config/base-ansi-release-2.6 --cxxflags` -o minimal.o minimal.cpp i386-pc-linux-gnu-c++ -o minimal minimal.o `/usr/lib/wx/config/base-ansi-release-2.6 --libs` /usr/lib/gcc/i386-pc-linux-gnu/3.4.3/../../../libwx_base-2.6.so: undefined reference to `wxSoundData::DecRef()' /usr/lib/gcc/i386-pc-linux-gnu/3.4.3/../../../libwx_base-2.6.so: undefined reference to `wxSoundData::IncRef()' collect2: ld returned 1 exit status It seems that wxBase doesn't properly disable SDL. If you interrupt the ebuild after configure has been run and change "#define wxUSE_LIBSDL 1" to "#define wxUSE_LIBSDL 0" in the setup.h header, then things work just fine. I have been unable to coerce the configure script itself into doing this.
What do you guys think of simply removing the wxbase ebuild and adding a 'no-gui' USE flag, which would only build wxbase. All we'd have to do in the wxGTK ebuild is pass '--disable-gui' to configure. We'd have to make sure they specify -sdl, -jpeg, -gif etc in their USE flags. Mikkel, correct me if I'm wrong please, but the way I understand it is if they build wxGTK as is, they can still run the deamon and console version in an xterm. The only problem would be is if they shut down X and tried to run the console version it wouldn't work due to linking problems? I don't see an easy way around that in Gentoo, because I think the Amule docs suggested compiling wxGTK then compiling wxbase and overwrite all the non-gui libs in wxGTK with wxbase's? And if thats the case, I don't think it'd work with a monolithic build of wxbase/GTK? If that was the case, we'd just have offer either console mode only with just wxbase, or gui + console mode that only worked in an xterm?
I'm not sure I under stand what you are trying to say (sorry). wxGTK consists of a number of libraries, whereas wxBase consists of a single library (libwx_base-2.6.so), so they are AFAIK able to coexist on the same system.
libwx_baseu-2.6.so still links to libX11, it just does not require gtk. Either way (compiled against wxGTK or wxbase) amulecmd runs perfectly well outside of X, it just requires xlibs to be present. Combining the two ebuilds seems sensible to me, why use a no-gui USE flag though? just build wxbase if compiled with -gtk -gtk2.
I found a post on the amule forums (months ago, searching for it now) about the reason why the manual says to install wxgtk and _then_ wxbase, even though wxbase shouldn't be necessary because its just a subset of wxgtk. The answer was that if you installed wxbase after, it would not link to libX11. If you didn't install wxbase at all you could still run the console app but only in an xterm. If you exited X and tried to run it, it'd fail because it wasn't linked to libX11. But you're saying that wxbase is linked to libX11 now, Herbie, so I think that is a problem if people have no X server. So I guess --disable-gui isn't enough, it probably needs a few other --disables to make sure it doesn't link to X? As for using -gtk -gtk2, that sounds fine, although not too obvious if someone is looking for a wxbase package (changing the package desc for wxGTK will work). Probably not a big deal since the only request for wxbase has been by amule users. You can add a preinst message in amule saying a non-gui version is available with -gtk -gtk2 I suppose. Mikkel, right the libraries are separate and can co-exist, but some headers are common to the two so unmerging wxbase after wxgtk would nuke those headers, so using wxGTK to install wxbase would avoid that (and the nightmare more patches could introduce).
Re #2: This is not necessary at all. The simplest way to handle this is to not use --enable-monolithic when compiling wxWidgets. If Gentoo didn't do it, wxGTK ebuild would install fully usable wxBase libraries independent on GTK+, so wxGTK could be used for both GUI and console-only development simply by passing appropriate options (e.g. --libs base) to wx-config. Re #6: wxBase has no dependency on X11 whatsoever (certainly not in the standard/non-monolithic build, anyway). Neither the undefined reference nor any dependency on X11 is in stock 2.6.0 compilation (../configure --with-sdl): vasek@wintermute lib $ ldd -r libwx_base-2.6.so.0.0.0 linux-gate.so.1 => (0xffffe000) libz.so.1 => /lib/libz.so.1 (0xb7ece000) libdl.so.2 => /lib/libdl.so.2 (0xb7eca000) libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/3.4.3-20050110/libstdc++.so.6 (0xb7dfc000) libm.so.6 => /lib/tls/libm.so.6 (0xb7dd9000) libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/3.4.3-20050110/libgcc_s.so.1 (0xb7dd0000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7dbd000) libc.so.6 => /lib/tls/libc.so.6 (0xb7ca3000) /lib/ld-linux.so.2 (0x80000000)
Created attachment 58160 [details, diff] Don't link to libSDL unless requested. Right, it's linking to libX11 purely becuase it's incorrectly linking to libSDL (the cause of the problem mentioned above). This patch to wxlib.eclass should fix the configure script to only link to libSDL (and hence libX11) if requested. aMule compiles cleanly against wxbase with this patch.
Err, no, wxBase libs don't link against libSDL either in standard build -- see comment #8 where --with-sdl _is_ used. What _exact_ configure line did you use to configure wx-2.6?
nks Vaclav, I think that gives us a plan now. So, we need to: a) Chagnge wxGTK to non-monolithic and bump it to -r1 and have everyone recompile apps linked against it (wxpython, pgadmin3, not too much else in portage yet thankfully). b) change wxpython to use MONOTLITHIC=0, bump version to 2.6.0.0-r1 c) Get rid of wxbase ebuild d) Change amule ebuild to pass "--libs base" to wx-config for non-gui only. Anything else?
That should do it, thanks. Depending on what exactly aMule does, it may be necessary to use "--cxxflags base" instead of "--cxxflags" etc. (the former defines wxUSE_GUI=0; libs list can be appended to all --fooflags) and maybe xml,base instead of base if it uses wx's XML classes.
$ cd wxWidgets-2.6.0 $ ./configure --disable-gui --without-sdl [...snip] expat sys libmspack no sdl gnomeprint none $ grep wxUSE_LIBSDL lib/wx/include/base-ansi-release-2.6/wx/setup.h #define wxUSE_LIBSDL 1 $ make [...snip] $ ldd lib/libwx_base-2.6.so.0.0.0 | grep SDL libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0x00002aaaab04b000)
Herbie, wxGTK-2.6.0-r1 is in cvs and is now multilib, so I think everything should be ok as far as amule goes. You can build it with -gtk2 -wxgtk1 to get wxbase non libX11 linked libs and its multilib (non-monolithic now). The wxbase ebuild has been removed. Let me know if theres anything else please.
All seems to work well for me, just a couple of very minor things: 1) wxGTK ebuild dies if use unicode && use !gtk2. You can compile wxbase with unicode so this is a little misleading. 2) Probably not even worth mentioning but.. the comments in the wxdidgets eclass state Arguments: 2.6: gtk gtk2 gtk2-unicode base base-unicode mac mac-unicode but need-wxwidgets will not accept "gtk2-unicode" as an argument, just uses "unicode"
Thanks Herbie, fixed #1 and #2 in CVS. Please re-open if anybody finds anything else.
