[BUG] --no-rosegment not supported by ld.gold from linux64 NDK r22 #1426
Comments
|
FYI: I tried simply running So most probably the issue is not host-platform-dependent. The quick work-around is to add: so |
|
ld.gold isn't present in the next release. |
|
Okay, but what are users on the current release supposed to do? Is everyone supposed to just set I'm not doing anything fancy here, no crazy arguments to externalNativeBuild or anything like that, and I'm getting a linker error when I upgrade to r22 |
|
Use LLD? The original problem you saw is the result of using ld.gold and not telling the toolchain file that you're doing so. Grep for If you don't find it I'm not sure what to look for, but you're pretty clearly ending up with ld.gold and it sounds like that isn't what you want. I can't help any more than that with the information I have. If you could upload a repro case it would probably be pretty obvious (I'm guessing that just the exercise of making the repro case would show you where the bug is) |
|
Sorry @DanAlbert , but to me it looks like the NDK team simply screwed the fix for issue #1196 for API levels under 29 and your response is a bit arrogant way not to admit that. Please try to be more humble and at least apologize for the fact the NDK r22 is broken by default for these API levels without An ETA for r23 that would fix that (can be by removing ld.gold and affecting lines in |
|
AFAICT, the LLD in r22 does support
The build scripts in NDK r22 (ndk-build and the CMake toolchain script) automatically add It's unfortunate that it's easy to hit this problem, by using I think we could have modified the Clang driver to pass |
i think that would be a huge surprise to all concerned, yes: i don't think anyone has doubted that you're seeing a problem with your build, but the NDK tests pass, the Studio tests pass, and so far only two people have reported that they're having build trouble, and no one has provided us with repro steps yet. (it also didn't help that this bug was entitled "--no-rosegment not supported by ld.gold" which -- though true -- is neither a regression nor your actual issue. your issue, as i understand it, is that your build is using gold but you don't believe you asked for gold, and think you should be getting lld.) if you won't/can't share actual repro steps with us, you're going to have to work out for yourselves why you're using gold rather than lld. you can see clearly from the command line that you supplied that you're passing
and if you read through the NDK cmake toolchain file, you can see that that's not where we would have added
don't worry --- we're more than happy to admit any mistakes, and more importantly to fix them, when NDK bugs are found! right now, though, this still doesn't look like an NDK bug, it isn't reproducible for us, and all the evidence points to "you have inconsistent settings of |
|
@rprichard I admit I was a bit too emotional and planned to double check when I reach the office. I must have remembered bad / tested with LLD from r21 by mistake some days ago. Please point me to the place where was it documented and I'll crawl back to my cave in humiliation :) |
|
It's in the changelog:
|
|
@DanAlbert Cool, thank you. This part:
was/is a bit misleading to me (though now I can see it applies to a custom build system only and not CMake). Thank you (I mean all Googlers / NDK contributors here) for your assistance here. |
|
@DanAlbert I finally figured out why I was claiming that LLD doesn't support it. Look at my msg from second post here:
I thought I've found that the LLD resides in Lesson learned - never reply on your phone, but rather read the msgs carefully while being at the machine where you can verify all the stuff :) Thx again and have a great day! |
I think that would be highly appreciated. I think with stuff like NDK you really need to think to implement stuff in a not-so-toolchain-savvy-users-resistant way. |
this was in the plan last time we talked about it, but it would have probably caused more trouble if we'd tried this before removing the other linkers, and it's a lot harder to understand or work around a problem hard-coded into the compiler than one that's in a cmake toolchain :-( the good news is that -- come r23 -- the NDK will have exactly one linker again for the first time in, well, longer than anyone who currently works on the NDK has worked on the NDK, and configuration will be simple again!
in retrospect i think maybe we shouldn't have given the custom build system instructions inline, for fear of confusing the 99%. something like: "LLD is now used by default. If your build is not yet compatible with LLD, you can continue using the deprecated linkers, set APP_LD=deprecated for ndk-build or ANDROID_LD=deprecated for CMake. See $CUSTOM_BUILD_SYSTEM_DOCS_LINK for how to use a deprecated linker in your custom build system." |
|
@enh-google Yep, that change to the Changelog would definitely work too. Anyway, at least I'm a bit wiser now regarding linkers in NDK and in general. Seems like you've done pretty good progress on (more fully) migrating to LLVM/CMake, so I'm only looking forward to what the future will bring. Thx again and keep up the good work! |
It wasn't possible to do this in r22, fwiw: #1196 (comment). We do make things like that easier when it's possible: #1294 (can subscribe for updates if you want to remove workarounds in the future) |
Yeah, I saw that comment, but I don't think I noticed #1294. I think it may have become more practical since then to fix this issue in the driver -- I commented on #1294. |
|
@DanAlbert @rprichard @enh-google Other idea for improvement could be to simply print a (CAPS) warning (or even better throw an error) if anything is put as I think that could solve most of the r21->r22 migration cases. My project was prepared for an older version of NDK/CMake and there was no This change (in theory) could be released as r22b, so less users would have issues before r23 comes. |
|
Not possible. We can't do anything after the toolchain file is done running. That's the reason you have to use |
With NDK>= 23 when we specify explicitly linker then we got the following error: ``` ld.gold: --no-rosegment: unknown option ``` From the github repository of NDK, I found that the only one right way to configure linker is using `-DANDROID_LD` variable: android/ndk#1426 (comment) Removed setting linker manually and by default `LLD` will be used. Checked that it works on the following versions of NDK: - 20.0.5594570 - 21.4.7075529 - 22.1.7171670 - 23.0.7599858 - 23.1.7779620 - 24.0.8215888 - 25.1.8937393
With NDK>= 23 when we specify explicitly linker then we got the following error: ``` ld.gold: --no-rosegment: unknown option ``` From the github repository of NDK, I found that the only one right way to configure linker is using `-DANDROID_LD` variable: android/ndk#1426 (comment) Removed setting linker manually and by default `LLD` will be used. Checked that it works on the following versions of NDK: - 20.0.5594570 - 21.4.7075529 - 22.1.7171670 - 23.0.7599858 - 23.1.7779620 - 24.0.8215888 - 25.1.8937393
With NDK>= 23 when we specify explicitly linker then we got the following error: ``` ld.gold: --no-rosegment: unknown option ``` From the github repository of NDK, I found that the only one right way to configure linker is using `-DANDROID_LD` variable: android/ndk#1426 (comment) Removed setting linker manually and by default `LLD` will be used. Checked that it works on the following versions of NDK: - 20.0.5594570 - 21.4.7075529 - 22.1.7171670 - 23.0.7599858 - 23.1.7779620 - 24.0.8215888 - 25.1.8937393
With NDK>= 23 when we specify explicitly linker then we got the following error: ``` ld.gold: --no-rosegment: unknown option ``` From the github repository of NDK, I found that the only one right way to configure linker is using `-DANDROID_LD` variable: android/ndk#1426 (comment) Removed setting linker manually and by default `LLD` will be used. Checked that it works on the following versions of NDK: - 20.0.5594570 - 21.4.7075529 - 22.1.7171670 - 23.0.7599858 - 23.1.7779620 - 24.0.8215888 - 25.1.8937393
Description
ld.goldfrom linux64 NDK claims that--no-rosegmentoption (which was introduced in #1196) is not supported.Cmd line output from armv7 build:
Same from armv8:
Environment Details
The text was updated successfully, but these errors were encountered: