| Summary: | 'undefined symbol: environ' when a shared library is built which shouldn't happen according to environ(7) | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Yuri Victorovich <yuri> |
| Component: | misc | Assignee: | freebsd-toolchain (Nobody) <toolchain> |
| Status: | Closed DUPLICATE | ||
| Severity: | Affects Only Me | CC: | marklmi26-fbsd |
| Priority: | --- | ||
| Version: | 13.1-STABLE | ||
| Hardware: | Any | ||
| OS: | Any | ||
| URL: | https://reviews.freebsd.org/D30842 | ||
|
Description
Yuri Victorovich
2022-07-03 07:28:35 UTC
The -Wl,--no-undefined flag triggers it.
Testcase:
$ cat x.c
extern char **environ;
char** fn() {
return environ;
}
$ cc --shared -o x.so -fPIC -Wl,--no-undefined x.c
ld: error: undefined symbol: environ
>>> referenced by x.c
>>> /tmp/x-0e96b0.o:(fn)
cc: error: linker command failed with exit code 1 (use -v to see invocation)
(In reply to Yuri Victorovich from comment #1) What about: QUOTE An array of strings, called the environment is made available to each process by execve(2) when a process begins. END QUOTE makes you think a link-time definition binding would be available for the .so being built so that -Wl,--no-undefined could be used? Is there some other wording that I missed that implies "shouldn't happen according to environ(7)" for linking .so files? environ is implicit/automatic in the likes of: # more trivial.c // # cc -o trival trivial.c int main() { } # cc -o trivial trivial.c # nm trivial | grep environ 0000000000203aa0 B environ There should end up being only one definition, even when a so is involved at run time with the program, not separate definitions in multiple places. In fact: # ldd trivial trivial: libc.so.7 => /lib/libc.so.7 (0x200000) [preloaded] [vdso] (0x7fffffffe000) # nm /lib/libc.so.7 | grep environ U environ So even /lib/libc.so.7 has it as undefined in order to pick up the one definition at load time (not link time). (In reply to Mark Millard from comment #2) Hi Mark, Every symbol should be resolvable in some way, either through some library or it should "just exist". environ(7) suggests that it just exists, w/out the need for any libraries. And it does just exists, except when one links some shared library with particular flags. The provided example is a valid use case of environ, yet it fails without an obvious workaround that doesn't alter link flags. Yuri (In reply to Yuri Victorovich from comment #0) I found: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263265 which has related material. (In reply to Mark Millard from comment #4) Thanks! *** This bug has been marked as a duplicate of bug 263265 *** (In reply to Yuri Victorovich from comment #3) (In reply to Yuri Victorovich from comment #3) See https://reviews.freebsd.org/D30842 for the FreeBSD specific details of why not (as stands). |