"M. Warner Losh" writes:
> + /*
> + * Close the PID file, and all other open descriptors.
> + * Inherit std{in,out,err} only.
> + */
> + cfg.close_pidfile();
> + ::closefrom(3);
Actually, closefrom() is sufficient, since t
On Mon, Jun 28, 2010 at 06:39:29PM +0200, Dag-Erling Smørgrav wrote:
> Anton Shterenlikht writes:
> > I think this only happens when I copy from one xterm to another,
> > to paste into the mailer. I've checked the command which
> > I put in a file, and all seems fine. Also, the latest
> > error me
Anton Shterenlikht writes:
> http://seis.bris.ac.uk/~mexas/ia64-lzma-problem.txt
This confirms my suspicion that ld is picking up the wrong liblzma:
> attempt to open /usr/local/lib/liblzma.a succeeded
but I still can't figure out why. Can you do the following:
% make buildenv
% env
and also
On 2010-06-29 11:25, Dag-Erling Smørgrav wrote:
> Anton Shterenlikht writes:
>> http://seis.bris.ac.uk/~mexas/ia64-lzma-problem.txt
>
> This confirms my suspicion that ld is picking up the wrong liblzma:
>
>> attempt to open /usr/local/lib/liblzma.a succeeded
>
> but I still can't figure out wh
On Tue, Jun 29, 2010 at 11:25:40AM +0200, Dag-Erling Smørgrav wrote:
> Anton Shterenlikht writes:
> > http://seis.bris.ac.uk/~mexas/ia64-lzma-problem.txt
>
> This confirms my suspicion that ld is picking up the wrong liblzma:
>
> > attempt to open /usr/local/lib/liblzma.a succeeded
>
> but I st
Dag-Erling Smørgrav writes:
> This confirms my suspicion that ld is picking up the wrong liblzma:
> > attempt to open /usr/local/lib/liblzma.a succeeded
> but I still can't figure out why.
Uh, I must be blind. It uses /usr/local/lib/liblzma.a because
-L/usr/local/lib was specified on the command
Anton Shterenlikht writes:
> # make buildenv
> Entering world for ia64:ia64
> # env
> LIBRARY_PATH=/usr/local/lib
where does this come from? Your .bashrc or something?
% make buildenv
% unset LIBRARY_PATH
then run the cc command again.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
On 2010-06-29 11:59, Anton Shterenlikht wrote:
> LIBRARY_PATH=/usr/local/lib
There's your problem. Remove this environment variable, and try
buildworld again. :)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/fre
On Tue, Jun 29, 2010 at 12:03:39PM +0200, Dag-Erling Smørgrav wrote:
> Anton Shterenlikht writes:
> > # make buildenv
> > Entering world for ia64:ia64
> > # env
> > LIBRARY_PATH=/usr/local/lib
>
> where does this come from? Your .bashrc or something?
I've this set in $HOME/.tcsh. I don't rememb
2010/6/29 Anton Shterenlikht :
> On Tue, Jun 29, 2010 at 12:03:39PM +0200, Dag-Erling Smørgrav wrote:
>> Anton Shterenlikht writes:
>> > # make buildenv
>> > Entering world for ia64:ia64
>> > # env
>> > LIBRARY_PATH=/usr/local/lib
>>
>> where does this come from? Your .bashrc or something?
>
> I'
Anton Shterenlikht writes:
> However, I've got this set on 3 ia64 boxes.
> On two of them I don't have this lzma problem.
Because they either don't have liblzma installed from ports, or they
have a different version that works.
DES
--
Dag-Erling Smørgrav - d...@des.no
__
On Tue, Jun 29, 2010 at 01:26:23PM +0200, Dag-Erling Smørgrav wrote:
> Anton Shterenlikht writes:
> > However, I've got this set on 3 ia64 boxes.
> > On two of them I don't have this lzma problem.
>
> Because they either don't have liblzma installed from ports, or they
> have a different version
On 6/28/2010 11:13 PM, Giorgos Keramidas wrote:
A recent CURRENT build from /head @ 209581 panics when I run
"cdrecord -scanbus" with the attached backtrace. The culprit
seems to be the extra call fo xpt_lock_buses() added in head rev
208752, but I'm not sure if this is the real cause yet.
On 6/28/2010 11:13 PM, Giorgos Keramidas wrote:
A recent CURRENT build from /head @ 209581 panics when I run
"cdrecord -scanbus" with the attached backtrace. The culprit
seems to be the extra call fo xpt_lock_buses() added in head rev
208752, but I'm not sure if this is the real cause yet.
In message: <86r5jqdz9w@ds4.des.no>
Dag-Erling Smørgrav writes:
: "M. Warner Losh" writes:
: > + /*
: > +* Close the PID file, and all other open descriptors.
: > +* Inherit std{in,out,err} only.
: > +*/
: > + cfg.close_pidfi
"M. Warner Losh" writes:
> I went ahead and used pidfile_close in this context because that's
> what's recommended in the man page. I know it is likely redundant,
> but I thought better safe than sorry...
agreed...
DES
--
Dag-Erling Smørgrav - d...@des.no
__
On Mon, Jun 28, 2010 at 10:25:15AM -0400, Nathaniel W Filardo wrote:
> Well, I'm back in the same town as my sparc64 and so csup'd, built, and
> rebooted, trying to get more information about the "vm object not owned"
> panic I reported a while ago. To my dismay, I now get this panic, also late
>
17 matches
Mail list logo
