On Tue, 2011-11-08 at 23:34 +0000, Matthieu Herrb wrote: > On Tue, Nov 08, 2011 at 04:05:06PM -0500, Gaetan Nadon wrote: > > On Mon, 2011-11-07 at 19:57 +0000, Matthieu Herrb wrote: > > > > > This logically reverts 7e223d3ac6c0d549a7d6e4dcc86a053e19594028. > > > There are still cases (in particular OpenBSD) where the shared > greeter > > > is not desired. > > > > My reading at the time was the static version was there because some > O/S > > did not have loadable libraries support (this greeter seems to be > very > > old code). Can you add in the commit text (if you know) the reasons > why > > OpenBSD would not be able to use a shared library? Less chances of > being > > removed in a few years from now. I thought all platforms could use > > shared libraries. > > OpenBSD/vax (don't laugh please) is still a.out and doesn't have > shared libs. Yet it can run xdm (no X server though since the ability > of statically linking the drivers was lost a few years ago :().
Fair enough, consider adding this info in the commit text. > > But this is not the main reason. Basically the shared object doesn't > give us any benefit. So why bother with the extra complexity and > failures cases that it introduces ? > I had considered doing just that at the time. I recall having seen on the net a site showing how to create a custom greeter. That made me choose shared vs static having the (wrong) assumption that all platforms supported shared libs. > > > > > > > > BTW, Ubuntu 11.10 and Fedora 15 both ship xdm 1.10 with the shared > > > greeter disabled too. > > > > And we don't if there are reasons for that or if it is just an old > build > > script that works... > > As Alan pointed out, there is no real reason to keep the shared object > version as long as no one provides alternate greeters that could be > plugged in to replace the default one. > > If you want to shrink the source, I would rather drop the support for > the dynamic greeter. > I am not opposed at all to a static only build. Perhaps a next patch should do that. This would certainly reduce module complexity. >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
