forked from jengelh/wxWidgets-3_2
Jan Engelhardt
a41a4de1c4
Enable wxWebRequest. From 3.1.5 changelog: > New wxWebRequest and related classes provide a simple way to > use HTTPS and HTTP/2 from wxWidgets applications using native > libraries or libcurl. Introduced in 3.1.5 but wasn't built until now. Apparently, no package in Factory depend on it yet. Noticed this when trying to update package golly (not in Factory, just in Education) whose last version seems to use this feature. Not sure if I correctly updated the soversion, please let me know if something's wrong. The new symbols are in libwx_baseu_net-suse. OBS-URL: https://build.opensuse.org/request/show/1083535 OBS-URL: https://build.opensuse.org/package/show/X11:wxWidgets/wxWidgets-3_2?expand=0&rev=103 |
||
|---|---|---|
| _constraints | ||
| _multibuild | ||
| .gitattributes | ||
| .gitignore | ||
| README.SUSE | ||
| soversion.diff | ||
| wxpython-mkdiff.sh | ||
| wxWidgets-3_2-rpmlintrc | ||
| wxWidgets-3_2.changes | ||
| wxWidgets-3_2.spec | ||
| wxWidgets-3.2.2.1.tar.bz2 | ||
wxWidgets in SUSE ================= There are many possible wxWidgets configurations that can be built from a single source spec file. Depending on what options have been chosing, the ABI changes in incompatible fashion, yet the library filenames do not. To counter running a program with an incompatible variant of wxWidgets, we chose to make use of the vendor tagging mechanism. Programs built against the SUSE wxWidgets explicitly require the library by our name and therefore cannot inadvertently be run with an incompatible wxWidgets from another distribution. To run a foreign program, you will need to use the LD_LIBRARY_PATH mechanism to point it to a directory which contains the matching third-party wxWidgets variant.