On Sun, May 25, 2014 at 09:17:51AM +0100, Gianfranco LocutusOfBorg Costamagna
wrote:
Hi dear Olly,
Il Sabato 24 Maggio 2014 15:31, Olly Betts o...@survex.com ha scritto:
I've just discovered an annoying consequence of this change.
If you now install libwxgtk3.0-dev and ask for libraries to link with,
you get:
$ wx-config --libs
-L/usr/lib/x86_64-linux-gnu -pthread -lwx_gtk2u_xrc-3.0
-lwx_gtk2u_webview-3.0
-lwx_gtk2u_html-3.0 -lwx_gtk2u_qa-3.0 -lwx_gtk2u_adv-3.0
-lwx_gtk2u_core-3.0
-lwx_baseu_xml-3.0 -lwx_baseu_net-3.0 -lwx_baseu-3.0
Note that this includes -lwx_gtk2u_webview-3.0, but that's not
installed, so linking fails. The same thing happens if you ask for an
explicit list of libraries and include std in that list.
This is pretty serious as it's likely to cause packages to FTBFS.
Some options I can see for fixing this and their downsides:
* Make libwxgtk3.0-dev depend on libwxgtk-webview3.0-dev - this would
pull in libwxgtk-webview3.0-0 and hence webkit for such builds; it
may also sometimes end up with webkit getting unnecessarily included
as a runtime dependency, for packages which don't link with
-Wl,--as-needed.
This seems ugly, at least on debian (no changes on ubuntu, I wonder if
debian will ever se them as default)
It's ugly even without the --as-needed issue as it bloats the BDs for
every package building with wx GUI libraries which doesn't use wxWebView
(which is likely to be most of them).
* Update all packages to explicitly request the wx component libraries
they actually need - significant fiddly work, but perhaps the way
forwards.
This seems to require a lot of uploads...
Probably - only packages which explicitly list the component libraries
they need (and don't ask for std) will continue to work.
* Alter the meaning of std in wx-config - makes it behave
differently
on Debian to elsewhere.
This is something I didn't understand correctly, but I think I did
something similar
So wx-config --libs will output the flags needed to link particular
component libraries. You can optionally provide a list of them, which
can include std. If there's no list, the default list of just std
is assumed.
Without webview enabled (i.e. in 3.0.0-2), std expands to:
xrc html qa adv core xml net base
With webview enabled (i.e. in 3.0.0-3), std expands to:
xrc webview html qa adv core xml net base
Note that this doesn't include all component libraries (e.g. media
isn't included, you have to request that explicitly), so my idea was
just to move webview to the same status as media.
The issue with this is that wx-config is then incompatible for
applications which use wxWebView, though applications can just use
--libs std,webview to work with both.
It seems unhelpful for libraries which aren't enabled if you build
wxWidgets from source with the default --enable and --with option to
be in std. So I think this might be a fix to suggest to upstream
(wxWebView is new, so making this change in 3.0.1 might be viewed as
reasonable).
I'm attaching a little patch I did to make wx-webview behave a more
little closer than wx-media...
However I'm stuck with a little problem:
how can I use wx-config to export wx-media libraries?
wx-config --libs std,media
(As noted above, media isn't in std).
I think we can make it return wx-webview only if the library is found
on the system, with this patch I made webview optional, next step is
to understand how wx-config really works (I fall asleep before
understanding it completely).
That's an interesting idea. It means that wx-config behaves
compatibly to a build without webview enabled if libwx-webview3.0-dev
isn't installed, which is less surprising.
I see wx-config already have some loops inside looking for libraries
on the system, my approach will return the flags only if found on the
system, and since this webview is marked as mandatory but seems
optional I think we can push this patch also upstream.
wx-config is generated at configure time (from wx-config.in), and if you
don't enable webview, then wx-config won't have it in its list of
libraries to expand std to.
So such a patch wouldn't really make sense for upstream, as they have a
mechanism to handle this already for those building from source.
Do you want to let this package reach testing? maybe reopening and
reassignig the severity will prevent automatic rebuild failures...
I did that, though I notice that it's not currently blocking transition
as the found version is already in testing. I'll open a new bug in
a moment.
Cheers,
Olly
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
