http://bugzilla.opensuse.org/show_bug.cgi?id=939434 http://bugzilla.opensuse.org/show_bug.cgi?id=939434#c1 Stanislav Brabec changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED CC| |jengelh@inai.de Flags| |needinfo?(jengelh@inai.de) --- Comment #1 from Stanislav Brabec --- There was a large discussion about it seveal years ago: - STL + Unicode is the configuration of wxWidgets recommended by the upstream. - ANSI (i. e. not Unicode) version should be considered as strongly deprecated - STL should be preferred over wxcontainer. - 2.4 API is also deprecated. And yes, all three STL, Unicode and 2,4 compatibility changes the API and ABI, which makes packaging especially complicated. In the version 2.8, the package spec file generated several variants: defualt (the STL container, Unicode enabled, 2.4 compatibility disabled), ansi (the old container, Unicode disabled, 2.4 compatibility enabled), wxcontainer (the old container, Unicode enabled, 2.4 compatibility disabled), wxcontainer24c (the old container, Unicode enabled, 2.4 compatibility enabled; Fedora ABI compatible). When it was update to version 3, Jan Engelhardt decided to drop other variants and keep only the default one, considering having a four incompatible packages as an overkill. Note that wxWidgets never supported this multi-variant setup. This always needed some additional tricks: adding RPATH tags to target binaries required patching of wx-config, and some programs ignored this additional option. It was expected that everybody who ported application to wxWidgets 3 also made it compatible with STL and Unicode. We cannot easily disable STL: - It will break ABI - Some programs already require STL If your package depends on wxWidgets 3 compiled without STL, it would be needed to do something line wxWidgets 2.8 did. Jan, do you think that it makes sense? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=939434 http://bugzilla.opensuse.org/show_bug.cgi?id=939434#c3 Markus Kolb changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(jengelh@inai.de) | --- Comment #3 from Markus Kolb --- Yes, software upstream code had only a problem in a single place which got fixed with c_str() conversion. I just got told there that openSUSE should use the default non-STL: https://veracrypt.codeplex.com/workitem/172 I can not judge if it is a rare problem or, like Stanislav has written, that some code already relies on STL. But the default compile is unicode on and stl off.

From http://docs.wxwidgets.org/trunk/overview_container.html: "For historical reasons, wxWidgets uses custom container classes internally. This was unfortunately unavoidable during a long time when the standard library wasn't widely available and can't be easily changed even now that it is for compatibility reasons. If you are building your own version of the library and don't care about compatibility nor slight (less than 5%) size penalty imposed by the use of STL classes, you may choose to use the "STL" build of wxWidgets in which these custom classes are replaced with their standard counterparts and only read the section STL Build explaining how to do it."

Sounds like they would welcome STL usage but have the burden of compatibility. But why they don't default to STL? My intention was to get these issues to your knowledge... I can live with the current situation. ;-) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=939434 http://bugzilla.opensuse.org/show_bug.cgi?id=939434#c5 --- Comment #5 from Stanislav Brabec --- If the application really depends on ANSI (non-Unicode) or wxcontainer (non-STL) variant, there is still available wxWidgets 2.8 with several variants. I guess it will be available at least for several next years. (Some time ago I did an experiment: Create specially configured OBS project that will force wxWidgets 3 to all packages. It seems that there are many not yet ported applications.) I think that Jan did a good decision when he dropped support for variants. It was a packaging nightmare. Variants were never supported by the upstream, and it required a patch to wx-config. This patch also has a compatibility problems: Packages that ignored wx-config and linked against wx libraries by their own failed to work. And also RPM does not support equally named libraries in different directories. It needed a specially crafted dependency rewriting utility. But this utility cannot be ported to the new RPM dependency checker. It causes unfixable dependency problems. -- You are receiving this mail because: You are on the CC list for the bug.