Date: Tue, 05 Jan 1999 13:52:36 -0800 (PST) From: John Polstra <jdp@polstra.com> To: current@FreeBSD.ORG Subject: HEADS UP: Suffix change for PIC object files Message-ID: <XFMail.990105135236.jdp@polstra.com>
next in thread | raw e-mail | index | archive | help
I want to commit a change which I believe will have zero impact on
anybody. The change is broad in scope, so I thought I'd better check
to make sure it won't cause unanticipated problems.
What I want to do is modify <bsd.lib.mk> and a couple of assorted
Makefiles, to change the filename suffix for PIC object files used in
building shared libraries from ".so" to ".So". The reason is that
the existing suffix conflicts with the standard suffix for shared
libraries that are loaded with dlopen(). One example of that is PAM
modules. Even ignoring PAM, we can expect to see more and more use of
dlopen() in our tree as time goes on.
Now, just to make this crystal clear, I'm not talking about changing
the suffix for shared libraries, or for anything that actually gets
installed by "make world". All I want to change is the suffix of the
intermediate PIC object files that make up the shared libraries. The
PIC object files exist only during the build process, and they never
escape the "/usr/obj" tree. This won't change what's on installed
systems one bit.
Modules to be loaded using dlopen() have traditionally been named
"*.so" in all Unix variants I'm aware of. This usage of ".so"
predates FreeBSD's use of the same suffix for PIC object files. The
suffixes need to be different to avoid clobbering files when building
dynamically loaded modules.
I should also stress that this won't affect 3rd party applications
(including ports) at all. They don't use <bsd.lib.mk>, and they are
free to use any suffix they want to for their PIC object files.
I've tested this change through several "make world" cycles, and it
hasn't caused any problems that I can see.
If any of you can think of a compelling reason not to make this
change, please let me know. I'll commit it this coming weekend
otherwise.
One final note. Questions like this often lead to interminable
threads consisting mainly of squabbles about peripheral and
inconsequential issues. I and all of the other readers would greatly
appreciate it if you'd confine your responses to _compelling_ reasons
not to make the change. If you simply don't like changes, or don't
like my choice of suffix, then please spare us a long and pointless
diversion.
Thanks,
John
---
John Polstra jdp@polstra.com
John D. Polstra & Co., Inc. Seattle, Washington USA
"Nobody ever went broke underestimating the taste of the American public."
-- H. L. Mencken
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.990105135236.jdp>