On Wed, 27 Sep 2000, Bill Studenmund wrote:

> Note: deleting a shared library is effectivly bumping its major
> number. You didn't change the version # on the package which needs to
> happen in such cases.

Yes, I see now. The right thing would be to bump the requirement, too,
on all the packages that depend on xforms (belatedly).

> Did you talk to anyone who actually made one of the distribution files?
> You talked to a lot of people, yes. But no one who's beein in the source.

Now, how was I supposed to know who those people are? To be honest, it
never occurred to me to get around the closed source restriction that way.

> should just kill the libtool part rather than delete the libraries.
> 
> Please test that. It shouldn't take more than an evening to test, and it
> will either work or not. If ripping out the libtool part fixes things,
> a.out has shared libs. Otherwise we are where we were - no shared libs
> anywhere.

I tried working around libtool by backing up the orginal shared lib,
letting libtool do it's thing (to make the .la file), and then
restoring the shared libforms, but it didn't work. I just checked, and
"cp"'ing the shared file in place _does_ seem to work on m68k (for
xchiplogo), but I sure don't see where the magic is hidden. From my
point of view, the shared library is liable to break for any
particular program, on any port, at any time.

> I'm still double-checking, but I thought I had it working w/o -lGL on
> ELF. Some programs had problems, some didn't.

To actually check, empirically, every package that depends on xforms
on every port, 1.4.3, and 1.5, looks to be an enormous undertaking. 

As near as I can tell, "lyx" and other packages which depend on xforms
have _never_ _been_ runnable on m68k, and possibly other a.out ports
too. Leaving out the shared library for the 1.4.3 tag pretty much
guarantees that these ports will get working binary packages, and yes,
I do hope to revisit this later.


Frederick