Andrew Deason writes:
> So, another interesting thing on this. heimdal gives you .la files for
> all of the various libraries, and on master, we build with libtool. So,
> libtool uses the information in the .la files, which includes -pthreads,
> so it always breaks no matter what we do with varia
On Thu, 28 Mar 2013 11:50:53 -0700
Russ Allbery wrote:
> > Should we strip it out?
>
> Maybe; it might make sense to strip it after the fact (outside of the
> imported macros) when you know you're using Solaris cc.
So, another interesting thing on this. heimdal gives you .la files for
all of th
On Thu, 28 Mar 2013 15:22:29 -0400
Eric Sturdivant wrote:
> Ok, I've got core+tcpdump files from the 3 buserver processes, as well
> as one of the butc processes. Anything in particular you are
> interested in seeing?
What I was after is the stack trace of all of the LWPs in the buserver
process
Andrew Deason writes:
> Russ Allbery wrote:
>> No, regardless of the underlying issue, the current manual library
>> probing for Heimdal libraries in rra-c-util is broken, and I'm happy to
>> fix that in rra-c-util by probing for the additional libraries.
> Well, are you treating "handle modern
On Thu, 28 Mar 2013 13:03:13 -0700
Russ Allbery wrote:
> MIT Kerberos definitely requires (or at least required) linking with
> pthreads, since without it you get undefined references to
> pthread_setspecific and the like on platforms without transitive
> shared library dependency closure. I don
Andrew Deason writes:
> For the linker? I thought for linking all it did was -lpthread (though
> it may do other things for the preprocessor or compiler). It's not a
> valid option to GNU ld, either.
It's opaque to the user. Basically, the gcc documentation says "use
-pthread and then we guaran
On Thu, 28 Mar 2013 11:50:53 -0700
Russ Allbery wrote:
> > So, what is the avenue for fixing this? Should heimdal not be giving
> > us -pthreads for --libs? (and does it avoid that, in future
> > versions?)
>
> No, it's required to get proper threading behavior, I believe.
For the linker? I tho
I should also note that RRA_LIB_KRB5 and, for that matter, krb5-config
only guarantee to provide access to the krb5 API. The reason why OpenAFS
has these problems is because OpenAFS uses functions that are not part of
the krb5 API and are provided by other libraries in both MIT Kerberos and
in Hei
Andrew Deason writes:
> No, krb5-config --deps doesn't exist in any release of heimdal I'm aware
> of (1.5.3 didn't seem to have it). And Måns is using heimdal 1.2.1,
> which certainly does not have --deps (discussed briefly offline).
windlord:~> krb5-config.heimdal --deps --libs
-L/usr/lib/i386
On Thu, 28 Mar 2013 13:26:46 -0500
Andrew Deason wrote:
> arguments reveals that Solaris Studio doesn't like -pthreads (it
> interprets it as the options -p, -h, etc, and obviously -h is not
> correct). And krb5-config does indeed say -pthreads for krb5-config
> --libs.
This tells me that heimdal
On Sat, 16 Mar 2013 12:13:04 -0700
Russ Allbery wrote:
> > The basic problem that you're having is that you aren't getting -lasn1
> > and -lhcrypto (at least). During the configure run, do you see a line
> > that says "checking for --deps support in krb5-config"? Heimdal's
> > krb5-config only
On Mon, Mar 25, 2013 at 06:56:25PM -0400, Chas Williams (CONTRACTOR) wrote:
> In message <20130325183340.ga28...@calhariz.com>,Jose Manuel dos Santos
> Calhariz writes:
> >Starting transaction on source volume 537817505 ... done
> >Allocating new volume id for clone of volume 537817505 ... done
>
the backtrace appeared not to be pthreaded buserver, only butc (which
has been true since ibm days)
On Thu, Mar 28, 2013 at 10:59 AM, Simon Wilkinson
wrote:
>
> On 28 Mar 2013, at 14:44, Andrew Deason wrote:
>> We're waiting for the buserver to respond to a BUDB_CreateDump. So,
>> presumably it i
On 28 Mar 2013, at 14:44, Andrew Deason wrote:
> We're waiting for the buserver to respond to a BUDB_CreateDump. So,
> presumably it is hanging on something. A quick glance at that suggests
> to me that it's most likely hanging on waiting for a write lock to the
> ubik database, which is presumabl
On Thu, 28 Mar 2013 08:33:26 -0400 (EDT)
Eric Sturdivant wrote:
> - lwp# 8 / thread# 8
> ff17ac78 lwp_park (0, 0, 0)
> ff174cc0 cond_wait_queue (46c338, 46c308, 0, 0, 1c00, 0) + 4c
> ff175208 cond_wait (46c338, 46c308, 4, d7690, 46c2e0, 4) + 10
> ff1
On Wed, 27 Mar 2013, Andrew Deason wrote:
On Wed, 27 Mar 2013 16:05:06 -0400 (EDT)
Eric Sturdivant wrote:
Info from the buserver and butc:
Oh, butc is threaded; cool. You'd be more likely to get more useful
results if you used 'pstack' like Derrick said, or dbx instead of gdb.
core 'bu
16 matches
Mail list logo
