quickjs: fix windows build #3587

star-hengxing · 2024-03-23T12:24:59Z

SpringFesti · 2024-03-23T13:01:03Z

我感觉直接
I feel that

       io.writefile("xmake.lua", ([[
            add_rules("mode.debug", "mode.release")
            target("quickjs")
                set_toolchains("mingw")
                set_kind("shared")
                add_files("quickjs*.c", "cutils.c", "lib*.c")
                add_headerfiles("quickjs-libc.h")
                add_headerfiles("quickjs.h")
                add_installfiles("*.js", {prefixdir = "share"})
                set_languages("c99")
                add_defines("CONFIG_VERSION=\"%s\"", "_GNU_SOURCE")
                add_defines("CONFIG_BIGNUM","__USE_MINGW_ANSI_STDIO", "__MINGW__COMPILE__")
                add_syslinks("pthread")
                add_shflags("-Wl,--output-def,quickjs.def")
                set_prefixname("")
        ]]):format(package:version_str()))
        -- local arch_prev = package:arch()
        -- local plat_prev = package:plat()
        -- package:plat_set("mingw")
        -- package:arch_set(os.arch())
        import("package.tools.xmake").install(package)
        -- package:plat_set(plat_prev)
        -- package:arch_set(arch_prev)

用set_toolchains的方式貌似会更好,这样能在我的电脑上编译过
use set_toolchains would be better, it could be compiled on my computer

waruqi · 2024-03-24T11:44:51Z

packages/q/quickjs/xmake.lua

-        add_versions("2021.03.27", "b5e62895c619d4ffc75c9d822c8d85f1ece77e5b")
-        add_versions("2023.12.09", "daa35bc1e5d43192098af9b51caeb4f18f73f9f9")
-        add_versions("2024.01.13", "d6c7d169de6fb2c90cd2bd2226ba9dafdef883ce")
+        add_deps("mingw-w64")


用 llvm-mingw 也许会更好些，支持的 arch 更多，win arm64 也支持

packages/q/quickjs/xmake.lua

waruqi · 2024-03-24T11:51:02Z

我感觉直接 I feel that

       io.writefile("xmake.lua", ([[
            add_rules("mode.debug", "mode.release")
            target("quickjs")
                set_toolchains("mingw")
                set_kind("shared")
                add_files("quickjs*.c", "cutils.c", "lib*.c")
                add_headerfiles("quickjs-libc.h")
                add_headerfiles("quickjs.h")
                add_installfiles("*.js", {prefixdir = "share"})
                set_languages("c99")
                add_defines("CONFIG_VERSION=\"%s\"", "_GNU_SOURCE")
                add_defines("CONFIG_BIGNUM","__USE_MINGW_ANSI_STDIO", "__MINGW__COMPILE__")
                add_syslinks("pthread")
                add_shflags("-Wl,--output-def,quickjs.def")
                set_prefixname("")
        ]]):format(package:version_str()))
        -- local arch_prev = package:arch()
        -- local plat_prev = package:plat()
        -- package:plat_set("mingw")
        -- package:arch_set(os.arch())
        import("package.tools.xmake").install(package)
        -- package:plat_set(plat_prev)
        -- package:arch_set(arch_prev)

用set_toolchains的方式貌似会更好,这样能在我的电脑上编译过 use set_toolchains would be better, it could be compiled on my computer

切 mingw ，建议直接切 plat 而不是 toolchain，内部很多逻辑都依赖 mingw plat 的判断，不仅仅只是 toolchain，比如 mingw 平台相关的 target 可执行后缀名等，都是平台决定的，不是 toolchain

SpringFesti · 2024-03-24T11:56:17Z

切 mingw ，建议直接切 plat 而不是 toolchain，内部很多逻辑都依赖 mingw plat 的判断，不仅仅只是 toolchain，比如 mingw 平台相关的 target 可执行后缀名等，都是平台决定的，不是 toolchain

主要是最后的导出库是给msvc用的，所以我感觉plat仍然用windows会更好,这样相关的库以及后缀都是windows平台格式的
还有这样可以直接用windows本身的运行库而不需要mingw的运行库了

Issues-translate-bot · 2024-03-24T11:56:27Z

Bot detected the issue body's language is not English, translate it automatically.

When switching to mingw, it is recommended to switch directly to plat instead of toolchain. Many internal logics rely on the judgment of mingw plat, not just the toolchain. For example, the target executable suffix name related to the mingw platform is determined by the platform, not the toolchain.

The main reason is that the final export library is for msvc, so I feel it would be better if the platform still uses windows, so that the relevant libraries and suffixes are in the windows platform format.

Issues-translate-bot · 2024-03-24T11:56:52Z

Bot detected the issue body's language is not English, translate it automatically.

When switching to mingw, it is recommended to switch directly to plat instead of toolchain. Many internal logics rely on the judgment of mingw plat, not just the toolchain. For example, the target executable suffix name related to the mingw platform is determined by the platform, not the toolchain.

The main reason is that the final export library is for msvc, so I feel it would be better if the platform still uses windows, so that the relevant libraries and suffixes are in the windows platform format.

waruqi · 2024-03-24T12:11:20Z

切 mingw ，建议直接切 plat 而不是 toolchain，内部很多逻辑都依赖 mingw plat 的判断，不仅仅只是 toolchain，比如 mingw 平台相关的 target 可执行后缀名等，都是平台决定的，不是 toolchain

主要是最后的导出库是给msvc用的，所以我感觉plat仍然用windows会更好,这样相关的库以及后缀都是windows平台格式的还有这样可以直接用windows本身的运行库而不需要mingw的运行库了

plat 是 windows 而 toolchain 是 mingw ，最后生成的库 bin 格式还是 gnulib，仅仅只是后缀名是 .lib ，要让 msvc 可用，得转成 mslib ，这个不是只改 plat 就行的

Issues-translate-bot · 2024-03-24T12:11:30Z

Bot detected the issue body's language is not English, translate it automatically.

When switching to mingw, it is recommended to switch directly to plat instead of toolchain. Many internal logics rely on the judgment of mingw plat, not just the toolchain. For example, the target executable suffix name related to the mingw platform is determined by the platform, not the toolchain.

The main reason is that the final export library is for msvc, so I feel that it would be better if the platform still uses windows. In this way, the relevant libraries and suffixes are all in the windows platform format, and in this way, the runtime library of windows itself can be used directly without the need MinGW's runtime library

plat is windows and the toolchain is mingw. The bin format of the finally generated library is still gnulib, but the suffix is .lib. To make msvc usable, it must be converted to mslib. This does not just require changing plat.

SpringFesti · 2024-03-24T12:21:11Z

plat 是 windows 而 toolchain 是 mingw ，最后生成的库 bin 格式还是 gnulib，仅仅只是后缀名是 .lib ，要让 msvc 可用，得转成 mslib ，这个不是只改 plat 就行的

静态库确实没办法互通，但是动态库dll能够生成def再生成一个导出库.lib让msvc可用。完全的静态链接我感觉应该是无法实现的，因为mingw的库和msvc实在无法互通。所以我在最上面让windows只能进行动态链接了。也好在C没有name mangling, 所以动态库可以互通使用

add_configs("shared", {description = "Build shared library.", default = true, type = "boolean", readonly = true})

waruqi · 2024-03-24T13:26:03Z

plat 是 windows 而 toolchain 是 mingw ，最后生成的库 bin 格式还是 gnulib，仅仅只是后缀名是 .lib ，要让 msvc 可用，得转成 mslib ，这个不是只改 plat 就行的

静态库确实没办法互通，但是动态库dll能够生成def再生成一个导出库.lib让msvc可用。完全的静态链接我感觉应该是无法实现的，因为mingw的库和msvc实在无法互通。所以我在最上面让windows只能进行动态链接了。也好在C没有name mangling, 所以动态库可以互通使用
add_configs("shared", {description = "Build shared library.", default = true, type = "boolean", readonly = true})

我没说静态库，我说的就是动态库的导出库 .lib 的格式，你 plat windows ，toolchain mingw ，最后生成的动态库即使是 .dll ，它的导出库，还是走的 mingw toolchain 是 gnulib 格式的，还是要转下的，避免不了，反而可能遗漏掉其他一些 mingw 平台下的处理，所以通常走 mingw 编译，就完整且 mingw plat ，也不会因为后期 xmake 又加了什么 mingw 相关的改动，漏掉一些处理，最后对生成的 mingw 的 dll 和 dll.a 走 gnu2mslib 处理下就行了。。

xmake-io/xmake#1181

SpringFesti · 2024-03-24T14:06:03Z

我没说静态库，我说的就是动态库的导出库 .lib 的格式，你 plat windows ，toolchain mingw ，最后生成的动态库即使是 .dll ，它的导出库，还是走的 mingw toolchain 是 gnulib 格式的，还是要转下的，避免不了，反而可能遗漏掉其他一些 mingw 平台下的处理，所以通常走 mingw 编译，就完整且 mingw plat ，也不会因为后期 xmake 又加了什么 mingw 相关的改动，漏掉一些处理，最后对生成的 mingw 的 dll 和 dll.a 走 gnu2mslib 处理下就行了。。

xmake-io/xmake#1181

两种方式我都测试运行了一下，结果好像是一样的，都能正常运行。我之前担心用mingw做plat会导致编译出来的dll和mingw结合过于紧密，但是最后发现两种方式都一样，免不了要引入mingw的dll，是我想多了。

我dumpbin了一下quickjs.dll

           if mingw and bindir then
                os.vcp(path.join(bindir, "libgcc_s_seh-1.dll"), package:installdir("bin"))
                os.vcp(path.join(bindir, "libwinpthread-1.dll"), package:installdir("bin"))
                os.vcp(path.join(bindir, "libstdc++-6.dll"), package:installdir("bin"))
            end

libstdc++应该是不需要的，可以少复制一个dll
最后应该再加一个package:addenv("PATH", "bin")吧，不然xmake run的时候会找不到这个dll

waruqi · 2024-03-24T14:17:22Z

我没说静态库，我说的就是动态库的导出库 .lib 的格式，你 plat windows ，toolchain mingw ，最后生成的动态库即使是 .dll ，它的导出库，还是走的 mingw toolchain 是 gnulib 格式的，还是要转下的，避免不了，反而可能遗漏掉其他一些 mingw 平台下的处理，所以通常走 mingw 编译，就完整且 mingw plat ，也不会因为后期 xmake 又加了什么 mingw 相关的改动，漏掉一些处理，最后对生成的 mingw 的 dll 和 dll.a 走 gnu2mslib 处理下就行了。。
xmake-io/xmake#1181

两种方式我都测试运行了一下，结果好像是一样的，都能正常运行。我之前担心用mingw做plat会导致编译出来的dll和mingw结合过于紧密，但是最后发现两种方式都一样，免不了要引入mingw的dll，是我想多了。

我dumpbin了一下quickjs.dll
           if mingw and bindir then
                os.vcp(path.join(bindir, "libgcc_s_seh-1.dll"), package:installdir("bin"))
                os.vcp(path.join(bindir, "libwinpthread-1.dll"), package:installdir("bin"))
                os.vcp(path.join(bindir, "libstdc++-6.dll"), package:installdir("bin"))
            end
libstdc++应该是不需要的，可以少复制一个dll

既然只生成 dll，为啥不用 -static-libgcc 呢，gcc dll 都不用 copy，走 static link 呗，libwinpthread-1.dll 说不定也能干掉。。

xmake 的 mingw 版本，我记得是不依赖任何 mingw dll 的。。

https://github.com/xmake-io/xmake/blob/e9cf2231246548d342de3583b5b7baa1a0fe8842/core/src/demo/xmake.lua#L39

Issues-translate-bot · 2024-03-24T14:26:10Z

Bot detected the issue body's language is not English, translate it automatically.

I didn’t say static library, I said the .lib format of the exported library of the dynamic library. You plat windows, toolchain mingw, even if the dynamic library finally generated is .dll, its exported library is still using the mingw toolchain, which is gnulib The format still needs to be transferred. It cannot be avoided. Instead, some other processing under the mingw platform may be missed. Therefore, usually mingw compilation is complete and mingw plat, and there will be no mingw-related changes added by xmake later. , missing some processing, and finally use gnu2mslib to process the generated mingw dll and dll.a. .

xmake-io/xmake#1181

I have tested and run both methods, and the results seem to be the same and both can run normally. I used to worry that using MinGW as a platform would cause the compiled DLL to be too closely integrated with MinGW, but in the end I found that both methods were the same, and it was inevitable to introduce MinGW's DLL, but I was overthinking it.

star-hengxing · 2024-03-24T14:28:22Z

C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.38.33130\bin\HostX64\ARM64\lib.exe /def:quickjs.def /name:quickjs.dll /out:quickjs.lib

C:\Users\runneradmin\AppData\Local\.xmake\packages\q\quickjs\2024.01.13\fec0128b47694d7c9d7e0f15be45a465\lib\quickjs.lib : warning LNK4272: library machine type 'x64' conflicts with target machine type 'ARM64'

看起来还是要传 /Machine:arch，否则就会生成 host 的 .lib

Issues-translate-bot · 2024-03-24T14:28:31Z

Bot detected the issue body's language is not English, translate it automatically.

C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.38.33130\bin\HostX64\ARM64\lib.exe /def:quickjs.def /name:quickjs.dll /out:quickjs. lib

C:\Users\runneradmin\AppData\Local\.xmake\packages\q\quickjs\2024.01.13\fec0128b47694d7c9d7e0f15be45a465\lib\quickjs.lib : warning LNK4272: library machine type 'x64' conflicts with target machine type 'ARM64'

It seems that you still need to pass /Machine:arch, otherwise the .lib of the host will be generated.

waruqi · 2024-03-24T14:41:28Z

C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.38.33130\bin\HostX64\ARM64\lib.exe /def:quickjs.def /name:quickjs.dll /out:quickjs.lib

C:\Users\runneradmin\AppData\Local\.xmake\packages\q\quickjs\2024.01.13\fec0128b47694d7c9d7e0f15be45a465\lib\quickjs.lib : warning LNK4272: library machine type 'x64' conflicts with target machine type 'ARM64'

看起来还是要传 /Machine:arch，否则就会生成 host 的 .lib

应该跟这个没关系吧，cl/link 我也从来不设置这个，选择 arch 都是跟当前 msvc envs 绑定的，估计是执行 lib.exe 没绑定当前 arch 的 msvc envs 导致

刚我改了下，再重跑下试试 xmake-io/xmake@08fd85a

SpringFesti · 2024-03-24T14:42:04Z

既然只生成 dll，为啥不用 -static-libgcc 呢，gcc dll 都不用 copy，走 static link 呗，libwinpthread-1.dll 说不定也能干掉。。

xmake 的 mingw 版本，我记得是不依赖任何 mingw dll 的。。

https://github.com/xmake-io/xmake/blob/e9cf2231246548d342de3583b5b7baa1a0fe8842/core/src/demo/xmake.lua#L39

quickjs里面可能用了什么特殊的库，导致它必须得链接libgcc了，我这边加上了也还是会依赖libgcc。但是我另开了一个测试工程就不会依赖libgcc

waruqi · 2024-03-24T14:43:30Z

既然只生成 dll，为啥不用 -static-libgcc 呢，gcc dll 都不用 copy，走 static link 呗，libwinpthread-1.dll 说不定也能干掉。。
xmake 的 mingw 版本，我记得是不依赖任何 mingw dll 的。。
https://github.com/xmake-io/xmake/blob/e9cf2231246548d342de3583b5b7baa1a0fe8842/core/src/demo/xmake.lua#L39

quickjs里面可能用了什么特殊的库，导致它必须得链接libgcc了，我这边加上了也还是会依赖libgcc。但是我另开了一个测试工程就不会依赖libgcc

确定这个 flag 加进去并且生效了？ dll 得用 add_shflags

Issues-translate-bot · 2024-03-24T14:44:14Z

Bot detected the issue body's language is not English, translate it automatically.

C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.38.33130\bin\HostX64\ARM64\lib.exe /def:quickjs.def /name:quickjs.dll /out:quickjs .lib

C:\Users\runneradmin\AppData\Local\.xmake\packages\q\quickjs\2024.01.13\fec0128b47694d7c9d7e0f15be45a465\lib\quickjs.lib : warning LNK4272: library machine type 'x64' conflicts with target machine type 'ARM64'

It seems that you still need to pass /Machine:arch, otherwise the host's .lib will be generated

It should have nothing to do with this. I never set this in cl/link. The selected arch is bound to the current msvc envs. It is probably caused by executing lib.exe without binding the msvc envs of the current arch.

I just changed it, try running it again xmake-io/xmake@08fd85a

SpringFesti · 2024-03-24T14:45:40Z

确定这个 flag 加进去并且生效了？ dll 得用 add_shflags

我的问题。用add_shflags就不依赖了，我加到ldflags里面了

Issues-translate-bot · 2024-03-24T14:56:23Z

Bot detected the issue body's language is not English, translate it automatically.

Since only dll is generated, why not use -static-libgcc? You don’t need to copy gcc dll, just use static link. Maybe libwinpthread-1.dll can also be killed. .

The mingw version of xmake, I remember, does not depend on any mingw dll. .

https://github.com/xmake-io/xmake/blob/e9cf2231246548d342de3583b5b7baa1a0fe8842/core/src/demo/xmake.lua#L39

There may be some special library used in quickjs, which causes it to have to be linked to libgcc. Even if I add it here, it will still rely on libgcc. But if I open another test project, it will not depend on libgcc.

Issues-translate-bot · 2024-03-24T15:00:05Z

Bot detected the issue body's language is not English, translate it automatically.

Since only dll is generated, why not use -static-libgcc? You don’t need to copy gcc dll, just use static link. Maybe libwinpthread-1.dll can also be killed. .
The mingw version of xmake, I remember, does not depend on any mingw dll. .
https://github.com/xmake-io/xmake/blob/e9cf2231246548d342de3583b5b7baa1a0fe8842/core/src/demo/xmake.lua#L39

There may be some special library used in quickjs, which causes it to have to be linked to libgcc. Even if I add it here, it will still rely on libgcc. But if I open another test project, it will not depend on libgcc.

Are you sure this flag has been added and taken effect? dll must use add_shflags

Issues-translate-bot · 2024-03-24T15:01:09Z

Bot detected the issue body's language is not English, translate it automatically.

Are you sure this flag is added and takes effect? dll must use add_shflags

my question. Use add_shflags to avoid dependence. I added it to ldflags.

star-hengxing · 2024-03-25T00:11:50Z

LINK : warning LNK4068: /MACHINE not specified; defaulting to X64

@waruqi

star-hengxing added 2 commits March 23, 2024 20:21

quickjs: fix windows build

e1556f3

improve xmake.lua

6309821

star-hengxing changed the title ~~Quickjs windows fix~~ quickjs: fix windows build Mar 23, 2024

star-hengxing added 2 commits March 23, 2024 21:39

static link dep lib in shared kind

32d3175

add todo

873b028

star-hengxing requested a review from waruqi March 23, 2024 14:06

waruqi reviewed Mar 24, 2024

View reviewed changes

packages/q/quickjs/xmake.lua Show resolved Hide resolved

use gnu2mslib

d646fd6

star-hengxing closed this Mar 24, 2024

star-hengxing reopened this Mar 24, 2024

star-hengxing closed this Mar 25, 2024

star-hengxing reopened this Mar 25, 2024

waruqi merged commit 7c5f205 into dev Mar 25, 2024
176 of 189 checks passed

waruqi deleted the quickjs-windows-fix branch March 25, 2024 03:00

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

quickjs: fix windows build #3587

quickjs: fix windows build #3587

star-hengxing commented Mar 23, 2024

SpringFesti commented Mar 23, 2024

waruqi Mar 24, 2024

waruqi commented Mar 24, 2024 •

edited

Loading

SpringFesti commented Mar 24, 2024 •

edited

Loading

Issues-translate-bot commented Mar 24, 2024

Issues-translate-bot commented Mar 24, 2024

waruqi commented Mar 24, 2024

Issues-translate-bot commented Mar 24, 2024

SpringFesti commented Mar 24, 2024 •

edited

Loading

waruqi commented Mar 24, 2024

SpringFesti commented Mar 24, 2024 •

edited

Loading

waruqi commented Mar 24, 2024

Issues-translate-bot commented Mar 24, 2024

star-hengxing commented Mar 24, 2024

Issues-translate-bot commented Mar 24, 2024

waruqi commented Mar 24, 2024

SpringFesti commented Mar 24, 2024

waruqi commented Mar 24, 2024

Issues-translate-bot commented Mar 24, 2024

SpringFesti commented Mar 24, 2024

Issues-translate-bot commented Mar 24, 2024

Issues-translate-bot commented Mar 24, 2024

Issues-translate-bot commented Mar 24, 2024

star-hengxing commented Mar 25, 2024

quickjs: fix windows build #3587

quickjs: fix windows build #3587

Conversation

star-hengxing commented Mar 23, 2024

SpringFesti commented Mar 23, 2024

waruqi Mar 24, 2024

Choose a reason for hiding this comment

waruqi commented Mar 24, 2024 • edited Loading

SpringFesti commented Mar 24, 2024 • edited Loading

Issues-translate-bot commented Mar 24, 2024

Issues-translate-bot commented Mar 24, 2024

waruqi commented Mar 24, 2024

Issues-translate-bot commented Mar 24, 2024

SpringFesti commented Mar 24, 2024 • edited Loading

waruqi commented Mar 24, 2024

SpringFesti commented Mar 24, 2024 • edited Loading

waruqi commented Mar 24, 2024

Issues-translate-bot commented Mar 24, 2024

star-hengxing commented Mar 24, 2024

Issues-translate-bot commented Mar 24, 2024

waruqi commented Mar 24, 2024

SpringFesti commented Mar 24, 2024

waruqi commented Mar 24, 2024

Issues-translate-bot commented Mar 24, 2024

SpringFesti commented Mar 24, 2024

Issues-translate-bot commented Mar 24, 2024

Issues-translate-bot commented Mar 24, 2024

Issues-translate-bot commented Mar 24, 2024

star-hengxing commented Mar 25, 2024

waruqi commented Mar 24, 2024 •

edited

Loading

SpringFesti commented Mar 24, 2024 •

edited

Loading

SpringFesti commented Mar 24, 2024 •

edited

Loading

SpringFesti commented Mar 24, 2024 •

edited

Loading