git submodule update fails #1654
Comments
|
I saw this Did I miss anything? or did anything wrong? Appreciate any help. Thanks! |
|
I also just ran into this issue. This fixed it for me. |
|
Edit: actually maybe not the same issue - see my following post... |
Why are you doing the last command? |
FWIW... |
|
Thanks! I tried but still encounter the same issue. |
I don't know why you're doing |
|
@zimingH Did you try |
You don't need to do anything extra if you just follow the instructions in my previous post. |
|
Hi all, I tried again and this work if I just want to build the toolchain: but still having problem with submodule updates. I have tried |
I can't reproduce your problem using those commands. and upload the (zipped if large) |
|
This is what I get:
|
|
Hi, thanks. I can build. If I just want to build gcc and stuff key stuff, actually there is no problem anymore. That's what I was trying to say. I still cannot do submodule update. I also need some submodules like pk and spike. Now I still cannot do |
Do you mean this? If you need pk and Spike specifically then you can do this: |
|
@mickflemm - any ideas about this? |
|
I can't reproduce this in my system... Have in mind that they support shallow clones as mentioned in their git guide: |
|
Ah I noticed the checkout, this will obviously fail since the commit you mention is not fetched, you only get the latest commit when doing shallow clone (unless you ask for a specific branch when cloning): |
Hi @mickflemm - would you expect this to work? |
|
When we clone a specific tag, that commit is advertised as a reference and we can fetch it directly, for example: which also matches what we have in .gitmodules Here is a quick n dirty bash script I wrote to check if the sha and/or branch of each submodule is advertised: And its current output... Notice that the commit ids for dejagnu and spike are not advertised, so a shallow clone may fail since it won't fetch the full list of commits, but the latest few, and as new commits come it, we'll loose the one we are after. We may increase depth to 10, 100 etc in order to get more of them, and increase the probability of finding the one we are looking for, but that's not the right approach. Instead we should make sure that when adding / updating a submodule, we use a specific branch / tag and not e.g. "master" (which basically means the latest HEAD that may change in the future). The problem with dejagnu, spike and pk is that they don't do releases, so we can either go with some ancient tag they put at some point, get the latest HEAD which is probably the best option (although we risk getting bugs as well), or not do a shallow clone for those. To use the latest one, in your command add --remote --force, e.g.: As you see we should also add correct branch values for uclibc-ng, qemu, newlib, musl, and glibc, and in general improve this. We have more options when we clone through Makefile or gitnub actions, we can do more things there, even periodically update dejagnu/spike/pk automatically so that we don't risk being left behind again. I'll try to come back to this when I get some time (probably after Jan. 25), and also deal with the night release script (so that it uses the submodule cache) etc. |
|
Thanks a lot @mickflemm - that's very helpful. 👍 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
brief description
Try to do git clone and make, and then some error shows indicating this repo is missing something under binutils. Try to update the submodules. It fails.
terminal log:
The text was updated successfully, but these errors were encountered: