Closed Tjoppen closed 6 years ago
I'd love to know if this is still relevant. I need someone to help build/test on Linux.
Hum, no idea. I have some other things to work on (codec2 stuff), but setting up a build system again shouldn't be too hard
Do you have a CI? Or does GitHub these days? It's best to have a computer test the build for you automagically :]
No I don't have a CI. :|
On Wed, Aug 16, 2017 at 2:51 AM, Tjoppen notifications@github.com wrote:
Do you have a CI? Or does GitHub these days? It's best to have a computer test the build for you automagically :]
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/christopherpow/nesicide/pull/6#issuecomment-322693898, or mute the thread https://github.com/notifications/unsubscribe-auth/ABkI8ODUdyoTREsGXLCPD46yi5hIzBuUks5sYp9ygaJpZM4ApZT5 .
K. GitLab comes with one by default, I'm using it at work. The CI config (.gitlab-ci.yml) is just another file in the repo too, so it gets tracked
Been lurking this project for some time, and I just want to add that, yes, there is still interest in a Linux build. I'd love be able to just use the code without having to chop at it with a machete to get FamiTracker to work in Linux. ;)
I might not be a technical wizard but I can help test builds.
Guess I'll have to put my Linux gloves back on.
@CuriouslyCurious I've committed all changes necessary to get it to build in Ubuntu 14. I am looking into linuxdeployqt to build a package.
@christopherpow After spending a few hours trying to get it to build on my Arch Linux laptop and a fresh Ubuntu 16 VM on the same machine I've gotten nowhere and could use some help.
I followed the instructions in README.md. Used wget https://download.qt.io/official_releases/qt/5.6/5.6.2/qt-opensource-linux-x64-5.6.2.run
to get the correct version of qt.
Then tried to run ./build.sh
. It first gave me an error that I couldn't build it at all, to solve this I downloaded qt4-make. Then tried to build again and it gave me this error (on Arch Linux):
Building FamiTracker...
cd ../../deps/rtmidi/ && ( test -e Makefile || /usr/bin/qmake -o Makefile /home/curious/Programming/nesicide/deps/rtmidi/rtmidi.pro ) && make -f Makefile
make[1]: Entering directory '/home/curious/Programming/nesicide/deps/rtmidi'
rm -f librtmidi.so.1.0.0 librtmidi.so librtmidi.so.1 librtmidi.so.1.0
g++ -Wl,-O1 -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -shared -Wl,-soname,librtmidi.so.1 -o librtmidi.so.1.0.0 release/RtMidi.o -lalsa -lpthread
/usr/bin/ld: cannot find -lalsa
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:142: release/librtmidi.so.1.0.0] Error 1
make[1]: Leaving directory '/home/curious/Programming/nesicide/deps/rtmidi'
make: *** [Makefile:47: sub-------deps-rtmidi-rtmidi-pro-make_first] Error 2
I got the same error on the Ubuntu VM but I solved it by symlinking the libalsa.so like so:
sudo ln -sf /usr/lib/x86_64-linux-gnu/ao/plugins-4/libalsa.so /usr/lib/x86_64-linux-gnu/
Fixing this on my Arch should be similar, I just need to find where it expects libalsa.so to be.
Unfortunately something is wrong with the referencing to QT on my VM and I haven't been able to figure it out. A snip-bit of the errors:
Building FamiTracker...
cd ../../deps/rtmidi/ && make -f Makefile
make[1]: Entering directory '/home/curious/Downloads/nesicide/deps/rtmidi'
make[1]: Nothing to be done for 'first'.
make[1]: Leaving directory '/home/curious/Downloads/nesicide/deps/rtmidi'
cd ../../libs/famitracker/ && make -f Makefile.famitracker-lib
make[1]: Entering directory '/home/curious/Downloads/nesicide/libs/famitracker'
Makefile.famitracker-lib:2742: warning: overriding recipe for target 'install_target'
Makefile.famitracker-lib:2726: warning: ignoring old recipe for target 'install_target'
Makefile.famitracker-lib:2750: warning: overriding recipe for target 'uninstall_target'
Makefile.famitracker-lib:2734: warning: ignoring old recipe for target 'uninstall_target'
g++ -c -m64 -pipe -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I../../deps/boost_1_64_0 -I../../deps/rtmidi -I ../../deps/wine/include -DUSE_WS_PREFIX -DWINE_UNICODE_NATIVE -O2 -w -D_REENTRANT -fPIC -DNOMINMAX -DNULL=0 -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/share/qt4/mkspecs/linux-g++-64 -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I. -ISource -I../../common -ISource/APU -Irelease -o release/cqtmfc_famitracker.o cqtmfc_famitracker.cpp
In file included from cqtmfc_famitracker.cpp:1:0:
../../common/cqtmfc.h:7:28: fatal error: QDialogButtonBox: No such file or directory
compilation terminated.
Makefile.famitracker-lib:499: recipe for target 'release/cqtmfc_famitracker.o' failed
make[1]: *** [release/cqtmfc_famitracker.o] Error 1
make[1]: Leaving directory '/home/curious/Downloads/nesicide/libs/famitracker'
Makefile:63: recipe for target 'sub-------libs-famitracker-famitracker-lib-pro-make_default' failed
make: *** [sub-------libs-famitracker-famitracker-lib-pro-make_default] Error 2
This is how far I've gotten at the moment.
I made some "dumps" with ./build.sh > arch_errors.txt
and ./build.sh > ubuntu_errors.txt
.
Turns out it was just me being stupid (that's what I get for trying to build a program in the middle of the night). I just had to install some libraries (I thought were included with qt): sudo apt-get install libqt4-dev libqt4-dev-bin libqt4-opengl-dev libqtwebkit-dev qt4-linguist-tools qt4-qmake
@christopherpow I've been watching the commits and as of the latest commit: e0de924 I managed to get the entire project to build on the Ubuntu VM. Great job, man! 👍
The only thing I had to do afterwards to get the programs to work was move a bunch of *.so files to /usr/local/include
and export LD_LIBRARY_PATH=/usr/local/include
. FamiTracker and FamiPlayer were running fairly okay (it's a VM on a laptop after all)! I'll start looking at what is needed to be done for Arch Linux (if anything) when I have the time.
Great news! By the way I also added linuxdeployqt to the linux-deploy.sh script. That should provide packages for all four executables that work without needing to do any library gymnastics. If you run the linux-deploy.sh script you should end up with four *.AppImage files. I'm also working to add an upload step so Travis CI will push new built packages to my website on every pull request.
Looks like you're building with qt4. Any reason for that? I'd set things up to build with qt5 and hadn't kept qt4 support in mind.
@christopherpow where can we download these?
@probonopd download what? The Linux packages of nesicide? Https://knob.phreneticappsllc.com/nesicide/
Thanks, but I am looking for the AppImage files:
you should end up with four *.AppImage files.
They're inside the bzipped-tarball.
Thanks @christopherpow - is there a specific reason they are inside an archive? If not, I'd ask you to consider providing the raw .AppImage files for download.
As described on https://github.com/AppImage/AppImageKit/wiki/Creating-AppImages#common-mistake,
Please DO NOT put an AppImage into another archive like a
.zip
or.tar.gz
. While it may be tempting to avoid users having to set permission, this breaks desktop integration with the optionalappimaged
daemon, among other things. Besides, the beauty of the AppImage format is that you never need to unpack anything. Furthermore, packing an AppImage into some form of archive prevents the AppImage from being added to the central catalog of available AppImages at https://github.com/AppImage/AppImageHub.
I simply tarballed the four appimages to keep them as one package. I had no idea it mattered to anyone. Seems a bit strange that it would be frowned upon, even more so that it would be called a "common mistake". But then again I'm not that familiar with Linux distro stuff.
On Sun, Oct 29, 2017 at 12:34 PM, probonopd notifications@github.com wrote:
Thanks @christopherpow https://github.com/christopherpow - is there a specific reason they are inside an archive? If not, I'd ask you to consider providing the raw .AppImage files for download.
As described on https://github.com/AppImage/AppImageKit/wiki/Creating- AppImages#common-mistake,
Please DO NOT put an AppImage into another archive like a .zip or .tar.gz. While it may be tempting to avoid users having to set permission, this breaks desktop integration with the optional appimaged daemon, among other things. Besides, the beauty of the AppImage format is that you never need to unpack anything. Furthermore, packing an AppImage into some form of archive prevents the AppImage from being added to the central catalog of available AppImages at https://github.com/AppImage/ AppImageHub.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/christopherpow/nesicide/pull/6#issuecomment-340279417, or mute the thread https://github.com/notifications/unsubscribe-auth/ABkI8IeUTnFUHHj30AXHvr8gTg6acK3Cks5sxLcPgaJpZM4ApZT5 .
Having AppImages inside archives breaks a lot of functionality that AppImage has been created for, so yes, it would really be cool if you could provide them as direct downloads. Thank you!
@probonopd https://knob.phreneticappsllc.com/nesicide/ -- is that better?
I know that it may look like nitpicking, but
nesicide.desktop: error: value "Development" for string list key "Categories" in group "Desktop Entry" does not have a semicolon (';') as trailing character
Can you please add a ;
at the end? Then it maybe will pass verification and can be included in the AppImageHub central directory of available AppImages. Thank you!
Reference: https://travis-ci.org/AppImage/appimage.github.io/builds/295072391#L691
Cool. What categories can I include? I'd like to use something else for the other apps.
Ok @probonopd I've updated the categories I think correctly.
Cool. What categories can I include? I'd like to use something else for the other apps.
According to the menu spec,
By including one of the Main Categories in an application's desktop entry file, the application will be ensured that it will show up in a section of the application menu dedicated to this category. If multiple Main Categories are included in a single desktop entry file, the entry may appear more than once in the menu.
Hence, please add at least one of the following in the Categories=
key.
Main Category | Description | Notes |
---|---|---|
AudioVideo | Application for presenting, creating, or processing multimedia (audio/video) | |
Audio | An audio application | Desktop entry must include AudioVideo as well |
Video | A video application | Desktop entry must include AudioVideo as well |
Development | An application for development | |
Education | Educational software | |
Game | A game | |
Graphics | Application for viewing, creating, or processing graphics | |
Network | Network application such as a web browser | |
Office | An office type application | |
Science | Scientific software | |
Settings | Settings applications | Entries may appear in a separate menu or as part of a "Control Center" |
System | System application, "System Tools" such as say a log viewer or network monitor | |
Utility | Small utility application, "Accessories" |
In addition, you could specify one or more from the longer list of Additional Categories.
Please test the result with desktop-file-validate
and make sure it passes.
Ok @probonopd I've updated the categories I think correctly.
Going to test it now.
AppImage launches, but what is contained inside the AppImage seems to be too new for Ubuntu 14.04, which is the oldest still-supported Ubuntu version and the baseline for applications to be included in AppImageHub:
This is likely because nesicide was compiled on a distribution newer than Ubuntu 14.04, or a newer libstdc++
version was used than what comes with Ubuntu 14.04.
There are (at least) two solutions:
libstdc++.so.6
libstdc++.so.6
inside the AppImage. In this case make sure to use https://github.com/darealshinji/AppImageKit-checkrt/Background information:
Some projects require newer C++ standards to build them. To keep the glibc dependency low you can
build a newer GCC version on an older distro and use it to compile the project. This project however will now require a newer version of the libstdc++.so.6
library than available on that distro. Bundling libstdc++.so.6
however will in most cases break compatibility with distros that have a newer library version installed into their system than the bundled one. So blindly bundling the library is not reliable. While this is primarily an issue with libstdc++.so.6
in some rare cases this might also occur with libgcc_s.so.1
. That's because both libraries are part of GCC. You would have to know the library version of the host system and decide whether to use a bundled library or not before the application is started. This is exactly what the patched AppRun binary from https://github.com/darealshinji/AppImageKit-checkrt/ does. It will search for usr/optional/libstdc++/libstdc++.so.6
and usr/optional/libgcc_s/libgcc_s.so.1
inside the AppImage or AppDir. If found it will compare their internal versions with the ones found on the system and prepend their paths to LD_LIBRARY_PATH
if necessary.
Yeah I'm compiling in 16.04. Travis builds are failing for Linux because of its use of 14.04.
So it cannot be compiled on 14.04?
I'll create a 14.04 VM and figure that out. :|
Thank you very much. This way uses of older distributions could benefit, too.
Strangely I am able to build just fine in an Ubuntu 14.04 VM. I'm not sure why Travis fails.
Some more fixes. Still lots of problems, but this reduces the number of them.