Ticket #70 (new defect)

Opened 13 years ago

Last modified 7 years ago

Build shared libraries for lib{dsk,gms,usp,Xj}

Reported by: andersk Owned by:
Priority: trivial Milestone: The Distant Future
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:

Description (last modified by broder) (diff)

Five of the libraries we package for Debathena are currently only available as static libraries. This causes two problems. First, changing the libraries requires recompiling any binaries that use them. Second,  Debian policy requires shared libraries to be compiled with -fPIC and static libraries without; that means that static libraries may not be linked into shared libraries, and indeed this causes problems on some architectures (at least amd64).

Attachments

shared-libgms.patch Download (1.9 KB) - added by broder 12 years ago.
Patch to build a shared libgms
shared-moira.diff.gz Download (5.7 KB) - added by broder 12 years ago.
Old packaging for a shared libmoira

Change History

comment:1 Changed 13 years ago by tabbott

  • Priority changed from major to low

Changed 12 years ago by broder

Patch to build a shared libgms

Changed 12 years ago by broder

Old packaging for a shared libmoira

comment:2 Changed 12 years ago by broder

About a month ago I submitted a patch to moiradev to build libmoira as a shared library. Garry said he would look at it, but I haven't heard back since.

Attached is a patch to make libgms a shared library, but I'm not committing that because I don't feel like packaging it at the moment.

If you want an example of how to package a shared library, I've attached shared-moira.diff.gz. That's from an old snapshot of the Moira source, so it would have to be tweaked to work against the current source tree.

comment:3 Changed 12 years ago by broder

  • Summary changed from Build shared libraries for lib{athdir,dsk,gms,locker,moira,usp,Xj} to Build shared libraries for lib{athdir,dsk,gms,moira,usp,Xj}

Oh yeah - and liblocker is going away as soon as I get around to writing the new attach/detach/etc, so that's not an issue

comment:4 Changed 12 years ago by broder

  • Upstream bug set to https://diswww.mit.edu/menelaus/moira/5409
  • Component set to --

comment:5 Changed 12 years ago by broder

  • Upstream bug changed from https://diswww.mit.edu/menelaus/moira/5409 to moira:5409

comment:6 Changed 12 years ago by jdreed

  • Upstream bug moira:5409 deleted

Moira now supports shared libmoira, according to moira-commits traffic.

 http://diswww.mit.edu/menelaus/moirac/1699
through
 http://diswww.mit.edu/menelaus/moirac/1726

comment:7 Changed 12 years ago by broder

  • Status changed from new to development

I updated debathena-moira to use the shared libmoira in r23882. I've uploaded the change to development to give everyone a chance to look over it.

I'll move it to proposed on Tuesday if nobody objects, and we can decide on when to move it to production then.

comment:8 Changed 12 years ago by broder

  • Status changed from development to proposed

Well, you all got 2 more days to object than I promised, and you still didn't say anything. This is in proposed now.

I re-snapshotted from upstream to include the fix in  moira:5443. I've also decided to drop krb4 support from our builds of Moira as part of my diabolical plan to erase krb4WWsimplify our packages in preparation for Karmic. Those changes are in r23899 and r23900, and I've uploaded the resulting packages to -proposed.

Since we have a fairly substantial set of changes at this point, I'm going to let this change sit in proposed for a week. I strongly encourage people to test and report bugs.

comment:9 Changed 12 years ago by broder

jdreed mentioned that the update_server in -proposed was causing errors:

Class: debathena Instance: apt.d
Time: Tue Jul  7 12:59:26 2009 Host: INFINITE-LOOP.MIT.EDU
From: This zephyr does not necessarily reflect the views of IS&T, MIT, its
parent companies or subsidiaries. <jdreed>

Oh, I meant to ask, when did those show up in -proposed?
I suddenly started experiencing DCM failures with "Unknown procedure"
errors, which mostly shouldn't happen

It looks like this is probably because the krb4-free patch ifdef'd out the AUTH_002 mechanism from the dispatch table in update_server.c

I think the following patch should fix the problem:

Index: update/update_server.c
===================================================================
--- update/update_server.c	(revision 23920)
+++ update/update_server.c	(working copy)
@@ -48,9 +48,7 @@
   char *str;
   void (*proc)(int, char *);
 } dispatch_table[] = {
-#ifdef HAVE_KRB4
   { "AUTH_002", auth_002 },
-#endif
   { "AUTH_003", auth_003 },
   { "XFER_002", xfer_002 },
   { "XFER_003", xfer_003 },

But I'd like some testing before I send it off to moiradev. Can Jon or somebody else who has a machine in -proposed that's receiving a DCM grab /mit/broder/Public/update_server and drop it in /usr/sbin?

comment:10 Changed 12 years ago by broder

Turns out the other issue was that the krb5 authentication code was never actually running correctly, which is why DCMs were attempting to do krb4-auth in the first place.

Patch sent in  moira:5461

comment:11 Changed 11 years ago by broder

  • Status changed from proposed to new
  • Description modified (diff)
  • Summary changed from Build shared libraries for lib{athdir,dsk,gms,moira,usp,Xj} to Build shared libraries for lib{athdir,dsk,gms,usp,Xj}

Ok. A set of Moira packages using the shared libmoira is now in production, so athdir, dsk, gms, usp, and Xj are the only statically linked libraries left.

comment:12 Changed 11 years ago by broder

Hmm...so the AC_PROC_LIBTOOL macro, which is needed to libtoolize a library, is usually incorporated into a project by the aclocal command, which puts the macro into aclocal.m4.

So until we solve #334 somehow, we can't libtoolize any of the remaining libraries in the Athena source tree, because running aclocal would scribble over the Athena aclocal.m4.

comment:13 Changed 11 years ago by jdreed

  • Milestone set to The Distant Future

comment:14 Changed 9 years ago by kcr

  • Summary changed from Build shared libraries for lib{athdir,dsk,gms,usp,Xj} to Build shared libraries for lib{dsk,gms,usp,Xj}

It looks like broder made athdir a shared library in April of 2010.

comment:15 Changed 9 years ago by kcr

There's a libtoolification of libdsk and libusp on the master branch of:

 git://github.com/kcr/discuss.git

and a libtoolification of libgms (why? WHY?) at

 git://github.com/kcr/gms.git

comment:16 Changed 7 years ago by jdreed

Now that it's the future, can we take kcr's fork of gms, not care about Xj, and move on with our lives? discuss-ng makes this moot for discuss, I think.

Note: See TracTickets for help on using tickets.