Compilation under Ubuntu and OS X

[forthrin]

1. (dpkg-buildpackage -us -uc -b -rfakeroot) fails even after installing a lot of unmentioned dependencies. When will a valid source be available with complete instructions how to compile?
2. Compilation for OS X is described as "experimental" up to OS X 10.7 and fails to generate binaries. When will a compilable source for OS X 10.11 be available? And an updated binary?

Let me know if you need error logs or other information.

[ghost]

I noticed too that the packaging metadata are largely outdated and not really maintained.

It has been a long time since my last read of the "Debian New Maintainers’ Guide", but if I remember correctly, it is mentioned that package maintainers are usually overriding every debian directory found in any package, treating the infos there as a sample only. Correct me if I am wrong.

Given this I would not expect that packaging like that will work out of the box™, probably everything is there just for the devs for testing/experimental purposes only.

But hey, you got the source, you can tweak/fix it and open a pull request. ☺️

In regards of OS X, I am not experiencing any issue, could you be more specific ? The autotools are working pretty well in building aMule. Sure you have to handle the dependencies by yourself, but this is expected, you are not downloading a binary. Are you referring to the Xcode build ?

Generally speaking I have to admit I agree with you: in fact I am maintaining a custom branch for those exact reasons. I have not opened up a pull request because if the devs find useful to maintain a certain behavior (debian directory in root, etc) it is a bit rude to break it.

[sandrotosi]

look at how debian does it: https://anonscm.debian.org/gitweb/?p=pkg-amule/amule.git

[forthrin]

I am no wiz at compilation. I can install missing dependencies and paste build commands from README files, but that's pretty much it. If there are compilation errors, I'm pretty much at a loss.

It would be very helpful if the Linux and OS X README files were updated with complete and correct instructions how to install. (Unless this tool is only supposed used by development gurus?)

export SDKNUMBER=10.11 gives Valid SDKNUMBER are 10.4-10.7 when compiling for OS X. The 10.7 SDK, released 2010, is long since deprecated and unavailable, effectively prohibiting compilation.

PS! The reason for wanting to compile is #35, which forces me to restart the app daily. If there is an OS X binary available which resolves this, I don't really need to compile.

[ghost]

Ok, I got it.

I think that it is best to stick with the packages provided by the distribution, unless you are able to troubleshoot compilation problems.

And you may be right, at first sight issue 35 should affect the aMule packages in Ubuntu (git20151120) because 786a00b is dated 6 Mar. Did you report this ?

In Ubuntu you may try to compile like this, but by default this will install amule in /usr/local, be aware that you will have to handle it on the next upgrade of your OS (the compiled binary may or may not work again).

git clone https://github.com/amule-project/amule.git
cd amule
sudo apt-get install libcrypto++-dev libgeoip-dev libupnp-dev libboost-all-dev libwxbase3.0-dev libwxgtk3.0-dev zlib1g-dev build-essential autoconf automake gettext 
./autogen.sh
./configure --with-boost
make
sudo make install

In OS X the build process is pretty much the same if you want to install an unbundled version

git clone https://github.com/amule-project/amule.git
cd amule
brew install autoconf automake gettext cryptopp geoip libupnp wxmac boost
brew link --force gettext
./autogen.sh
./configure --with-boost
make && make install
brew unlink gettext

If you want to build a bundle (an aMule.app to install in /Applications by copy and paste) for OS X 10.10+ using the latest SDK, you can do it, but not using the official repo.

git clone https://github.com/tgragnato/aMule.git
cd aMule && cd platforms/macOS
xcodebuild build

A binary compiled using this latest process (with all the latest commits) is available here, please note that it's provided as is and without any warranty.

Hope this helps.

[forthrin]

Starting with a pristine Ubuntu 16 and sudo apt-get install git, your instructions fails as follows:

configure: WARNING:
    UPnP code has been disabled because libupnp >= 1.6.6 not found (pkg-config not found).
