patch to unhook libxpg4 and liby from build

[Chris Pressey]

On Sat, 27 Mar 2004 22:48:41 -0500
David Rhodus <drhodus at xxxxxxxxxxx> wrote:

> On Mar 27, 2004, at 7:41 PM, Chris Pressey wrote:
> > http://catseye.webhop.net/DragonFlyBSD/patch/unhook_libxpg4_liby.diff
> >
> > If someone can confirm that these libraries really are really and
> > truly 100% obsolete, I'll enqueue the patch.
> >
> > -Chris
> 
> Chris, I first off want to say thanks to bringing this up and just 
> making
> hasty decisions that may or may not have repercussions on the
> system that aren't felt right away.

It's just like Animal Crossing - the axe is the most fun to use, but you
have to consider very very carefully before you ever actually use it  :)

> On FreeBSD the XPG4 support was started in a separate library other
> than libc. During 4.5-RELEASE the basic functionality that FreeBSD
> had was merged into libc. With that in mind, there are still some
> ISV's that try to link BSD against libxpg4. A quick search on the
> machine next to me here shows about 6 ports that made a compile time
> link. These would have resulted in a ports breakage. I'm not sure
> there is really any over-head associated with leaving this stub
> around. Though, I'm open to any cleaver idea's people might have for
> this stub relocation.
> Perhaps it would be best to leave this, at least for now.
> 
> Liby is also something I don't think we want to remove. One thing in
> particular that still uses it is yacc and some other compiler tools.
> I also think libipsec or something along those lines pulls an external
> reference from it.  Again, I think this functionality could be masked
> some place else but would most likely add increased linking overhead
> in general.

These are very good points.

I'd be willing to patch ports to make them behave, but it's software
that that's *not* in the ports that's the real problem, as we have zero
control over it.

So, the absolute cleverest idea I can come up with at the moment is to
introduce a patch to ld (and gcc?) that simply makes it ignore -ly and
-lxpg4 options, when they are given.  Trapping something that tries to
load libxpg4.so would probably be much harder, and likely not worth the
effort.

(FWIW, I can't find any reference to liby in libipsec - in fact, all the
occurances of -ly that I did find had no effect when I removed them. 
And there should be no shared object issue, as no shared object version
of liby is built AFAICT.)

I'm not really worried about overhead as much as just clutter.  I'm
also less worried about clutter when it's documented clutter...  I guess
my basic concern is accessibility.  The gentler we can make the learning
curve - the fewer bits of cruft hanging around, the less our source tree
looks like a maze, and the less intimidating everything is - the more
eyeballs we can attract, which in the open-source arena should be the
long-term win.

At any rate, I still think we can remove -ly from our Makefiles with
impunity.  (We aren't using -lxpg4 anywhere.)  I'll tweak the patch to
do that and only that, leaving liby and libxpg4 connected to the build,
and put that version up for further discussion.

Thanks,
-Chris