[Bug 265008] 'undefined symbol: environ' when a shared library is built which shouldn't happen according to environ(7)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265008

Mark Millard <marklmi26-fbsd@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marklmi26-fbsd@yahoo.com

--- Comment #2 from Mark Millard <marklmi26-fbsd@yahoo.com> ---
(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).

-- 
You are receiving this mail because:
You are the assignee for the bug.