NOTE: as of now, I have successfully used the above steps to compile many packages for 4k-wheezy, 64k-wheezy and 4k-jessie. I don’t think I’ve tried 64k-jessie, but if compilation succeeds for 4k I see no reason for which it shouldn’t for 64k.
Many of those packages have also been installed and run successful on 4k (in fact, I’m currently using firmware 3.x in my My Cloud).
ISSUES SO FAR:
iotop builds and runs successful, but exits immediately because the kernel in the My Cloud has been compiled without the flags needed by iotop; a kernel ricompilation would be needed: since we have the source by WD, in principle it should be possible to do…
transmission-daemon can be successfully compiled from wheezy suite (version 2.52), but not from jessie (version 2.82): configuration fails and, in the output, I see three segmentation faults of qemu which are likely to be the cause; I’m trying to build qemu 2.1.0-rc3 from source (Debian provides 2.0 at most) to see if this can be fixed… otherwise an alternative approach must be taken to get a newer Transmission: try to build it in the My Cloud itself (would require to build and install on the device all the development tools) or cross-compile from original source as Nazar did
Ok I followed your steps trying to build transmission 64K wheezy with updated g++ package 4.7 on Debian 7.0.6 64bit, 1st round the bootstrap was missing dpkg-dev so I chroot build and install it.
The 2nd round the make failed at “make[4]: Entering directory `/root/transmission-2.52/third-party/dht’” with lots of these errors: dht.c:2893:49: error: invalid conversion from ‘void*’ to ‘const unsigned char*’ [-fpermissive].
3. Fix WD bootstrap once! cd to the package dir, replace qemu that was provided by WD:
cd packages/build_tools/debian/
cp -f /usr/bin/qemu-arm-static qemu/`dpkg --print-architecture`/
4. Run the build command (watch out for timeout/gateway errors which will result in failure at the end, retry if some dependencies failed to download):
OUTPUT debs can be found here:
build/root/transmission-cli_2.52-3+nmu2_armhf.deb
build/root/transmission-dbg_2.52-3+nmu2_armhf.deb
build/root/transmission-daemon_2.52-3+nmu2_armhf.deb
build/root/transmission-gtk_2.52-3+nmu2_armhf.deb
build/root/transmission_2.52-3+nmu2_all.deb
build/root/transmission-qt_2.52-3+nmu2_armhf.deb
build/root/transmission-common_2.52-3+nmu2_all.deb
I don’t understand, I just repeated the steps one by one to compile the package named “transmission-daemon” for 64-wheezy using G++ 4.7 and I had no issue at all…
Also, it’s strange that you had to install dpkg-dev manually: when you launch the build script, it invokes apt-get to install all the packages required for building. It’s all automatic. Are you sure your etc/apt/sources.list in the chrooted subsystem is ok?
Ok, I see now you’ve fixed your problem. However, are you able to compile libcurl3-gnutls? I can’t
Also, compiling transmission-daemon fails in 4k-jessie, again for a configuration error It’s the opposite situation of libcurl3-gnutls.
I’m starting to think that transmission will need the use of packages coming from mixed sources… I’ll keep on experiment.
I’ve managed to fix the build problem I had with libcurl3-gnutls from wheezy (it was my fault, I messed with the update-alternatives of gcc). So, now I have all the needed packages for Transmission 2.52 built from wheezy: I installed it and run successful!
Still I can’t build Transmission 2.82 from jessie. I think that Nazar’s solution is still valid if someone needs a recent version.
Today I tried java and mysql, can’t seems to build the latest jdk/jre 7 only older builds, segmentation fault
What does segfault? QEMU?
I tried to compile QEMU 2.1.0_rc3 from official sources. Compilaion succeded, but the final qemu-arm executable (which is not qemu-arm-static…) does not work… I mean, if I try to replace qemu-arm-static in the chrooted system with the file I get from compilation, chroot fails. The Debian package must be doing something to obtain the qemu-user-static package, but that goes beyond my knowledge. I even tried to download the Debian 2.0.0 source package, replace the sources there with the one coming from the official 2.1.0-rc3 tar.bz2 file and run the Debian compilation, but it fails
We might try to ask for assistance to QEMU developers…
iotop builds and runs successful, but exits immediately because the kernel in the My Cloud has been compiled without the flags needed by iotop; a kernel ricompilation would be needed: since we have the source by WD, in principle it should be possible to do…
In theory, yes, and I have been able to compile/build the 3.4 kernel which turned out to be not so bad. Had to install 32bit libs for the build tools, and dev ncursors to get the make menuconfig to go. However, building iptables into the kernel or .ko modules still escapes me … what ever I do, doesnt seem to make much difference in the build… then again I’ve never built a kernel before so its probably me
But without a dev/test environment its a guaranteed bricking activity so testing the kernel becomes a point of contention unless you’re willing to sacrifice a my cloud and have a quick drive rebuild procedure when things have gone pear shaped.
OUTPUT debs can be found here:
build/root/transmission-cli_2.52-3+nmu2_armhf.deb
build/root/transmission-dbg_2.52-3+nmu2_armhf.deb
build/root/transmission-daemon_2.52-3+nmu2_armhf.deb
build/root/transmission-gtk_2.52-3+nmu2_armhf.deb
build/root/transmission_2.52-3+nmu2_all.deb
build/root/transmission-qt_2.52-3+nmu2_armhf.deb
build/root/transmission-common_2.52-3+nmu2_all.deb
Hi
This is transmission version2.52. What do I need to change in the compilation config in order to compile version2.82, like the one in the old 3.0 firmware? My torrent sources seem to have problem downloading using verion 2.52.
First of all I really doubt that your downloading problem is due to the Transmission version.
Anyway, to compile Transmission 2.82 you have to follow my guide and build the “transmission-daemon” package either in the 4k-jessie scenario (if you have 3.x firmware) or in the 64k-jessie one (if you have 4.x firmware).
The problem, however, is that the build environment crashes when compiling Transmission from sources from jessie suite, because of a problem with the QEMU emulator, as I mentioned earlier. At least this is what happens to me.
I still have to investigate further, however as of now the only way to build a Transmission version newer than 2.52 is to compile from source as Nazar described in another post on this forum.
I’ve learned that we still need to mix methods to sometimes successfully produce the result, running the build script doesn’t always work. At times we may need to chroot to the build dir to make changes to the bootstrap, also cross-compile if something breaks.
Took me quite sometime to finally have mysql server running without breaking WD’s Dashboard/WebDav:
1. Upgraded to Apache2 2.4.10 to fix some of PHP5’s mod load issues.
2. Upgraded to PHP5 5.6.0 just to get php5-mysql and have it working.
Installed MySQL Server/Client 5.5.38, this was perfect once Apache2 and PHP5 configured correctly.
Think I’ve lost track of this build due to too many changes to the bootstrap. But if anyone needs the debs, let me know…
I have followed your protocol for 64k-wheezy and it has worked great for a number of packages, but now I think I have run in to a problem case. I wonder if you might evaluate?
1. Upgraded to Apache2 2.4.10 to fix some of PHP5’s mod load issues.
2. Upgraded to PHP5 5.6.0 just to get php5-mysql and have it working.
Installed MySQL Server/Client 5.5.38, this was perfect once Apache2 and PHP5 configured correctly.
Think I’ve lost track of this build due to too many changes to the bootstrap. But if anyone needs the debs, let me know…
Do you remember at least some of the changes you needed to do to the bootstrap?
By the way, I still think it’s a good idea to provide a list of links of pre-built packages, so that people do not have to rebuild all of them by themselves… what do you think? We may create a new topic for this. However, where do we put the built packages? I think a common web space would be a good idea… or the use of torrents instead. if we use our private Dropboxes the risk that links expire or are blocked is very high.
I have followed your protocol for 64k-wheezy and it has worked great for a number of packages, but now I think I have run in to a problem case. I wonder if you might evaluate?
I’m not a guru, but I know libstdc++ is a foundamental core library… I fear that even if you succeed at compiling it, installing on the My Cloud may break something. Why do you need to rebuild it? Are you sure you need?
I agree with you that the conflict might be in the binutils package, but if I remember well a patched binutils is needed for 64k-wheezy to build packages… Maybe rebuilding binutils itself before libstdc++ would make the trick, but, once again, I don’t know if this is going to work once you install packages on the My Cloud…
1. Upgraded to Apache2 2.4.10 to fix some of PHP5’s mod load issues.
2. Upgraded to PHP5 5.6.0 just to get php5-mysql and have it working.
Installed MySQL Server/Client 5.5.38, this was perfect once Apache2 and PHP5 configured correctly.
Think I’ve lost track of this build due to too many changes to the bootstrap. But if anyone needs the debs, let me know…
Do you remember at least some of the changes you needed to do to the bootstrap?
By the way, I still think it’s a good idea to provide a list of links of pre-built packages, so that people do not have to rebuild all of them by themselves… what do you think? We may create a new topic for this. However, where do we put the built packages? I think a common web space would be a good idea… or the use of torrents instead. if we use our private Dropboxes the risk that links expire or are blocked is very high.
The changes were mostly missing or conflicting dependencies. I can’t really recall because I was doing few builds at one go (left trying to get jre working). Think this should be easily replicated by building on a fresh bootstrap.
Despite package security concerns, a common web space is good, for the ease of wget right into the build box path. But we need someone committed to administer this. Like updating the main thread with the links to the guides and packages. Another is I’m not sure if Mods are happy with this, could end up thread getting closed and all the effort down with it…