configure: WARNING: could not figure out which toolset name to use for g++
/bin/bash: ./config.rpath: No such file or directory
configure: WARNING:
    You need to install GNU gettext/gettext-tools to compile aMule with
    i18n support.
configure: WARNING:
    bfd.h not found or unusable, please install binutils development
    package if you are a developer or want to help testing aMule
config.status: error: cannot find input file: `Makefile.in'

Since package version of gettext (0.19.7) doesn't seem to cut it, I installed the latest from source:

wget http://ftp.gnu.org/pub/gnu/gettext/gettext-latest.tar.gz
tar zxf gettext-latest.tar.gz 
cd gettext-0.19.8.1/
./configure
make
sudo make install

Since package version of binutils (2.26) doesn't seem to cut it, I installed the latest from source:

wget http://ftp.gnu.org/gnu/binutils/binutils-2.27.tar.gz
tar xvf binutils-2.27.tar.gz 
cd binutils-2.27/
./configure
make
sudo make install

How do I solve the remaining errors?

configure: WARNING: could not figure out which toolset name to use for g++
/bin/bash: ./config.rpath: No such file or directory
configure: WARNING:
    Cannot link to the library containing the bfd functions.
config.status: error: cannot find input file: `Makefile.in'

[ghost]

Mmh, you do not need to compile anything other than aMule. Maybe I missed autopoint and bison. Would you mind to try ?

[forthrin]

Same errors.

[ghost]

Sorry I am not able to reproduce

[forthrin]

Does a bit of context help?

checking for Boost headers version >= 1.47.0... yes
checking for Boost's header version... 1_58
checking for the toolset name used by Boost for g++... configure: WARNING: could not figure out which toolset name to use for g++
checking for Boost sources... no
checking boost/system/error_code.hpp usability... yes
checking boost/system/error_code.hpp presence... yes
checking for boost/system/error_code.hpp... yes
checking for the Boost system library... yes
checking boost/asio.hpp usability... yes
checking boost/asio.hpp presence... yes
checking for boost/asio.hpp... yes

(...)

checking bfd.h usability... yes
checking bfd.h presence... yes
checking for bfd.h... yes
checking for libraries required to link with bfd... not found
configure: WARNING:
        Cannot link to the library containing the bfd functions.

(...)

checking for SVNDATE... rev. gbe8236a
checking denoising level... 0
checking whether ccache support should be added... no
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: error: cannot find input file: `Makefile.in'

[forthrin]

Could this be related? http://blog.fmeh.org/2014/04/09/how-not-to-package-a-library/

[forthrin]

I read somewhere that Red Hat is recommended for aMule. If this is a requirement for successful compilation, this should be clearly stated in the README. The README should anyway provide a complete and updated instruction how to compile on supported systems to avoid confusion.

[ghost]

aMule is fine in Ubuntu: you are messing up with something, but I don't know what. As a proof: build log 1 - build log 2 - build log 3

[xf1]

Same issue here, autopoint save me.

[gonosztopi]

Since package version of gettext (0.19.7) doesn't seem to cut it

sudo apt-get install autopoint

Since package version of binutils (2.26) doesn't seem to cut it

sudo apt-get install binutils-dev

It would be very helpful if the Linux and OS X README files were updated with complete and correct instructions how to install.

Please see http://wiki.amule.org/wiki/Compile . Although the information there may also be outdated, it might provide better instructions than any README file in the sources.

Red Hat is recommended for aMule

False. No distribution is specifically recommended for aMule.

[forthrin]

Well, that link sure was a bit more elaborate on compilation than the README files, but it still talks about Snow Leopard like it was yesterday, while it's actually more like five years ago.

It would be of great help if someone would create up-to-date instructions and put them in a single place to make life easier for everyone. (I suggest the README files of the Git tree.)

Switching to Homebrew for packaging is also guaranteed to produce a good round of applause.

As for Red Hat: http://wiki.amule.org/t/index.php?title=YSWPS

[ghost]

Homebrew

• currently ships wxmac3
• has deprecated head only formulas
• has a rapid pace of development

aMule

• 2.3.1 do not build with wx3
• the release cycle went from 1/2 yrs to 5 yrs

Even if someone would be able to submit a stable formula for the release to come (16.09.16), that Formula won't be in the brew repo for quite a long (unless the aMule project will engage in keeping up with the ecosystem).

Sorry, but I do not agree: my feeling is that, for macOS, a well bundled binary app is the way to go.

[forthrin]

Actually, I do agree. As long as there is a binary available that does not have grave bugs (like the assert dialog that started the discussion), a binary should suffice for most, including me.

[hotman-x]

I'm running Ubuntu 16.04 in Chinese locale. The aMule in the repository crashed with these message:

----------------------------=| BACKTRACE FOLLOWS: |=----------------------------
Current version is: aMule SVN compiled with wxGTK2 v3.0.2 and Boost 1.58
Running on: Linux 4.4.0-59-generic x86_64

[2] ?? in /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0[0x7f49320088ec]
[3] ?? in /lib/x86_64-linux-gnu/libpthread.so.0[0x7f4931153390]
[4] non-virtual thunk to CryptoPP::PK_FinalTemplate<CryptoPP::TF_SignerImpl<CryptoPP::TF_SignatureSchemeOptions<CryptoPP::TF_SS<CryptoPP::PKCS1v15, CryptoPP::SHA1, CryptoPP::RSA, int>, CryptoPP::RSA, CryptoPP::PKCS1v15_SignatureMessageEncodingMethod, CryptoPP::SHA1> > >::~PK_FinalTemplate() in amule[0x4c28cd]
[5] wxSizer::Add(wxWindow*, int, int, int, wxObject*) in amule[0x5d5ee1]
[6] wxSizer::Add(wxWindow*, int, int, int, wxObject*) in amule[0x5d5985]
[7] wxSizer::Add(wxWindow*, int, int, int, wxObject*) in amule[0x5e05a5]
[8] wxSizer::Add(wxWindow*, int, int, int, wxObject*) in amule[0x5eafec]
[9] non-virtual thunk to CryptoPP::PK_FinalTemplate<CryptoPP::TF_SignerImpl<CryptoPP::TF_SignatureSchemeOptions<CryptoPP::TF_SS<CryptoPP::PKCS1v15, CryptoPP::SHA1, CryptoPP::RSA, int>, CryptoPP::RSA, CryptoPP::PKCS1v15_SignatureMessageEncodingMethod, CryptoPP::SHA1> > >::~PK_FinalTemplate() in amule[0x4a45f6]
[10] void std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_M_construct<wchar_t const*>(wchar_t const*, wchar_t const*, std::forward_iterator_tag) in amule[0x46ba34]
[11] CryptoPP::IteratedHash<unsigned int, CryptoPP::EnumToType<CryptoPP::ByteOrder, 0>, 64u, CryptoPP::HashTransformation>::DataBuf() in amule[0x533237]
[12] wxEntry(int&, wchar_t**) in /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0[0x7f4931f3df72]
[13] ?? in amule[0x440712]
[14] __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6[0x7f4930d92830]
[15] ?? in amule[0x452c19]

Any trace message has a little difference from each other, but the backtrace [2] and [3] are always libwx_baseu and libpthread. It looks like some errors prone in concurrent code of wx GUI.

IMPORTANT MODIFICATION I find that, after I compiled aMule and uninstall my version, reinstall aMule in the repository:

$sudo make uninstall
$sudo apt install amule

The crash message of amule is ALWAYS THE SAME AS ABOVE

So I tried to compile my version of aMule. It compile well, but run into a crash too. Dump this:

----------------------------=| BACKTRACE FOLLOWS: |=----------------------------
Current version is: aMule SVN compiled with wxGTK2 v3.0.2 and Boost 1.58 (Debugging) (Snapshot: rev. 11156)
Running on: Linux 4.4.0-59-generic x86_64

[2] ?? in /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0[0x7fc2ace188ec]
[3] ?? in /lib/x86_64-linux-gnu/libpthread.so.0[0x7fc2ac19b390]
[4] CECSocket::HaveNotificationSupport() const in ECSocket.h:104
[5] ECNotifier::DownloadFile_SetDirty(CPartFile const*) in ExternalConn.cpp:2151
[6] MuleNotify::DownloadCtrlUpdateItem(void const*) in GuiEvents.cpp:134
[7] MuleNotify::CMuleNotifier1<void const*>::Notify() const in GuiEvents.h:265
[8] MuleNotify::HandleNotification(MuleNotify::CMuleNotiferBase const&) in GuiEvents.cpp:86
[9] void MuleNotify::DoNotify<void const*, CPartFile*>(void (*)(void const*), CPartFile*) in GuiEvents.h:415
[10] CPartFile::UpdateDisplayedInfo(bool) in PartFile.cpp:3622
[11] CPartFile::SetFileName(CPath const&) in PartFile.cpp:3959
[12] CPartFile::LoadPartFile(CPath const&, CPath const&, bool, bool) in PartFile.cpp:406
[13] CDownloadQueue::LoadMetFiles(CPath const&) in DownloadQueue.cpp:135
[14] CamuleApp::OnInit() in amule.cpp:572
[15] CamuleGuiApp::OnInit() in amule-gui.cpp:288
[16] wxAppConsoleBase::CallOnInit() in app.h:93
[17] wxEntry(int&, wchar_t**) in /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0[0x7fc2acd4df72]
[18] main in amule-gui.cpp:95
[19] __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6[0x7fc2abdda830]
[20] _start in :0

Just as same as the one in repository, each backtrace different except the backtrace [2] and [3] are always same.

I don't think I should dive into the source code and spend my weeks of time to debug. Some searching tell me that the wrong is made by ubuntu, I don't know how. But how can I work around?

Thanks for any help.

[ssbarnea]

Ok, without brew formulas it means that it would likely be a waste of time to try a DIY build. RIP

Meanwhile brew got support for linux too.

[Vollstrecker]

When the cmake-stuff is done, it should work on Mac, too. I'm not at the point to test on Mac, but it's on the list.

[ssbarnea]

I do not see any reason for not trying to make use of github actions to do that, it works very well on macos and if I remember well it comes with homebrew pre-installed.

[Vollstrecker]

Maybe because someone would have to learn how homebrew works, integrate and maintain it in the source, and then wait for someone else who likes another system more, to do it all again with that. That's why I chose cmake, works on all three plattforms with the major IDE's. It's even possible to create packages for these plattforms right out of the build-system.

[ssbarnea]

homebrew is not a build system, is just a very thin layer that clones code, install deps and run build/install commands. There is no danger to cmake itself ;) --- Once could argue that the homebrew recipes are mainly packaging metadata.

[Vollstrecker]

Jep, kind of packagemanager. Like the ones in source-based distros. It basically looks for the deps (didn't check if they all are available) downloads and installs (compiles) them and then compiles the source. Guess what: That's exactly what cmake does when I'm finished. So I strictly vote against an additional layer while I hardly try to get rid of autotools, VS-projects, X-Code-projects and other shell-scrips.

And I'm sure if we would add this there will come issues with add this option, the dep is now available, or hey you homebrew, please add snap or whatever else is now en voque. In my eyes the best way is to find one that works for all, instead of handling everything in separate.

[l2dy]

Ok, without brew formulas it means that it would likely be a waste of time to try a DIY build. RIP

It's really not that hard with CMake. If we need CI (e.g. GitHub Actions) for macOS, let Homebrew, MacPorts, or any other package manager install the dependencies and cmake, and run cmake to do the build. There is no need to write a Homebrew formula just for CI. CMake is very convenient already.