[02:40:27] --- pod has become available [02:43:32] --- Simon Wilkinson has become available [04:10:47] --- pod has left [05:51:24] --- meffie has become available [06:40:27] --- jaltman/FrogsLeap has left: Disconnected [07:26:08] --- jaltman/FrogsLeap has become available [07:38:40] --- deason has become available [10:14:32] --- jaltman/FrogsLeap has left: Disconnected [10:36:45] --- jaltman/FrogsLeap has become available [10:45:30] --- jaltman/FrogsLeap has left: Disconnected [10:45:38] --- jaltman/FrogsLeap has become available [11:10:01] --- rra has become available [11:13:01] Derrick, I don't follow your remark about nm(1). (If I put an explicit /usr/lib/libcom_err.so at the end of the link line, the linker is happy.) [11:23:13] /usr/lib/libcom_err isn't the only com_err on the system, since you have $srcdir/lib/libcom_err.a, which is what that line would appear to be picking up [11:23:26] we must have run into this before, not that I know how to solve it [11:25:49] > .a Nit, but it looked like it was linking dynamically? [11:27:21] Anyway, I see this on FBSD 7.3 but not (I think) on newer versions. And it's not really clear what would have changed. [11:43:07] does the compile line look the same? [11:43:18] it's possible on different versions we don't need -lcom_err to use -lkrb5 [11:44:18] It should ... I don't believe krb5-config --libs has changed [11:44:34] and we don't give you a .so in $srcdir/lib; I assumed if it found $srcdir/lib/libcom_err.a, it wuld use that before /usrl/ib/libcom_err.so, but I dunno, I'm just theorizing [11:45:55] you could try temporarily moving $srcdir/lib/libcom_err.a out of the way and run the compile line by hand, and see if it works :) [11:46:09] An ancient build log from a more modern OS: cc -o aklog -I/usr/include -DALLOW_REGISTER -I/usr/ports/net/openafs/work/openafs-1.5.72/src/config -I/usr/ports/net/openafs/work/openafs-1.5.72/include -I. -I. -O2 -pipe -fPIC aklog.o krb_util.o linked_list.o -lkrb5 -lcom_err -lcrypto -lcrypt -lasn1 -lhx509 -lroken /usr/ports/net/openafs/work/openafs-1.5.72/lib/libprot.a /usr/ports/net/openafs/work/openafs-1.5.72/lib/libauth.a /usr/ports/net/openafs/work/openafs-1.5.72/lib/libubik.a /usr/ports/net/openafs/work/openafs-1.5.72/lib/librxkad.a /usr/ports/net/openafs/work/openafs-1.5.72/lib/libsys.a /usr/ports/net/openafs/work/openafs-1.5.72/lib/librx.a /usr/ports/net/openafs/work/openafs-1.5.72/lib/libsys.a /usr/ports/net/openafs/work/openafs-1.5.72/lib/liblwp.a /usr/ports/net/openafs/work/openafs-1.5.72/lib/libdes.a /usr/ports/net/openafs/work/openafs-1.5.72/lib/libcom_err.a /usr/ports/net/openafs/work/openafs-1.5.72/lib/libcmd.a /usr/ports/net/openafs/work/openafs-1.5.72/lib/libafsutil.a [11:46:44] I'm pretty sure that -lfoo looks for libfoo.so if no -static is given and libfoo.a if it is given. [11:48:42] notice the lack of a -L$srcdir/lib in that line [11:57:38] Hmm, so maybe I should try a fresh master on a more modern system for comparison, then. [12:16:36] hmm, has anyone noticed anything odd with buildbot? I don't _think_ I've seen buildbot mark anything verified in the past day or two [12:16:50] maybe I'm just being impatient, but I don't think I see the relevant slaves waiting on anything [14:46:39] buildbot fails to update gerrit when the same sha1 value shows up in two gerrit tickets. This can happen as a result of a ticket being abandoned and the patchset resubmitted. I've sent Jason an e-mail asking him to check. [15:12:39] I don't think it's that. I think buildbot is stuck. Nothing has been marked verified since Dec 7. [15:13:27] Builds do still seem to be happening, it's just that the results aren't being reported to gerrit. [15:14:59] deason/kaduk: We really shouldn't be calling our com_err by the same name as the system one. We don't provide any of the same symbols any more. [15:18:38] yeah, which is why I was thinking this must have happened before [15:18:57] or is fbsd the only place we need to -lcom_err, or something? [15:19:39] My suspicion is that on Linux, we've got better versioning information, so we don't end up getting the local one when we really want the system one. [15:20:50] Ah. Helps if I read more scrollback. [15:23:20] Anywhere which is using heimdal should need -lcom_err , I think. [15:24:12] MIT has -lcom_err too, I believe. [15:25:44] If you're on a platform with shared library dependencies, then those dependencies will get used, rather than specifying the full list of libraries to the linker. [15:26:06] I guess FBSD doesn't have dependency support, or the Heimdal build you're linking against doesn't have that information. [15:26:50] I'm not entirely sure I understand what is meant by "shared library dependencies". Is this related to symbol versioning? [15:27:28] you get to specify that libkrb5.so needs libcom_err.so when you create libkrb5.so [15:27:47] so the code using libkrb5 just needs to say -lkrb5, and libcom_err.so gets linked without you having to specify it [15:29:32] Hmm, I thought we did that. [15:29:45] Our autoconf code supports it, and if it finds that you're on a platform with dependency support, it will just use -lkrb5, rather than using the output from krb5-config [15:30:20] try 'ldd /usr/lib/libkrb5.so' ? [15:30:22] Iff you build with --enable-reduced-depends. [15:31:05] Ah, it's not unconditional? Hmmm. So that isn't in play here. [15:31:13] It's not the default because assuming that transitive shared library dependencies work is not the conservative choice. [15:31:26] And writing an Autoconf probe to see if they work was more than I wanted to tackle. [15:31:44] We just use krb5-config by default if you don't do anything special and if we can find it on the path. [15:31:47] I can understand that. such a probe would be ... interesting [15:32:12] Hmm, my ldd claims libkrb5.so only depends on libc.so.7 [15:33:04] But, say, libgssapi_krb5.so depends on a whole pile of stuff. [15:33:19] Regardless of why this works for everyone else, I think the correct fix for master is to rename libcom_err to libafscom_err and be done with it. [15:33:29] We stopped shipping a compatible com_err years ago. [15:36:04] Haha, you said "compatible" and "com_err" in the same sentence. [15:36:15] Yeah. My bad. [15:42:49] --- deason has left [15:42:50] --- deason has become available [15:43:26] I have a plan for mostly-compatible com_err; I just haven't had time to do it. It's based on the observation that the interface to error_message() itself is fairly consistent, and so all we need to do is completely ignore all the registration interfaces, load the data by parsing tables instead, and get on with life. [15:55:54] I created a horrible hack for aklog which allows you to chain multiple com_err's together, which at least means that you can decode Kerberos errors and AFS errors in the same process. [16:18:18] --- deason has left [17:30:35] --- deason has become available [17:34:13] Is someone (Simon?) planning on looking at the libafscom_err rename, or should I add it to my list? [17:38:23] --- jaltman/FrogsLeap has left: Disconnected [18:12:07] --- rra has left: Disconnected [18:34:45] --- Russ has become available [19:15:22] --- jaltman/FrogsLeap has become available [19:46:09] do we have to worry about other users of our com_err? [19:47:32] it was because of other users of our com_err that we did not rename it [20:03:16] --- asedeno has left [20:03:19] --- asedeno has become available [21:20:28] --- deason has left [21:30:02] --- Russ has left: Disconnected