-
-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MSYS build issues #671
Comments
On 2023-04-12 10:21, Arild Velure wrote:
I did the mistake of updating my MSYS, the latest update brings in
LLVM16 as the default and it is not so easy to roll back.
Is it in the works to support LLVM16?
The master branch as of a few weeks ago as well as the 1.9 release
should support LLVM 16.
CXXLD bin/nvc.exe
make[2]: [C:\msys64\tmp\cclZpxIF.mk:6:
C:\msys64\tmp\ccbd2Juv.ltrans1.ltrans.o] Error 1 (ignored)
make[2]: [C:\msys64\tmp\cclZpxIF.mk:78:
C:\msys64\tmp\ccbd2Juv.ltrans25.ltrans.o] Error 1 (ignored)
make[2]: [C:\msys64\tmp\cclZpxIF.mk:69:
This was also reported in #648. I don't know what causes it yet but it
seems to be harmless as the program still works correctly. You can avoid
it by passing --disable-lto to configure but there will be a small
performance loss.
Running make check-TESTS from within MSYS, then all tests except the
VHPI ones pass (vhpi[1,2,3,5] and issue612)
C:\proj\public\nvc\build\bin\nvc.exe --std=1993 -a
C:\proj\public\nvc\test\regress\vhpi3.vhd -e vhpi3 -O0 -r --load=
C:\proj\public\nvc\build\bin/../lib/vhpi3.so.exe vhpi3
** Note: loading VHPI plugin
C:\proj\public\nvc\build\bin/../lib/vhpi3.so.exe
** Fatal: failed to load
C:\proj\public\nvc\build\bin/../lib/vhpi3.so.exe
Try `make check` instead as that will also build the VHPI libraries
those tests require.
Running my own tests from native Windows I get
fatal: failed to resolve symbol memcpy
[00007FF60F69302F]
[00007FF60F735A95]
[00007FF60F6921D2]
[00007FF60F770164] vhpi_put_data+0x27c4
[00007FF60F73A932]
[00007FF60F73D011]
[00007FF60F73D068]
[00007FF60F732720]
[00007FF8217B4D0B] pthread_create_wrapper+0x9b
[00007FF855E11BB2] configthreadlocale+0x92
[00007FF8568D7614] BaseThreadInitThunk+0x14
[00007FF8580226A1] RtlUserThreadStart+0x21
This is definitely a bug. I think I know what causes it and I'll try to
fix it this evening.
I'm not able to easily test my own tests from within MSYS without
changing a lot of build scripts as it seems NVC does not like linux
style paths in the library parameter when running under MSYS, which is
what my python based build scripts choose to use under MSYS
$ nvc -L/c/proj/library --work=libname:/c/proj/library/libname
--std=08 -a /c/proj/libraries/libname/lib.vhd
fatal: invalid character ';' in library name
When you run commands from MSYS2 bash, any ':' characters in program
arguments get converted to ';'. I guess Python is running that command
through bash which triggers this behaviour. There's some explanation
here:
https://www.msys2.org/docs/filesystem-paths/
You might be able to fix it by setting `MSYS2_ARG_CONV_EXCL=--work=`. I
know @amb5l ran into this before so he may have a better solution.
|
I'm sure I pulled master yesterday, but I see it works now. I looked at the C:\msys64\tmp\cclZpxIF.mk file and it is failing on the last line shown below
Which seems like it's just a way of emptying the file and keeping the timestamp, so I guess it is harmless. The same happens when running in bash outside the python, so I guess so.
But running Latest master gives same |
OK so the problem is that |
I guess that might be a quick hack to fix it yes. |
I've implemented this now so |
Great, it now it compiles in MSYS, but I get
In native windows it works ok, also in simulation. |
Which MSYS environment is that running in? I can't reproduce that in MinGW x64 or UCRT x64. |
Never mind, needs a function with a stack frame larger than one page. E.g. entity test is
end entity;
architecture tb of test is
procedure other(x : bit_vector) is
begin
end procedure;
procedure proc is
variable b : bit_vector(1 to 10000);
begin
other(b);
end procedure;
begin
p_main: process
begin
proc;
wait for 1 ns;
end process;
end architecture; |
Should be fixed by the commit above. |
It all works from MSYS now, thanks. |
I did the mistake of updating my MSYS, the latest update brings in LLVM16 as the default and it is not so easy to roll back.
Is it in the works to support LLVM16?
I can install LLVM15 as a separate package, but they don't include LLVM15 as a shared library in that package.
Building NVC with
../configure --with-llvm=/ucrt64/opt/llvm-15/bin/llvm-config.exe --enable-static-llvm
gives a few ignored errors during compileRunning
make check-TESTS
from within MSYS, then all tests except the VHPI ones pass (vhpi[1,2,3,5] and issue612)Running my own tests from native Windows I get
I'm not able to easily test my own tests from within MSYS without changing a lot of build scripts as it seems NVC does not like linux style paths in the library parameter when running under MSYS, which is what my python based build scripts choose to use under MSYS
I don't know if these are all related issues.
The text was updated successfully, but these errors were encountered: