vala command compiles files instead of running them

  • Done
  • quality assurance status badge
Details
2 participants
  • Maxim Cournoyer
  • two
Owner
unassigned
Submitted by
two
Severity
normal
T
T
two wrote on 9 Jul 2022 16:38
(address . bug-guix@gnu.org)
20220709143848.1299.16298@mail.envs.net
the bin/vala-0.54 shell script executes bin/valac-0.54 which executes bin/.valac-0.54-real.
it should execute bin/.vala-0.54-real instead.

expected (was the case before guix's update):
$ vala hello.vala
Hello, World!
$ ls
hello.vala

actual:
$ vala hello.vala
$ ls
hello hello.vala
$ ./hello
Hello, World!
M
M
Maxim Cournoyer wrote on 15 Jul 2022 21:31
(address . two@envs.net)(address . 56467@debbugs.gnu.org)
87ilnyuq9y.fsf@gmail.com
Hi,

two@envs.net writes:

Toggle quote (16 lines)
> the bin/vala-0.54 shell script executes bin/valac-0.54 which executes bin/.valac-0.54-real.
> it should execute bin/.vala-0.54-real instead.
>
> expected (was the case before guix's update):
> $ vala hello.vala
> Hello, World!
> $ ls
> hello.vala
>
> actual:
> $ vala hello.vala
> $ ls
> hello hello.vala
> $ ./hello
> Hello, World!

That's indeed confusing, but it stems from the odd symbolic links layout
that upstream installs:

Toggle snippet (12 lines)
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.

Do you have another build of vala to compare against, preferably at the
same version?

Thanks,

Maxim
M
M
Maxim Cournoyer wrote on 15 Jul 2022 21:35
(address . two@envs.net)(address . 56467@debbugs.gnu.org)
87edymuq27.fsf@gmail.com
Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

[...]

Toggle quote (19 lines)
> 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.

Maxim
M
M
Maxim Cournoyer wrote on 15 Jul 2022 23:46
(address . two@envs.net)(address . 56467-done@debbugs.gnu.org)
871qumuk13.fsf@gmail.com
Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Toggle quote (28 lines)
> Hi,
>
> Maxim Cournoyer <maxim.cournoyer@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
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 56467@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 56467
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch