v
v copied to clipboard
vlang
Building 0.4.6 release: `V panic: No such file or directory; code: 2`
Describe the bug
I'm trying to build/package the 0.4.6 release of V on openSUSE. I'm following packaging_v_for_distributions.md It appears I can produce a v binary and I'm trying to do v build-tools. That was failing, so I tried v self-test. I'm getting this error:
[ 53s] + ./vlang-stage1 -prod -no-parallel -o vlang-stage2 cmd/v
[ 98s] + ./vlang-stage2 -prod -o vlang cmd/v
[ 143s] + echo 'println('\''Use your package manager to update V'\'')'
[ 143s] + echo 'println('\''v self is disabled for the packaged versions of V'\'')'
[ 143s] + export VEXE=/home/abuild/rpmbuild/BUILD/vlang
[ 143s] + VEXE=/home/abuild/rpmbuild/BUILD/vlang
[ 143s] + export VTEST_SANDBOXED_PACKAGING=
[ 143s] + VTEST_SANDBOXED_PACKAGING=
[ 143s] + ./vlang test-self
[ 153s] > error while executing: /home/abuild/rpmbuild/BUILD/cmd/tools/vtest-self ['test-self']
[ 153s] V panic: No such file or directory; code: 2
[ 153s] v hash: c412b9f
[ 153s] | 0x5620ee8db5fc | ./vlang(+0x2215fc)
[ 153s] | 0x5620ee6bd61e | ./vlang(+0x361e)
[ 153s] | 0x7fb9c1a2a1f0 | /lib64/libc.so.6(+0x2a1f0)
[ 153s] | 0x7fb9c1a2a2b9 | /lib64/libc.so.6(__libc_start_main+0x8b)
[ 153s] | 0x5620ee6bd655 | ./vlang(+0x3655)
[ 153s] error: Bad exit status from /var/tmp/rpm-tmp.K1BGeO (%build)
It does not give me enough information to proceed further. Is there a way to figure out what file it cannot find?
Reproduction Steps
Here is the project with the .spec file if that can be helpful:
https://build.opensuse.org/package/show/home:bberberov/vlang
Expected Behavior
A more verbose output so I can figure out what is missing and correct it.
Current Behavior
[ 143s] + ./vlang test-self
[ 153s] > error while executing: /home/abuild/rpmbuild/BUILD/cmd/tools/vtest-self ['test-self']
[ 153s] V panic: No such file or directory; code: 2
[ 153s] v hash: c412b9f
[ 153s] | 0x5620ee8db5fc | ./vlang(+0x2215fc)
[ 153s] | 0x5620ee6bd61e | ./vlang(+0x361e)
[ 153s] | 0x7fb9c1a2a1f0 | /lib64/libc.so.6(+0x2a1f0)
[ 153s] | 0x7fb9c1a2a2b9 | /lib64/libc.so.6(__libc_start_main+0x8b)
[ 153s] | 0x5620ee6bd655 | ./vlang(+0x3655)
Possible Solution
No response
Additional Information/Context
No response
V version
0.4.6
Environment details (OS name and version, etc.)
If I cannot run self-test can I run doctor? I didn't even know that existed until now.
[!NOTE] You can use the 👍 reaction to increase the issue's priority for developers.
Please note that only the 👍 reaction to the issue itself counts as a vote. Other reactions and those to comments will not be taken into account.
Build your V executable without -prod, and with -g -keepc instead.
Then you will get more useful stack traces.
If I cannot run self-test can I run doctor? I didn't even know that existed until now.
Those are 2 separate commands, implemented in 2 separate programs.
Just do v doctor and paste the results please, whatever they are.
Thank you! At least I got some better output.
[ 67s] + ./vlang-stage1 -g -keepc -no-parallel -o vlang-stage2 cmd/v
[ 123s] + ./vlang-stage2 -g -keepc -o vlang cmd/v
[ 178s] + echo 'println('\''Use your package manager to update V'\'')'
[ 178s] + echo 'println('\''v self is disabled for the packaged versions of V'\'')'
[ 178s] + export VEXE=/home/abuild/rpmbuild/BUILD/vlang
[ 178s] + VEXE=/home/abuild/rpmbuild/BUILD/vlang
[ 178s] + export VTEST_SANDBOXED_PACKAGING=
[ 178s] + VTEST_SANDBOXED_PACKAGING=
[ 178s] + ./vlang doctor
[ 189s] > error while executing: /home/abuild/rpmbuild/BUILD/cmd/tools/vdoctor ['doctor']
[ 189s] V panic: No such file or directory; code: 2
[ 189s] v hash: c412b9f
[ 189s] /home/abuild/rpmbuild/BUILD/v-0.4.6/cmd/v/v.v:116: | 0x77f390 | ./vlang(main__main+0xc50)
[ 189s] /tmp/v_399/vlang.tmp.c:251144: | 0x43c74b | ./vlang(main+0x1b)
[ 189s] | 0x7fb65b640eec | /lib64/libc.so.6(+0x40eec)
[ 189s] | 0x7fb65b640fb5 | /lib64/libc.so.6(__libc_start_main+0x87)
[ 189s] /home/abuild/rpmbuild/BUILD/glibc-2.38/csu/../sysdeps/x86_64/start.S:117: | 0x43c781 | ./vlang(_start+0x21)
[ 189s] error: Bad exit status from /var/tmp/rpm-tmp.dCWZNq (%build)
@bberberov have you checked the cmd/tools directory? All the files that V uses to compile its commands should be there.
v build-tools will build the tools for you. This must be done at least once.
V in unpacked from the release source tarball.
v.c is from this commit.
The vlang binary that is produced is at the same directory level as the cmd folder and the vlib folder. I went with a longer binary name; is that a problem?
v build-tools fails exactly the same way. That's why I thought I should try v self-test, and then I learned about v doctor
...
[ 10s] + CFLAGS='-O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto'
[ 10s] + export CFLAGS
[ 10s] + CXXFLAGS='-O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto'
[ 10s] + export CXXFLAGS
[ 10s] + FFLAGS='-O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto '
[ 10s] + export FFLAGS
[ 10s] + FCFLAGS='-O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto '
[ 10s] + export FCFLAGS
[ 10s] + LDFLAGS=-flto=auto
[ 10s] + export LDFLAGS
[ 10s] + export 'VFLAGS=-g -keepc'
[ 10s] + VFLAGS='-g -keepc'
[ 10s] + gcc -std=gnu11 -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -flto=auto -lm -lpthread -o vlang-stage1 v.c
...
Lots of warnings, but no errors
...
[ 48s] + ./vlang-stage1 -g -keepc -no-parallel -o vlang-stage2 cmd/v
[ 68s] + ./vlang-stage2 -g -keepc -o vlang cmd/v
[ 87s] + echo 'println('\''Use your package manager to update V'\'')'
[ 87s] + echo 'println('\''v self is disabled for the packaged versions of V'\'')'
[ 87s] + export VEXE=/home/abuild/rpmbuild/BUILD/vlang
[ 87s] + VEXE=/home/abuild/rpmbuild/BUILD/vlang
[ 87s] + export VTEST_SANDBOXED_PACKAGING=
[ 87s] + VTEST_SANDBOXED_PACKAGING=
[ 87s] + ./vlang build-tools
[ 97s] > error while executing: /home/abuild/rpmbuild/BUILD/cmd/tools/vbuild-tools ['build-tools']
[ 97s] V panic: No such file or directory; code: 2
[ 97s] v hash: c412b9f
[ 97s] | 0x74aff1 | ./vlang(main__main+0x3d1)
[ 97s] | 0x43b91b | ./vlang(main+0x1b)
[ 97s] | 0x7feada42a1f0 | /lib64/libc.so.6(+0x2a1f0)
[ 97s] | 0x7feada42a2b9 | /lib64/libc.so.6(__libc_start_main+0x8b)
[ 97s] /home/abuild/rpmbuild/BUILD/glibc-2.39/csu/../sysdeps/x86_64/start.S:117: | 0x43b955 | ./vlang(_start+0x25)
[ 97s] error: Bad exit status from /var/tmp/rpm-tmp.iVGRTv (%build)
v doctor won't work until cmd/tools/vdoctor is built from cmd/tools/vdoctor.v.
Normally, the tools are built the first time they're used, but you have to have a successful build of V for that to happen... and it's probably not something you want in a package, anyway.
One of the many reasons I keep saying it is far too soon to make official packages for V. Cloning and building the source is the bests/most reliable method for now.
Why are you setting VEXE btw?
If it is not set, then V will try to set it itself, by looking at the path of the currently running v executable.
Imho what is happening, is that you are setting it to a folder, that is not containing the cmd/tools and its sources, then when V tries to locate them, it fails.
I think that you may be better off building everything in the same folder, and then copy only what you need from it. That will eliminate such problems.
i.e. try commenting or moving the export VEXE="%{_builddir}/%{name}"
line 53 in your https://build.opensuse.org/projects/home:bberberov/packages/vlang/files/vlang.spec?expand=1 spec file, after all the v doctor, v build-tools etc are already ran.
The other export VEXE="%{_libexecdir}/%{name}/%{name}" in line 68, that will be written in the launching script should probably stay, since it will be used to tell V where it was installed, even if it was launched as /usr/bin/vlang for example.
Imho what is happening, is that you are setting it to a folder, that is not containing the cmd/tools and its sources, then when V tries to locate them, it fails.
You are absolutely right; that was it. :facepalm: Thanks!
Now I'm getting an error I expect, and need to work on, since there is no tcc in the build environment. I already have a package of tcc; I'll see what I can do with that.
[ 55s] + ./vlang-stage1 -g -keepc -no-parallel -o vlang-stage2 cmd/v
[ 85s] + ./vlang-stage2 -g -keepc -o vlang cmd/v
[ 115s] + echo 'println('\''Use your package manager to update V'\'')'
[ 115s] + echo 'println('\''v self is disabled for the packaged versions of V'\'')'
[ 115s] + export VEXE=/home/abuild/rpmbuild/BUILD/v-0.4.6/vlang
[ 115s] + VEXE=/home/abuild/rpmbuild/BUILD/v-0.4.6/vlang
[ 115s] + export VTEST_SANDBOXED_PACKAGING=
[ 115s] + VTEST_SANDBOXED_PACKAGING=
[ 115s] + ./vlang build-tools
[ 130s] cannot compile `/home/abuild/rpmbuild/BUILD/v-0.4.6/cmd/tools/vbuild-tools.v`: 1
...
[ 130s] /usr/lib64/gcc/x86_64-suse-linux/13/../../../../x86_64-suse-linux/bin/ld: cannot find /home/abuild/rpmbuild/BUILD/v-0.4.6/thirdparty/tcc/lib/libgc.a: No such file or directory
[ 130s] collect2: error: ld returned 1 exit status
[ 130s] builder error:
[ 130s] ==================
[ 130s] C error found. It should never happen, when compiling pure V code.
[ 130s] This is a V compiler bug, please report it using `v bug file.v`,
[ 130s] or goto https://github.com/vlang/v/issues/new/choose .
[ 130s] You can also use #help on Discord: https://discord.gg/vlang .
[ 130s]
[ 130s] error: Bad exit status from /var/tmp/rpm-tmp.ykUqRO (%build)
One of the many reasons I keep saying it is far too soon to make official packages for V.
I'm not making an official package. OBS just does a great job of setting up a build environment.
tcc should be a recent one (the one most distros provide is tcc version 0.9.27 which is over 5 years old at this point, since the tcc upstream has not bothered to cut a new tagged release since then, instead they do all their development in the mob branch of https://repo.or.cz/tinycc.git/).
We do supply a prebuilt tcc executable in thirdparty/tcc/tcc.exe (downloaded by make usually, after detecting the current environment/architecture).
See https://github.com/vlang/tccbin/blob/thirdparty-linux-amd64/README.md if you want to rebuild it on your own for amd64.
libgc.a is also distributed with our prebuilt tcc btw, for legacy reasons.
You can force V to use the distro's libgc however, by using -d dynamic_boehm, i.e. try:
export VFLAGS='-d dynamic_boehm' in your build recipe, and potentially add it to the script that launches V in your package.
I looked into it earlier, and I have a tcc packaged directly from the mob branch. It built one of the weekly V releases, but I didn't go through all the warnings. It's good to know that I need a recent one, and not the last official release. If something does not work, I can re-target the tcc package by the commit ID.
I found libgc inside thirdparty, but I didn't get to figuring out why it was not building and linking. I have an official packaged libgc and will try that first, now that I know the flag for it!