Add toolchain support for DSM 6.0

[GuillaumeSmaha]

No description provided.

[Dr-Bean]

Thanks. There's a file toolchains/syno-armadaxp-6.0/Downloading that doesn't belong in the PR.

[Dr-Bean]

You also might want to check that the email you're using for the commits to Github is associated with your Github account: that currently does not seem to be the case.

[GuillaumeSmaha]

Ok I remove the file toolchains/syno-armadaxp-6.0/Downloading, rebase the commit and update my email.

[cytec]

@Dr-Bean LGTM now :)

[Dr-Bean]

Yeah, I was verifying that the toolchains work as expected with the Python package, but ran into a snag with that (the open issue on manylinux wheels).

The problem here is that once we merge it, the all-supported rule switches over to using the DSM6 toolchains. I'd like to hold off on merging this PR for two reasons:

• We should add the DSM6 kernels (more of a nice-to-have than anything, but we should aim to include them on relatively short notice after adding the toolchains);
• We have to have the adduser issues fixed/at the very least something working in a PR imo. We can't properly use the DSM6 toolchains without it for the majority of packages. It's a bit of a chicken/egg situation, but at least we have the first component in this PR ready to go.
  Alternatively, we might be able to change the all-supported rule to not pick the latest TC by default, and e.g. use the one in local.mk. Not sure how much effort that is, I'd have to look into it.

[cytec]

you are right, totally forgot about the adduser thing already :/

[Dr-Bean]

I wish I could forget all about it ;)

[GuillaumeSmaha]

@Dr-Bean @cytec Are source for kernel currently available for DSM6.0 ? Or Are there the same as DSM5.2 ?

[Dr-Bean]

Huh, that's weird. I'm sure the GPL sources were published at some point (the beta stuff anyway), because I noticed they were split into separate files instead of it being compressed into one large file. It looks like Synology removed it again...
Should otherwise be located here: https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/

[GuillaumeSmaha]

@Dr-Bean I found it in the log activities : https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/7274branch/

4 months ago
Synology Open Source Project released /Synology NAS GPL Source/7274branch/alpine4k-source/gnutls-3.3.x.txz

But it's not available ...

[GuillaumeSmaha]

@Dr-Bean But there are also others files in https://sourceforge.net/projects/dsgpl/files/toolkit/

[Dr-Bean]

@GuillaumeSmaha Those are the actual development environments Synology provides. We use spksrc instead, so it doesn't contain anything of value for us.
I've sent in a request to Synology asking them to re-add the GPL source for DSM6.

By the way, could you have a look at #2219 (comment), and check if setting TC_ARCH="x86_64" in syno-x64-6.0/Makefile is recognized as a valid arch when compiled into a package? (seeing that you have an x64 model on DSM6 available, I don't).
We might be able to do similar things with other arches (Synology seems to do the same with ARM arches) but that's harder to test without having the equipment...

[GuillaumeSmaha]

@Dr-Bean I updated syno-x64-6.0 from

TC_ARCH = x86 braswell bromolow cedarview avoton

to

TC_ARCH = x86_64 x86 braswell bromolow cedarview avoton

I compiled zsh package and the installation was successful.

[Dr-Bean]

@GuillaumeSmaha Thanks, but that wasn't exactly what I meant ;)
I meant to ask: can we get away with using only x86_64 in TC_ARCH (which ultimately is translated to arch=x86_64 in INFO for a given package).
If that works for kvmx64 and dockerx64 (so the new VirtualDSM option and DockerDSM) as well as the more traditional arches, such as avoton, then we don't have to continue to keep adding each individual arch to TC_ARCH whenever a new model is released.
Synology seems to do that for their newer packages, so it's worth checking out (since there's no documentation on the matter, the only thing we can do is test ourselves)

[GuillaumeSmaha]

@Dr-Bean Humm Ok, I understand. I will try it

[GuillaumeSmaha]

Ok, it works. See the INFO file from the package :

package="zsh"                                                                    
version="5.2-3"                                                                  
description="Zsh is a shell designed for interactive use, although it is also a powerful scripting language."
description_fre="Zsh est un shell conçu pour un usage intéractif, mais il est aussi un puissant langage de script."
arch="x86_64"                                                                    
maintainer="SynoCommunity"                                                       
maintainer_url=""                                                                
distributor=""                                                                   
distributor_url=""                                                               
firmware="5.0-4458"                                                              
reloadui="no"                                                                    
startable="no"                                                                   
displayname="Z shell"                                                            
changelog="Update to 5.2"                                                        
checksum="dd8f5f3facf565d2aa33ea9ad416ba70"

I used :

TC_ARCH = x86_64

[Dr-Bean]

Just a drive-by comment: TC_FIRMWARE, e.g. here: https://github.com/SynoCommunity/spksrc/pull/2306/files#diff-d3c69815b668b46514d3bda504b7990eR5, has to be set to a DSM6 version.
Not all toolchains are backwards compatible with DSM5 (due to kernel version updates), and we have to be able to release DSM6-specific packages anyway, so setting all the toolchains to the same value makes sense.

The value should be set to the earliest stable DSM6 version, which should be 6.0-7321 according to http://dedl.synology.com/download/DSM/release/6.0.

[GuillaumeSmaha]

@Dr-Bean Ok, I update the FIRMWARE value.

https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/ is always not updated

[GuillaumeSmaha]

https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/ is always not updated ... -_-

[GoodOmens83]

6.0.2 toolchains have been released....

[GuillaumeSmaha]

@GoodOmens83 Thanks =)
@Dr-Bean @cytec Should I replace 6.0 by 6.0.2 or it will be a set of new package ?

It is always the same, GPL Source is misising !

[Dr-Bean]

A new set please. We can maintain all the toolchains with the current structure in spksrc, even though the older ones are generally not used after newer TC's are released.

It would be nice to have the GPL sources though, seeing as we can't build all the packages without them.
I've entered a request to publish the sources, for the third time or so...maybe Synology will remember to publish them this time. If you could also send in a feature request yourself, it might help.

[Dr-Bean]

GPL Source has been published (only 8451/DSM6.0.2, but at least we're getting somewhere ;)):
https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/

[GuillaumeSmaha]

@Dr-Bean Ok I am making the pull request

[GuillaumeSmaha]

@Dr-Bean lol This is a different kind of files ... https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/8451branch/avoton-source/

[Dr-Bean]

Well then...that doesn't help, does it? GPL source code indeed, but no kernel files. Sent in another request, thanks for noticing ;)

[Dr-Bean]

@GuillaumeSmaha I'm working on adding the DSM6.0.2 toolchains (planning to release a couple of -testing package, see here.

I used your PR as a base to start off from, but I do have a couple of comments on it (I never did a proper review...sorry):

• The 'useless' sysroot/lib location in myFix for the Monaco and Qoriq toolchains isn't useless in DSM6.0.2 or 5.2...so unless Synology reverted a change in between those two toolchains, I think you'll find that sysroot/lib is the exact location you want to use, including for TC_LDFLAGS. We should probably not use symlinks if we can help it, it's too error prone.
• What is the libdl issue you're referring to in this commit: f1fab1f?
  We generally see that sysroot/usr/lib contains nothing of value, and if there is, it's symlinked to sysroot/lib.

In short, I've reverted those changes from my 6.0.2 TC's for now ;) Would be nice if you can provide some insight into the questions above.

[Dr-Bean]

@GuillaumeSmaha I've added a new branch, dsm6, containing the dsm6.0.2 toolchains. It may be best to merge this PR into that branch (and when the time comes, merge the whole branch into master), but that means reopening this PR against that branch.
Not sure you're still working on this though. If so, please see my previous comment as well.
Thanks.

[GuillaumeSmaha]

@Dr-Bean I will check for f1fab1f but I don't have anymore the computer which returns this error. So I will try on a VM (debian wheezy).

If you want I can made a new PR on the new branch dsm6.

[Dr-Bean]

@GuillaumeSmaha Ok. I'd initially say don't bother with trying to recreate the error, but then again, I haven't run into it myself.

If you open a PR, then yes please: against the dsm6 branch :) You'll probably want to use the exact same approach as I did for the 6.0.2 stuff (e.g. same TC_FIX approach, same flags): probably just the download site and TC_VERS would be different, I think. No hurry, since 6.0.2 supercedes it anyway, but we like to add it to spksrc to make it complete.

It's about time we do a bit of a larger cleanup/revamp of the way the toolchains are setup though...I'll probably start working on that once the DSM6 stuff is up and running.

[GuillaumeSmaha]

@Dr-Bean I finally made the PR #2666
I remove the usr/lib directory in TC_LDFLAGS but if we encountered an issue with libld.so as missing, it fix it (only usr/lib contains libdl.so).
I also replace in MyFix the symlink ./lib by the real path.

[GuillaumeSmaha]

I close it (New PR on the branch dsm6)