Conversation

Richard Weinberger

Hunting down bugs on embedded systems is not always fun. That one was.

https://sigma-star.at/blog/2025/06/deep-down-the-rabbit-hole-bash-overlayfs-and-a-30-year-old-surprise/
3
10
12

@rw wouldn’t it be fine to change the default to no broken cwd in bash’s configure.ac if cross compilation and glibc was detected? Instead of hacking each and every Linux cross compile setup/tooling..

1
0
0
@manut sure. I'd go so far and suggest removing the getcwd() fallback at all.
2
0
1

@rw @manut I agree 😁. Now that you've analyzed all of this and drew conclusions, what's keeping you from posting a patch to bash to remove the broken getcwd fallback? 😎

1
0
0

@rw wouldn’t this break bootstrapping an OS without a getcwd implementation? Not sure if this is relevant as of today..

1
0
0
@manut I meant for Linux. Having the fallback available on Linux makes no sense.
1
0
0
@agraf @manut
I did report the issue already:
https://lists.gnu.org/archive/html/bug-bash/2025-06/msg00149.html

Given the responses so far, I'm not sure whether I want to continue this path.
1
0
0

@rw this would be fine. Thanks for taking care and sharing!

0
0
0

@rw @manut Definitely worthwhile. Don't feed the trolls 😁. That dude is just a random person with too much time on theor hands. If you send a patch, the conversation will go differently. In the patch, stress that it's broken in multiple ways (overlayfs & errno) and effectively a completely untested code path that clearly saw no real life use because otherwise at least the errno thing would have been caught by now.

0
0
1

@rw i don't want to throw shade at all, just curious... do you roll your own build environment or was it another well known one?

1
0
0
@stefanct It's an in-house solution developed and maintained by one of my customers.
0
0
1