Re: On the cost of libraries

[Drazen Kacar <dave willfork com>]

Colm Smyth wrote:
> >> It can also be quite handy when trying to resolve
> >> nasty problems, for example when trying to combine
> >> two libraries that each expect to be able to override
> >> the C++ global new() operator, you can specify a different
> >> "global" new() symbol binding for each library!
> >
> >Uh... I think this would backfire sooner or later. How about using -B group
> >or -z groupperm instead?
> 
> Why do you think it would backfire? You can't get more explicit than
> actually stating precisely the library that contains a symbol
> definition.

Yeah, but... I don't know what would happen if the next installed version
of that library (binary compatible) just happens not to contain that
particular symbol. Nothing good, I presume. C++ is not my area and this
particular example might be safe for all I know. But in general I would
try to be very cautious with things like that.

I suppose that this kind of hacks would require this particular library to
contain that particular symbol. And then you need to pass that requirement
on to all the people who will work on that source and builds in the
future. With a single person in charge from now to eternity, things might
be safe and under control. With more people and distributed development
model all kinds of misunderstandings might arise. I could try to come up
with examples involving -B direct, but that would be beside the point. In
my experience up so far, a huge number of bugs and bad design decisions
could have been prevented if only somebody invested some time in writing
the documentation (or reading the existing documentation) instead of
cranking out the code. That's the point.

The libraries I'm compiling and installing on my systems use a great
number of funky and esoteric flags. They are fast, they take less memory
than what would the default installation take and they are safe. I've never
had problems with linking systems since I decided to invest some time in
learning how those systems work. But if I'd let somebody without
equivalent knowledge to upgrade those libraries and applications, all hell
would break loose. Most of the developers I've worked with never thought
they should learn how their tools (compilers, linkers, debuggers, etc.)
work. That's sad, but it's a fact of life and poses some restrictions on
what one might consider as safe.

> I didn't know about the -B group and -z groupperm options,  looking
> at the man-page I can see they would also be useful in a number
> of situations.

Hmm, then you probably don't know about some other things, undocumented
flags included. Ask your linker folks[1] about things they'd have ready by
the time you'd start testing production builds and base your strategy on
that. IMHO, the linking system is one of the best parts of Solaris, people
who work on that are good and reliable and I'd trust them. If you need
something they don't currently provide, just ask for it. There's at least
one linker feature which was implemented specifically because one of the
Gnome libraries needed it, so we have the precedent. :-)

[1] rie eng sun com would be a good starting point.

-- 
 .-.   .-.    Errors have been made. Others will be blamed.
(_  \ /  _)
     |        dave willfork com
     |
_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers