Elliott Sales de Andrade
Elliott Sales de Andrade
At the moment, build dependencies are added without version and runtime dependencies are added automatically due to shared library linkage. Additionally, something gets hashed into the library name causing them...
When building on [s390x](https://koji.fedoraproject.org/koji/taskinfo?taskID=35535066), tests fail: ``` --- FAIL: TestRefStrings (0.00s) murmur_test.go:41: [Hash32] key: 'hello', seed: '0': 0x84c85fd5 (want 0x248bfa47) murmur_test.go:48: [Hash32] key: 'hello', seed: '0': 84c85fd5 (want 248bfa47) murmur_test.go:52:...
When building `aws` 0.16 against `http-client` 0.4.28, I get: ```haskell Aws/Ec2/InstanceMetadata.hs:21:12: error: Not in scope: ‘HTTP.parseUrlThrow’ Perhaps you meant ‘HTTP.parseUrl’ (imported from Network.HTTP.Conduit) Module ‘Network.HTTP.Conduit’ does not export ‘parseUrlThrow’. ```...
Not sure why this wasn't causing issues at the time of #101. Also, I _think_ the bounds check isn't necessary in this case because the `Int64Val` would have already done...
Along with some upstream changes (below), this allows a full build on armv7hl. https://github.com/Auburns/FastNoiseSIMD/commit/32873404111701397781fe9ef21931fed4f7f766 https://github.com/Auburns/FastNoiseSIMD/commit/575c0047bbfd2bac841359daa9db220a9f97a638 https://github.com/Auburns/FastNoiseSIMD/pull/27 https://github.com/Auburns/FastNoiseSIMD/pull/32
This seems to be a flaky error. I had to repeat builds 3 times until it passed, and the error was slightly different each time. The failure is something like:...
With Go 1.18, I am getting the following error when running `make tinygo-test`: ``` ld.lld: error: undefined symbol: getpagesize >>> referenced by os_linux.go:122 (/builddir/build/BUILDROOT/tinygo-0.25.0-1.fc36.x86_64/usr/lib64/tinygo/src/runtime/os_linux.go:122) >>> /tmp/tinygo863360999/main.o:(os_test.TestGetpagesize) error: failed to link...
It appears that all CI that uses Go 1.18 is still pinned on 1.18.1, but with 1.18.4, there is a new failure that did not occur in 1.18.3, with `make...
Or really, it's more of a workaround, by simply disabling the tests that can't run, as mentioned in #2824.
This avoids having to guess what the linker name-with-build-triplet is, as we can just pass the target to it in the same way as the compilation stage. Close #1536.