FS#34201 - [erlang] can not find wxe_driver.so, some graphical tools don't work
Attached to Project:
Community Packages
Opened by Ruud (Moving_away) - Thursday, 07 March 2013, 15:32 GMT
Last edited by Alexander F. Rødseth (xyproto) - Wednesday, 27 March 2013, 16:05 GMT
Opened by Ruud (Moving_away) - Thursday, 07 March 2013, 15:32 GMT
Last edited by Alexander F. Rødseth (xyproto) - Wednesday, 27 March 2013, 16:05 GMT
|
Details
Description:
When trying to use some of the graphical tools/ demo-applications in Erlang, it gives the following error-message: ERROR: Could not find 'wxe_driver.so' in /usr/lib/erlang/lib/wx-1.0/priv and the screen that appears is not complete (missing information). Folder 'priv' does not exist at that location, and the file 'wxe_driver.so' does not exist anywhere else in the system. https://bbs.archlinux.org/viewtopic.php?id=159183 mentiones the same issue. Issue has happened both in Arch ( Additional info: * Packages: -erlang R16B-1 (x86_64) -wxgtk 2.8.12.1 (x86_64) * Up-to-date system, newly installed, Steps to reproduce: In the terminal open erlang-shell: $ erl Try one of the following commands in this shell: 1> debugger:start(). or 1> wx:demo(). The following graphical tools do not seem to be influenced: pman:start(). tv:start(). appmon:start(). |
This task depends upon
Closed by Alexander F. Rødseth (xyproto)
Wednesday, 27 March 2013, 16:05 GMT
Reason for closing: Fixed
Wednesday, 27 March 2013, 16:05 GMT
Reason for closing: Fixed
I tried ading 'wxgtk' to make dependencies, just in case, but the result was the same.
Judging from earlier bugreports, it's highly likely that it's an upstream bug this time as well.
Please report upstream and include a link to the bug report here.
Thank you.
I had a look at their bugs mailing-list (forgot to do so before), http://erlang.org/pipermail/erlang-bugs/2013-February/003384.html seems relevant. It describes the same problem, only in R16A (erlang's testing release as far as I understand). They mention a patch, but I guess that should have made it into R16B then. I don't have enough experience building packages yet to poke around in it myself I'm afraid (still learning the basics).
http://erlang.org/pipermail/erlang-bugs/2013-February/003428.html
Awaiting the next release. I will consider applying the patch as well.
I just now mentioned the issue in the #erlang channel on freenode. A fellow Archer (essen) over there tried to compile the package and was not able to do so, using the current PKGBUILD for erlang. When compiling it says it fails on src/otp_src_R16B/lib/wx/c_src/gen/wxe_funcs.cpp (g++ internal compilation error). It also gives the following error for this before failing the compilation:
78830: Warning: end of file not at end of line; newline inserted
71949: Error: unknown pseudo-op:`.str'
When I mentioned the idea was to wait for the next release, he said that that would mean waiting for 3 months and not no clue whether it will be fixed by then.
Try compiling the package again on a computer with more available memory.
By the way, the build indeed took significantly more memory when compiling the wxe_funcs.cpp than other parts of the build (from 360M to 1250M), so maybe that was indeed why essen on IRC had trouble building it.
So now we need to find out where the difference is between my build and the standard one.
https://www.archlinux.org/packages/extra/x86_64/unixodbc/
https://www.archlinux.org/packages/community/x86_64/lksctp-tools/
Did you try building in a chroot?
Just tried building it again, and it built fine here.
This problem is not a packaging problem. It's a problem with Erlang (a regression even) that the upstream developers should solve.
* I build the package using ABS (updated ABS, copied the folder for erlang, execute 'makepkg -s'). this seemed to finish successfully.
* As part of this, lksctp-tools and unixodbc are downloaded. I called these orphans, I meant they are not a dependancy to run, but apparently a dependancy to build the package (in other words, when I run 'pacman -Qdt' these 2 packages show up because they are not a dependancy of anything). Not really important, the only reason I mentioned this was to give full report of what I did
* After just building the package (so not installing it yet), I tested whether the bug was there (since lksctp-tools and unixodbc were added and I didn't understand the concept of build-dependency enough). Naturally, it was.
* I uninstalled the erlang I got from the repos (using 'pacman -Rsn'), and installed the newly build package. As a sidenote, I noticed that there was a slight difference in size between my newly build package and the package from the repos (mine being slightly bigger).
* After installing the package, I tested whether I still had the problems, and I did not. The problem was solved. So building it from ABS myself created a working package, solving the bug.
My point was that there apparently is a difference in the build made for the repos, and the build I did from ABS, and that finding out what that was would make it possible to rebuild the package in the repos so it works out of the box. One thing I could think of myself was actually having wxgtk installed, but you said you tried to build it before with wxgtk as make-depend and it didn't solve it. I attached a list of all installed packages so you can see in what environment it was build. If you need other info, let me know.
The package built from ABS and the package from [community] can differ in size from a number of different reasons. Different system-wide compile flags, different versions of compilers at the time of building, etc. The case of Erlang is a bit special, since it builds differently depending on which libraries are available at compile-time, so this may be the case too, if I should have missed one of the make dependencies (or included one too many). I see that wxgtk is only a dependency and not a make dependency. I'll try adding it as a make dependency and build the package again.
P.s. sorry for the garbled look in the file, but script apparently outputs all control characters.
It's probably possible to change the PKGBUILD to only require one of them, by configuring the erlang build process somehow.
Updating the package, it should appear in [community] shortly. Thanks for the help, Ruud.