win11下编译异常 #5051
Comments
Title: Compilation exception under win11 |
|
编译不过 error: @programdir\core\main.lua:329: @programdir\actions\build\main.lua:148: @programdir\modules\async\runjobs.lua:322: @programdir\modules\private\action\build\object.lua:91: @programdir\modules\core\tools\gcc.lua:886: ..\..\interface\src\luat_mobile_ec7xx.c: In function 'luat_mobile_set_apn_auth_inf':
..\..\interface\src\luat_mobile_ec7xx.c:367:9: warning: implicit declaration of function 'psSetCGAUTH'; did you mean 'psGetCGAUTH'? [-Wimplicit-function-declaration]
367 | return psSetCGAUTH(PS_DIAL_REQ_HANDLER, &req);
| ^~~~~~~~~~~
| psGetCGAUTH
..\..\interface\src\luat_mobile_ec7xx.c: In function 'luat_mobile_config':
..\..\interface\src\luat_mobile_ec7xx.c:944:7: error: 'MOBILE_CONF_RESET_TO_FACTORY' undeclared (first use in this function)
944 | case MOBILE_CONF_RESET_TO_FACTORY:
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
..\..\interface\src\luat_mobile_ec7xx.c:944:7: note: each undeclared identifier is reported only once for each function it appears in
stack traceback: |
luatos仓库没pull最新的 |
The luatos warehouse does not pull the latest one |
|
有点怪，它的 help 里面说了 支持 c376454\bin\../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ar.exe: invalid option -- @
@<file> - read options from <file> |
有点值得注意的是只有win11下会这样，win10下没问题 |
|
那就不知道了，你可以先本地测下 为啥 win11 上 ar.exe @file 不支持 |
Then I don’t know. You can test it locally first. Why is ar.exe @file not supported on win11? |
看来不是win11的问题，可能是环境问题，今天有一个客户win10系统也出现了这个问题，大部分电脑都是没问题的，我这里也无法复现，但是有几个客户的环境会出现这个问题，系统是最新版本win10/win11, |
|
It seems that it is not a problem with win11, it may be an environmental problem. Today, a customer's win10 system also has this problem. Most computers have no problem. I can't reproduce it here, but there are several customers who have this problem. Problem, the system is the latest version win10/win11, |
|
|
是这个 patch 改出来的问题，#5015 gcc-ar.exe 不支持 |
|
稍微改了下，应该可以了，不过目前不是完美方案，只能针对 gcc-ar 禁用 @file ，但是如果命令行过长，可能会有问题。 如果要同时兼容支持 先试试吧。 |
After a slight change, it should be possible. However, it is not a perfect solution at present. @file can only be disabled for gcc-ar, but if the command line is too long, there may be problems. If you want to be compatible with Try it first. |
客户反馈可以了 |
Customer feedback is available |
|
还是不行，之前可以编译的项目反而无法编译了。。。一些大一点的项目连接时候会长一些，完全无法编译了 |
我这里是必现的，gcc-ar 似乎就是处理不了 |
你那里应该和客户的情况一样，但是大部分用户没有报这个问题，我这里也编译正常，相关工程以前也一直这么用的已经有两年了 |
|
那就没办法了，目前没有更好的办法，同时兼容
你可以自己想下有没有兼容办法，反正目前我这想不到更好的办法同时支持这三种 case 。。除非有办法让 |
|
ar 支持 @file, 比较稳定，但是不支持 lto？我这里一直在用lto并没有问题呀 |
|
我这里重装了2.9.1，用之前有dev编译的工程直接编译也会出现提示不支持@ 删除掉 build缓存和.xmake之后在编译就正常了，应该还是有bug的 |
|
我可以提供我的环境给你，我们这边也有ci，都是可以编译的 https://github.com/openLuat/luatos-soc-2024/actions/runs/8905334030/job/24455883537 |
ar supports @file, which is relatively stable, but does not support lto? I have been using lto here and there is no problem. |
I have reinstalled 2.9.1 here. When directly compiling the project that was compiled by dev before, a prompt will appear that @ is not supported. After deleting the build cache and .xmake, the compilation will be normal. There should still be a bug. |
See #5015 Or if you have a way to deal with this problem compatible with ar when using ar, that's fine too |
You have to clear the cache between different versions, and cache compatibility is not guaranteed. |
I can provide you with my environment. We also have ci here, which can be compiled https://github.com/openLuat/luatos-soc-2024/actions/runs/8905334030/job/24455883537 |
Just because your environment is okay, it doesn't mean that other people's environments are okay, and the tool chains they use are different from yours, but it can only be handled in a unified way here, and it's impossible to break it down in such detail. |
We use gcc-arm-none-eabi 10, which should be somewhat different from the Linux cross-compilation tool chain. |
No, they are all our sdk, the projects are the same, the tool chains are the same, and most of them can be compiled. This is considered a bug. There is no difference in the tool chains. |
I don’t know which bug you are talking about now. Don’t mix the same issues together.
If this is the problem you are talking about, what I just said above is quite clear. I don’t have a good way to make everything compatible at the moment. .
If this is the problem you are talking about, as I just said, you just need to clear the cache. .
If this is what you are talking about, I just said that their gcc toolchain encountered lto problems, and they later changed it to gcc-ar. . |
The problem now is that a small number of users cannot compile the same sdk, and the @ problem is reported, but most people can compile it. Some gcc-ar machines do not support @file. I don’t understand this sentence. This is the support of the tool chain. Why? Could it be that the machine doesn't support it? Moreover, both of my machine environments are reproduced. It cannot be that my environment has changed back and forth. In addition, regarding the lto issue, there is not only one gcc tool chain. The Linux application platform and the bare metal platform tool chain are not the same. Gcc cannot be all the same just because of the tool chain problem of Linux applications. Bare metal ones are generally used for microcontrollers, and Linux applications are generally used for The A core compiles the Linux kernel and applications. They are inherently different and should not be bound to the same processing. The Linux tool chain does not support it, which does not mean that None does not support it either. |
It's not what you said. Your customer has this problem. Is this okay for you? Specifically why it is not supported sometimes. I have to ask gcc-ar about this. Anyway, I must have found that gcc-ar cannot handle
So, I just said that lto in your toolchain is OK, but it does not mean that lto in other users' toolchains is also OK, but it is impossible to classify it in such detail in xmake. You can also classify none, linux and various gcc cross toolchain versions one by one. Compatible, it can only be processed uniformly, either using ar.exe or gcc-ar.exe. . But no matter which one you use, either you have a problem, or other users have a problem. . I also said that at present I have no good solution, all of which are compatible with various cases of each user's toolchain. . Even if I change it back now and use ar.exe again, the user before going back will have issues again. . |
There are so many Linux toolchain versions on the market, and it is impossible for xmake to handle them all internally. It can only handle them in a unified way that can cover 90% of the case processing. . Keep the impact to a minimum. . If you want to handle each specific Linux cross toolchain in a more fine-grained manner, only user-defined toolchains can be used instead of letting xmake make various internal changes to adapt to one of the toolchains. . .
Anyway, the current situation is just these three. I can't make them all compatible, and I can't deal with each different version of gcc cross toolchain one by one. . There are currently two solutions:
|
|
目前能想到的一种完全兼容方案，#5015 (comment) 但具体是否可靠，我暂时不确定，即使可以这么搞，估计也得废几天时间。。 |
A fully compatible solution that can be thought of at present, #5015 (comment) But I am not sure whether it is reliable for the moment. Even if it can be done this way, it will probably be useless. A few days. . |
1，嵌入式使用的是裸机工具链，和linux完全分开的没有关系，不管是ARM还是其他厂家发布GCC时候都是分开的版本，完全独立的，因为完全是两个方向 |
|
|
问题基本了解为啥了，客户下载的不是发行版，所以引入了这个问题，如果回退 ar 就没问题，lto问题只存在于老版本的linux编译工具，我们使用的10以上的裸机编译工具没有此问题 所以lto问题算是老版本工具链bug，如果要支持的话是否可以根据linux gcc版本进行兼容处理？ |
I basically understand the reason for the problem. The customer downloaded is not a distribution version, so this problem is introduced. If you roll back ar, there will be no problem. The lto problem only exists in the old version of linux compilation tools. The bare metal compilation tools we use above 10 do not have it. this question So the lto problem is considered a bug in the old version of the tool chain. If it is to be supported, can it be compatible with the Linux gcc version? |
根据版本也可以，关键是得先确定是哪个版本以下不支持 lto |
It can also depend on the version. The key is to first determine which version does not support lto. |
|
而且即使根据版本切，低版本 gcc 下用 gcc-ar 。。不还是会遇到你这的问题。。低版本下还是没法完全兼容。。。仅仅只是不影响高版本了，限制了影响范围。。 应该是根据版本判断，高版本还是用 ar 不用任何处理，。低版本走 ar --plugin lto_plugin.so 去传参兼容。。 |
And even if it depends on the version, gcc-ar is used for lower versions of gcc. . No, I will still encounter your problem. . It is still not fully compatible with lower versions. . . It just doesn't affect higher versions, which limits the scope of influence. . It should be judged based on the version. For higher versions, use ar without any processing. For lower versions, use ar --plugin lto_plugin.so to pass parameters for compatibility. . |
好的，和客户说了，等客户测试一下，这个只有部分客户电脑会出现问题，
是的，这个方法可以 |
Okay, I told the customer that I will wait for the customer to test it. Only some customers' computers will have problems.
Yes, this method works |
|
现在这个 patch 应该差不多了 #5087 |
我这里测试可以正常编译，如果有客户反馈有问题我再继续反馈，先关掉了 |
My test here can compile normally. If there is any customer feedback and there are problems, I will continue to provide feedback and turn it off first. |
Xmake 版本
2.9.1
操作系统版本和架构
win11
描述问题
win10下编译正常，win11下报 ar.exe: invalid option -- @
期待的结果
正常编译
工程配置
仓库地址 ： https://gitee.com/openLuat/luatos-soc-2024
附加信息和错误日志
xmake -vD记录.txt
The text was updated successfully, but these errors were encountered: