Hi, Maxim Cournoyer <maxim.courno...@gmail.com> writes:
> Hi, > > Maxim Cournoyer <maxim.courno...@gmail.com> writes: > > [...] > >> lrwxrwxrwx 1 nixbld nixbld 9 Jul 15 19:18 vala -> vala-0.54 >> lrwxrwxrwx 1 nixbld nixbld 10 Jul 15 19:18 vala-0.54 -> valac-0.54 >> lrwxrwxrwx 1 nixbld nixbld 10 Jul 15 19:18 valac -> valac-0.54 >> -rwxr-xr-x 1 nixbld nixbld 147248 Jul 15 19:18 valac-0.54 >> lrwxrwxrwx 1 nixbld nixbld 12 Jul 15 19:18 valadoc -> valadoc-0.54 >> -rwxr-xr-x 1 nixbld nixbld 451032 Jul 15 19:18 valadoc-0.54 >> lrwxrwxrwx 1 nixbld nixbld 24 Jul 15 19:18 vala-gen-introspect -> >> vala-gen-introspect-0.54 >> -rwxr-xr-x 1 nixbld nixbld 1067 Jul 15 19:18 vala-gen-introspect-0.54 >> lrwxrwxrwx 1 nixbld nixbld 12 Jul 15 19:18 vapigen -> vapigen-0.54 >> -rwxr-xr-x 1 nixbld nixbld 720128 Jul 15 19:18 vapigen-0.54 >> >> If you read attentively, you'll see there's no proper 'vala' binary, >> vala, vala-0.54 and valac are all symbolic links to valac-0.54, which is >> the compiler. >> >> Perhaps upstream changed the behavior? Or it could be that they use >> arg0 (the program name) to infer different behaviors, which gets mangled >> by our wrappers. > > I just confirmed the later in #vala on the gnome IRC server. Let's see > what we can do. Simple deleting the problematic wrap phase seems a good enough solution, done in commit 154d270012. I've also taken the opportunity to upgrade the package to version 0.56.2 and fixed a small usability issue (it would require the user to have 'cc' on their PATH). Enjoy, Maxim