32-bit version of unison on amd64?

[Havin_it]

Hi,

I've been using unison for some time now to sync a folder between home (Gentoo and Arch x86) and work (Win 7 32bit) PCs via a central server (Gentoo amd64). The server was originally x86 but I replaced it with an amd64 box a couple of months ago, which didn't immediately seem to cause any problems.

However, lately I've had problems syncing specific files from the Windows box to the server. The compare stage goes normally, but transfer hangs on certain files. (Unfortunately I can't share the files in question due variously to business sensitivity and software licensing, but they include some quite small SQL files and some largish .chm help files.)

In the unison wiki I found this passage:

[Hu]

That looks like a bug in the design of the Unison network protocol. Wire protocols should be independent of the bitness and even endianness of the hosts using them. If Unison does not have dependencies on other libraries, you could probably build a 32-bit version by modifying the ebuild. It looks like it is not a normal C program, so this could be somewhat difficult.

For basic transfers, net-misc/rsync works well. However, it assumes policy is provided by its caller.

[MotivatedTea]

I use unison a lot too. (For the record, unison does a lot more than rsync.) I haven't tried running between 32 and 64 bit systems yet. However, I have had to use it on computers on which I did not have permission to install software system-wide, or computers on which the installed version didn't match the version I wanted to use. In those cases, I simply compiled the executable from source in my home directory and moved the "unison" executable to ${HOME}/bin/unison (making sure that ${HOME}/bin was in my PATH before /usr/bin).

Although it's not a portage-y solution, it would probably work for you. If you already have an i686 crossdev environment set up, build ocaml and then unison in that environment. (If you can do without the GUI, you should only need ocaml. If you want the GUI, you'll need to cross-compile a bunch of GTK libraries as well. Read the "INSTALL" file in the source tarball for details. However, it will probably be much easier to cross-compile without the GUI. I would at least try that first. You can always just use the GUI on the "other" machine you're syncing.) I'm sorry I can't help you figure out how to do that - I haven't used crossdev in a while. However, given that your system is multilib, if you can acquire a 32-bit unison executable from somewhere, you should be able to run it directly. Note that you may need to use the "servercmd" directive in your unison profile to make sure the 32-bit version is run instead of the one in /usr/bin, since non-interactive logins won't necessarily have the same PATH that you're used to. (See the unison documentation.)

I hope that helps at least a little bit. If you find a solution, please post it here. I'm not syncing between 64 and 32 bit system yet, but I probably will need to in the future!

[Havin_it]

OK, thanks for that. So does that mean if I follow the cross-compiling guide and do "xmerge unison" I'll get a binary with its own 32-bit libs, all of which'll run happily on the host system, or will I need to do other things either (a) to ensure it loads the correct libs at runtime, or (b) to create a static binary if (a) won't work?

Should also mention that the connection is over SSH (using cygwin's ssh binary on the client, although the unison client I'm using is native not the cygwin one). Just in case that complicates the remote invocation (I assume some kind of wrapper can deal with this).

[MotivatedTea]

I believe that should work, although I'm not in a position to test it. I believe unison is written in Ocaml, not C, and that's a language I'm not familiar with. I don't know what shared libraries it might need to run - that would be your biggest potential problem. That's why I suggest compiling it without the GUI - that will greatly reduce the list of dependencies.

Cross-dev still uses portage, correct? In that case, I would use cross-dev to build a 32-bit version of unison with USE="static -gtk". That is, turn the GUI off (-gtk), and make a static executable. That should result in a 32-bit executable with few or no dependencies. You should be able to just run a 32-bit static executable on a 64-bit multilib machine without problems. You can check what shared libraries a program expects by running "ldd /path/to/32/bit/unison". Ideally you will get a message saying "not a dynamic executable". If you do get some dependencies, they will hopefully be only a few libraries that are provided by your multilib setup.

Once you know you have a 32-bit build you can run, then you need to make sure unison uses it. Locally, you can just run it explicitly (although you won't get a GUI). Remotely, you'll need to edit your unison profile as I indicated before, and make sure the "servercmd" points to the full path to the 32-bit executable.

[Havin_it]

Getting closer, but still some problems. The static, non-gtk build has only a few deps but one of them (coreutils) is having a build failure. Besides the xmerge script, I also spotted that there's an emerge-i686-pc-linux-gnu command, which seemed to function identically to xmerge, but failed identically too

Can cross-compiling failures be reported to b.g.o?

Also, seems odd that ocaml was not pulled in. It's not a runtime dep as long as USE="ocamlopt" (compiles a binary instead of ocaml bytecode) but I'm surprised that it doesn't require a 32-bit version of ocamlopt to build it (as would be the case with gcc).

[Hu]

Cross-compilation failures should be supported on b.g.o, but you can bring them here first if you want confirmation. Did you set USE=static for the entire xmerge tree or only for unison? You should only need to set it for unison.

As I read the ebuild, dev-lang/ocaml is never a runtime dependency. The check for USE=ocamlopt is because OCaml support for creating native code is an optional feature of dev-lang/ocaml, so users might have installed dev-lang/ocaml[-ocamlopt], which would give them an OCaml interpreter, but not enable them to build native code from OCaml inputs. Such users would fail to build net-misc/unison[ocamlopt]. It might be a mistake that the ebuild does not include RDEPEND+="!ocamlopt? ( dev-lang/ocaml )". Most people end up with the build time dependencies lurking on their systems indefinitely, so would not notice the mistake, if it is a mistake at all. It is also possible that net-misc/unison[-ocamlopt] works without an installed OCaml interpreter, although I see nothing in the ebuild to explain why that would be the case.

If OCaml's method of generating native code is to translate OCaml source into C source, then run a C compiler on it, then any runnable architecture of OCaml could be used to perform the translation step. You would only need a C compiler for the appropriate target.

[Havin_it]