Re: Help- selective symbol exposure after link

Jason Spielman <jason@interval.net> wrote:
  >Q: How does one link several object files into a single object file
  > or library, where symbols are resolved locally as much as possible,
  > and where only selected symbols are exported/exposed/made public?


David L Moore (dlmoore@ix.netcom.com) wrote:
: The original question is not one that should be shrugged off.


I heartily agree, for all the reasons outlined.


: [...] This does not work with C or C++ because you can always redeclare
: objects rather than import the appropriate specification (.h)


: Perhaps you would not do this, but if you have twenty or more
: programmers helping you build your system, are you sure they all would
: not do that? How will you check?


Spot checks combined with scorn and ridicule heaped on the
offenders in the company cafeteria do a _fair_ job :-) But I also
agree with the next line, and was actually posting to comment on the
moderators comment:


: So, if you want to write serious software in C or C++, you really need
: your tools to support exactly the facility that Jason is asking for.


: [What gets me is that implementing this stuff shouldn't be very hard. Don't
: know why it hasn't become more popular. -John]




I'm not so sure it isn't "more popular", just not "more common
commercially". I've implemented such a facility, either directly in a
linker or by writing a "selective strip" utility a few times. No, it
wasn't hard. Perhaps because it isn't hard, programmers in bygone days
did not worry overmuch about it and just "did it themselves", each in
his own little workshop.


Today's emphasis on huge, monolithic "Integrated Development
Environments" (read: "Use what we provide and quit whining") with
proprietary object (and even source) code file formats make it a lot
less likely. If the vendor won't even document the object or library
format, and won't provide the facility as part of their tool, you
don't get it, period. If you are writing modules for use on a variety
of platforms, and even one tool-vendor makes this sort of thing
impossible (in real life, most block it), your design can't use it.


No good whining, as the platform, and often the tools, were
not chosen by the programmer in the trenches. That's just life in the
"software as a commodity" world we live in. Now, if some brave soul
wanted to unravel, say, the FSF tools enough to make something like
this easy, then we'd all have a fairly big hammer to hit recalcitrant
vendors with. But FSF, and even Cygnus, do not seem overly concerned
with embedded development (Note to Cygnus sales: We already have your
MIPS embedded tools. don't call), nor should they without a stack of
money from somebody, and I'm not done paying for my new roof yet :-)
Of course, if they _did_ provide the function, and I wrote my code to
depend on it (not re-validating parameters in non-gateway function)
I'd catch hell from the guy who had to port my code to a PC with
Borland or MicroSoft C.


Yes, I could _use_, but be careful not to _depend_ on,
"selective exportation" in my code. Of course, management would
complain that I wasted any time worrying about it, and question why I
want to give Cygnus any money to develop it :-)


Mike
--

Return to the comp.compilers page.
Search the comp.compilers archives again.