Created attachment 528152 [details, diff] Reinstate the wxwdigets use flag When the ebuild for dev-lang/erlang-20.3 was upgraded to dev-lang/erlang-20.3.2 the use flag for wxwidgets was removed with the motivation "Please also note that I have dropped the "wxwidgets" USE flag, as upstream unconditionally links against it". This is probably a misunderstanding as OTP, when built on a machine without X, builds successfully thus indicating that linking is not done unconditionally. It is also pretty inconvenient to be forced to drag both X and OpenGL on small headless systems running Erlang. The OTP build system will link against wxWidgets if it is installed and usable, so it is understandable if this has been misunderstood as unconditional linking. The proper way to disable wxWidgets support is to pass the `--without-wx` flag to configure. That will skip building wx even if it is available on the system. Attached is a patch that allows reinstates the wxwidgets use flag and properly disables wxwidgets when it is not set.
Created attachment 528154 [details, diff] Reinstate the wxwdigets use flag virtual/glu must depend on wxwidgets too
Created attachment 528156 [details, diff] Reinstate the wxwdigets use flag Disabling wx using --without-wx makes the build fail as the debugger requires the wx_object behaviour which is not found when --without-wx is used. So update the patch to the previous behaviour. This allows for building OTP without dragging in X and Wxwindows, if Wxwindows is installed but the wxwindows use flag is not set, wxwindows will still be used, but this is a lesser evil than the forced bloat.
"if Wxwindows is installed but the wxwindows use flag is not set, wxwindows will still be used" <-- this is not acceptable for Gentoo main tree. The package manager doesn't know it's used, let one unmerge wx and get a (partially?) broken erland. Also it makes it link to some random wxWidgets version, not what is intended by WX_GTK_VER (and the SLOT deps that could be recorded by USE=wxwidgets)
Hi Frej, I agree with Mart, the package manager needs to know this information. Gokturk and I also ran into the "--without-wx" issue, with various other modules actually relying on wx to build successfully even if it was disabled. I believe wxwidgets should be unconditionally required. Thanks, Sarnex
(In reply to Mart Raudsepp from comment #3) > "if Wxwindows is installed but the wxwindows use flag is not set, wxwindows > will still be used" <-- this is not acceptable for Gentoo main tree. The > package manager doesn't know it's used, let one unmerge wx and get a > (partially?) broken erland. Also it makes it link to some random wxWidgets > version, not what is intended by WX_GTK_VER (and the SLOT deps that could be > recorded by USE=wxwidgets) A valid point! An unconditionally requirement for wxWidgets makes the ebuild unusable for me, so I dug further. It appears that we can get the overly ambitious OTP build system to play along if we, when wxWidgets is disabled, give it a bogus wxdir. That way we short circuit all the logic that tries to find a usable wxWidgets installation and we will not link against wxWidgets even if it is installed. If the wxWidgets use flag is enabled, we instead rely on the detection logic and OTP will pick up the wx-config script as provided by the wxwidgets eclass and all will be well. I have updated the patch. I'm a bit unsure if "$(if ! use wxwidgets ; then echo "--with-wxdir=/dev/null" ; fi)" is the right way or if there is a more gentooish way of doing this.
Created attachment 528162 [details, diff] Reinstate the wxwdigets use flag
@Frej, the problem isn't about disabling the build of lib/wx. We did try really hard to keep the USE flag. I run servers too so I understand your issue. Take a look at https://github.com/erlang/otp/blob/master/lib/observer/src/Makefile#L42. Other apps under lib/ also have some linking against wx that cause the issue. The build system does not keep a track of this, just simply skips building lib/wx which clearly doesn't solve the problem. Here's a different output from the debugger app which also wants to links against wx unconditionally: === Entering application debugger make[3]: Entering directory '/tmp/otp-OTP-20.3.2/lib/debugger/src' ERLC ../ebin/debugger.beam ERLC ../ebin/i.beam ERLC ../ebin/int.beam ERLC ../ebin/dbg_debugged.beam ERLC ../ebin/dbg_icmd.beam ERLC ../ebin/dbg_idb.beam ERLC ../ebin/dbg_ieval.beam ERLC ../ebin/dbg_iload.beam ERLC ../ebin/dbg_iserver.beam ERLC ../ebin/dbg_istk.beam ERLC ../ebin/dbg_wx_break.beam ERLC ../ebin/dbg_wx_break_win.beam ERLC ../ebin/dbg_wx_code.beam ERLC ../ebin/dbg_wx_filedialog_win.beam compile: warnings being treated as errors dbg_wx_filedialog_win.erl:22: behaviour wx_object undefined make[3]: *** [/tmp/otp-OTP-20.3.2/make/x86_64-unknown-linux-gnu/otp.mk:123: ../ebin/dbg_wx_filedialog_win.beam] Error 1 I'm not convinced that even if we get it to build without wx somehow, it will continue to function. Searching through their bugzie makes me think there may be some dlopen magic involved, though I haven't checked this (https://bugs.erlang.org/browse/ERL-171?jql=text%20~%20%22wx%22). Currently, the best we can do is to disable every single app that has a wx dependency (debugger and observer are the two things I've seen so far). The optimal solution would be to add wx-dependent modules conditionally in the Makefiles of all the apps that use wx. Ultimately, it will have to be resolved upstream. I suggest the following: let's file an upstream bug and request support for optional wx in certain apps. In the meanwhile, we can add the USE flag back with an einfo saying "Disabling wxwidgets USE flag also disables the following apps (see bug #653700): debugger observer foo bar baz". What do you think?
(In reply to Göktürk Yüksek from comment #7) > I suggest the following: let's file an upstream bug and request support for > optional wx in certain apps. In the meanwhile, we can add the USE flag back > with an einfo saying "Disabling wxwidgets USE flag also disables the > following apps (see bug #653700): debugger observer foo bar baz". What do > you think? This sounds like the preferrable solution. There is clearly something wrong upstream and needs to be addressed there. Disabling those apps sounds more than acceptable to me, esp. since a GUI observer can just connect remotely to a headless node. Thanks all for trying to resolve this.
(In reply to Göktürk Yüksek from comment #7) > Take a look at > https://github.com/erlang/otp/blob/master/lib/observer/src/Makefile#L42. > Other apps under lib/ also have some linking against wx that cause the > issue. The build system does not keep a track of this, just simply skips > building lib/wx which clearly doesn't solve the problem. Here's a different > output from the debugger app which also wants to links against wx > unconditionally: Actually, you are confusing two things, linking at the OS level and use of the OTP wx application. The error you see is because you have given --without-wx to configure. As you have not compiled the wx application there is no behaviour module for wx_object and as we compile with -Werror it will fail. Just because an OTP application uses wx it does not force linking of any wxWidgets library shared objects. Erlang uses external code through two mechanisms, NIFs and port drivers. A NIF (Natively Implemented Function) is a dynamically loaded .so which can use a Erlang-specific API to create and access Erlang terms. A port driver can either be a .so-file loaded dynamically or a stand alone executable that communicates with an Erlang process over something that's basically a byte-stream (simplified). The wx OTP application uses a dynamically loaded port driver, the driver is started when the wx application is started. The Erlang build system, by default, builds the Erlang part of all applications, if, for example, you don't have wxWidgets installed it will simply skip building the port driver. I'm pretty sure this is by design as some monitoring applications need the application BEAMs on both the monitored node and the node which runs the user interface. > I'm not convinced that even if we get it to build without wx somehow, it > will continue to function. Searching through their bugzie makes me think > there may be some dlopen magic involved, though I haven't checked this > (https://bugs.erlang.org/browse/ERL-171?jql=text%20~%20%22wx%22). > > Currently, the best we can do is to disable every single app that has a wx > dependency (debugger and observer are the two things I've seen so far). The > optimal solution would be to add wx-dependent modules conditionally in the > Makefiles of all the apps that use wx. Ultimately, it will have to be > resolved upstream. That's not what we want as it will probably stop us from connecting to a running node and monitor or debug it from a machine that has the full wx support. We only want the possibility to skip building the port driver, even if wxWidgets is installed on the build machine. My proposed hack of passing `--with-wxdir=/dev/null` to configure when `! use wxwidgets` does just that, it tricks the Erlang build system to behave as if it did not find a usable wxWidgets thus skipping the port driver. > I suggest the following: let's file an upstream bug and request support for > optional wx in certain apps. We could try that, but I suspect they'll tell us to use something along the lines of my hack. > In the meanwhile, we can add the USE flag back with an einfo saying > "Disabling wxwidgets USE flag also disables the following apps (see > bug #653700): debugger observer foo bar baz". What do you think? That would be great, although it's not that clear cut as you will probably be able to use some of the applications as long as you run the GUI from another node. Doing a `grep -r -- "-behaviour(wx_object)" lib/` it looks like it is only debugger, observer, and et that are affected. I'd go with: "Disabling the wxwidgets USE flag will disable the GUI part of the following applications (see bug #653700): debugger, observer, et"
From https://bugs.gentoo.org/658656#c4 , Stefan wants to proxy maintain this :)
Frej, please let me know if using Erlang modules that depend on "wx" ("debugger", "dialyzer", "et", "observer", "reltool") on a system without wxwidgets is a tested scenario or just a guess.
(In reply to Ștefan Talpalaru from comment #11) > Frej, please let me know if using Erlang modules that depend on "wx" > ("debugger", "dialyzer", "et", "observer", "reltool") on a system without > wxwidgets is a tested scenario or just a guess. That is tested, at least the reltool and dialyzer applications work fine on a system without an installed wx (the c++-side libraries etc) as long as you don't try to invoke their graphical frontends. Et and debugger, being GUI applications can't run, but I'm not 100% sure that you won't need modules from these applications when you run distributed erlang and run them from a node which has the wx port-driver. Remember that as long as you don't try to open a window, all modules using the wx_object behaviour will load without complaint. A nit-pick: "debugger", "dialyzer", "et", "observer", "reltool" are applications, not modules.
I added your configure hack to (optionally) avoid linking against wxwidgets to the erlang-21.0-r1 ebuild in my overlay: https://github.com/stefantalpalaru/gentoo-overlay
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=52b809031961e32051870ace639b4efd87234160 commit 52b809031961e32051870ace639b4efd87234160 Author: Ștefan Talpalaru <stefantalpalaru@yahoo.com> AuthorDate: 2018-08-17 19:45:30 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2018-09-30 10:53:41 +0000 dev-lang/erlang: version bump to 21.1 I removed some deprecated configure options, properly (re-)added the "wxwidgets" USE flag - without automagic dependencies, added the "pgo" flag and made some USE flags enabled by default to match upstream's defaults. Most of the ebuild was refactored, after code reviews, with the more significant change being the replacement of two shell functions copied from an upstream build script with a call to a patched version of that script. When the "pgo" USE flag is enabled, distcc and ccache are disabled, to avoid a build failure due to a version mismatch in .gcda files that cannot be explained by different GCC versions. Closes: https://bugs.gentoo.org/653700 Closes: https://bugs.gentoo.org/658656 Signed-off-by: Ștefan Talpalaru <stefantalpalaru@yahoo.com> Signed-off-by: Michał Górny <mgorny@gentoo.org> Closes: https://github.com/gentoo/gentoo/pull/9357 dev-lang/erlang/Manifest | 3 + dev-lang/erlang/erlang-21.1.ebuild | 161 +++++++++++++++++++++ dev-lang/erlang/files/erlang-custom-autoconf.patch | 14 ++ dev-lang/erlang/metadata.xml | 27 ++-- 4 files changed, 192 insertions(+), 13 deletions(-)
