M2 Pro, arm64 system architecture got Linking failed with exit code: 1 #428
Comments
|
From the information you have supplied, it is difficult to offer suggestions. Have you looked at the information here https://tada.github.io/pljava/build/build.html#Troubleshooting_the_build and on the build tips page it links to? They will suggest ways of capturing more useful information (and then how to filter that down to the key information most useful to report). |
|
@jcflack , yes i checked the build info page and troubleshoot page. log info i can share more here... It seems issue with arm64 architecture. |
|
It looks to me as if it may have been a slightly-dubious shortcut taken 19 years ago, that a modern compiler is taking issue with. The case for the shortcut may have been that the function does nothing but But honestly, with only three uses and all in one source file, I don't think it would hurt to have six more lines of code 19 years later, and specialize the function, and eliminate the need to make assumptions about it. |
|
May i know, Is any plan to merge those fixes ? |
|
I wonder whether those three warnings are a red herring here. I also see them in the CI testing here, but only as warnings and they do not fail the build. Also, they are compiler warnings, and your failure seems to be from the linker. Your linker message is saying "can't link with a main executable file ... for architecture x86_64". You've mentioned you're on Is it possible the build script is finding an I'm not sure why there would be an |
|
This issue, along with #411, seems to relate to the Mac OS compiler and linker ending up with some objects built for This may be a matter of not getting the right options to the compiler or linker during the build. In It may be that the "Mac OS X" configuration needs to be either adjusted to use the right command options on both I do not have ready access to an |
jcflack
added a commit
that referenced
this issue
Feb 20, 2025
None of this is related at all to JEP 472, but some is needed to catch up with changes on the GitHub runners as the CI would otherwise fail. The macos-12 runner is gone, and it was the last macos one that supplied PostgreSQL preinstalled. So rename the workflow from ci-runnerpg to ci-lazypg ... it still uses the preinstalled PG on runners that have one, but now resorts to brew to install it on macos. The macos-13 runner is still Intel-based (and needs PG installed). The macos-14 runner is ARM64-based (and needs PG installed). The runners have some Java versions preinstalled, so check for those and only fetch a JDK if the matrix.java version isn't one of the preinstalled ones. Preinstalled versions can be found by their JAVA_HOME_$VERSION_$ARCH environment variables, except that when $ARCH is ARM64 the environment variable has arm in lowercase. So much for consistency. There are newer versions of the setup-java and checkout actions. The old ones elicited warnings about a deprecated Node.js version. The old setup-java, when running on macos ARM64 (or arm64), would happily install an x86_64 JDK. Which would seem to work fine, apparently running in a compatibility mode, apparently inherited by the C compiler and linker spawned from Maven. The linker would then report baffling errors about not finding symbols in PostgreSQL for x86_64! This is the exact sort of mystery seen and not yet solved in issues #411 and #428. So, running Maven on a JDK that's for the wrong architecture is now a known way to cause such a problem, and worth checking in such a case. Added some ::group:: / ::endgroup:: to make the log output more easily perused.
|
Recent CI runs (see, for example, c5f9ae4) include the GitHub Actions However, while updating the CI scripts, I did encounter a similarly puzzling linker error that listed a lot of PostgreSQL internal symbols and said it could not find them for The cause in my case turned out to be that the GitHub Actions The solution was to make sure that the JDK being used was built for |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Error log
I have arm64 system architecture. It's failing on project pljava-so
Originally posted by @sandeep2244 in #411 (comment)
The text was updated successfully, but these errors were encountered: