Bugzilla Bug 91574

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 an attachment (id=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 an attachment (id=58160) [details]
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.