Looks like I made a mistake.
Sorry for any inconvenience the advice may have caused.
Regards,
Lanny
On Thu, 2003-09-25 at 01:13, Greg 'groggy' Lehey wrote:
> On Thursday, 25 September 2003 at 1:12:21 -0400, Lanny Baron wrote:
> > On Wed, 2003-09-24 at 22:42, Greg 'groggy' Lehey wrote:
> >> On
On Thursday, 25 September 2003 at 1:12:21 -0400, Lanny Baron wrote:
> On Wed, 2003-09-24 at 22:42, Greg 'groggy' Lehey wrote:
>> On Thursday, 25 September 2003 at 3:04:52 +0200, Willem Jan Withagen wrote:
>>> Hi,
>>>
>>> I'm trying to upgrade my firewall/router to 5.x but I'm getting caught by
>>
On Wed, 24 Sep 2003, Loren James Rittle wrote:
> >I was looking through gcc last night to see how conceptually difficult
> >it would be to do something like this. But instead of a file, I was
> >thinking of this process:
> >
> >* if env("PTHREADS_LIBS") then LDFLAGS += PTHREADS_LIBS
> >* elseif f
Perhaps 'The Complete FreeBSD' by Greg Lehey will help out.
We always suggest it.
Regards,
Lanny
On Wed, 2003-09-24 at 22:42, Greg 'groggy' Lehey wrote:
> On Thursday, 25 September 2003 at 3:04:52 +0200, Willem Jan Withagen wrote:
> > Hi,
> >
> > I'm trying to upgrade my firewall/router to 5.x
So, after running this laptop with debugging stuff and INVARIANTS on all
day and having it work fine, I decided to try taking the INVARIANTS
options out of the kernel. Lo and behold, it now hangs again when I try
to boot. I can't even get it to respond when I hit Ctrl-Alt-Esc and try
to get it to g
>I was looking through gcc last night to see how conceptually difficult
>it would be to do something like this. But instead of a file, I was
>thinking of this process:
>
>* if env("PTHREADS_LIBS") then LDFLAGS += PTHREADS_LIBS
>* elseif fileexists("libpthread") then LDFLAGS += -lpthread
>* elseif
On Thursday, 25 September 2003 at 3:04:52 +0200, Willem Jan Withagen wrote:
> Hi,
>
> I'm trying to upgrade my firewall/router to 5.x but I'm getting caught by
> the fact that I cannot find a 'sl0' interface.
Are you really still using SLIP? What's wrong with PPP?
> I've tried the both with if_
Hi,
I'm trying to upgrade my firewall/router to 5.x but I'm getting caught by
the fact that I cannot find a 'sl0' interface.
I've tried the both with if_sl compiled into the kernel as well as a module.
In neither case does ifconfig show a sl0 device.
In the module-env kldstat does show if_sl.ko
I've got an IBM ThinkPad R40 that hangs when I do a "shutdown -p". It s
wedges after printing "Powering system off using ACPI". The display
stays on, and judging by the heat, it seems that the CPU is on as well.
It doesn't respond to the keyboard, so I haven't been able to get into
DDB. The only
> FWIW, I have the same problem on my amd64 boxes at home. It will not see
> the drive if its in slave mode. It too happens to be a seagate.
>
> > If I revert a 1.10 revision of ata-lowlevel.c (#ifdef 0 a section of
> > probing code), the disc is back and works absolutely fine.
>
> I'll try the
On Wed, 24 Sep 2003, Thomas Quinot wrote:
> Le 2003-09-19, Guillaume écrivait :
>
> > Thanks for the patch. cd0 is faster now and ATAPICAM works great.
> > Are you going to commit the patch?
>
> DMA is now enabled for ATAPI/CAM i/o, as of atapi-cam.c rev. 1.26.
> Thanks to all who tested and revie
On Wednesday 24 September 2003 23:11, Daniel Eischen wrote:
> On Wed, 24 Sep 2003, John Baldwin wrote:
> > On 23-Sep-2003 Dan Naumov wrote:
> > > On Tue, 2003-09-23 at 23:25, Dan Naumov wrote:
> > >> On Tue, 2003-09-23 at 23:13, Daniel Eischen wrote:
> > >> > I understand that folks want to wave th
> Hi, I want to report a regression in ATAng. It's exactly same problem
> that Richard Nyberg reported on current@ 9 days ago.
>
> After updating to today -current, my system no longer see primary slave
> hard drive. It's one year old Seagate 80 GB hard drive.
FWIW, I have the same problem on my
In message: <[EMAIL PROTECTED]>
Daniel Eischen <[EMAIL PROTECTED]> writes:
: I plan on changing thread library compatibility for FreeBSD
: 6.0, though. So it might be wise just to add a different
: compiler switch for libthr or libc_r.
FYI: gcc 3.4 will have -pthread accross the board
Robert Watson wrote:
> Based on the results seen thus far, my preference would really be for:
>
> (1) Keep -pthread, make it imply -lpthread, saving a lot of hassle.
Regarding the switch, the gcc folks have been adding -pthread as the
'standard' way to enable pthreads across the board for all pl
Hi, I want to report a regression in ATAng. It's exactly same problem
that Richard Nyberg reported on current@ 9 days ago.
After updating to today -current, my system no longer see primary slave
hard drive. It's one year old Seagate 80 GB hard drive.
If I revert a 1.10 revision of ata-lowlevel.c
V st, 24. 09. 2003 v 20:56, Vitalis píše:
> > How about using xmms-cdread in ${PORTSDIR}/audio/xmms-cdread?
> > With this module xmms can read the CDDA discs as data via IDE bus.
> Thanks for your answer. I've just installed the port, but when I launch
> xmms, I get this message:
> /usr/X11R6/lib
On Wed, 24 Sep 2003, Daniel Eischen wrote:
> On Wed, 24 Sep 2003, Michael Edenfield wrote:
>
> > * Ian Dowse <[EMAIL PROTECTED]> [030924 12:03]:
> > > In message <[EMAIL PROTECTED]>, Daniel
> > > Eischen writes:
> > > >On Wed, 24 Sep 2003, Scott Long wrote:
> > > >> PTHREAD_LIBS is a great tool
Ulrich Spoerlein ([EMAIL PROTECTED]) wrote:
> On Wed, 24.09.2003 at 01:23:07 +0200, Julian St. wrote:
> > > I've been experiencing (especially) the lag in audio and/or video when
> > > seeking within media files. I kicked out all the debugging stuff, but
> > > it didn't make a difference.
> >
> >
On Wed, 24 Sep 2003, Michael Edenfield wrote:
> * Ian Dowse <[EMAIL PROTECTED]> [030924 12:03]:
> > In message <[EMAIL PROTECTED]>, Daniel
> > Eischen writes:
> > >On Wed, 24 Sep 2003, Scott Long wrote:
> > >> PTHREAD_LIBS is a great tool for the /usr/ports mechanism, but doesn't
> > >> mean anyt
On Wed, 24 Sep 2003 01:29:15 +0300 (EEST)
Vladimir Kushnir <[EMAIL PROTECTED]> wrote:
[XMMS/etc patches]
> Unfortunately, no. But I can post them - they're not big (obviously
> :-)
I would be particularly interested in the XMMS patch.
Regards,
Julian Stecklina
--
"Think. Think think. Thin
< said:
> Eek, no. Libpthread is libpthread, libthr is libthr, etc. A
> symlink doesn't help you anyways because the library/application
> becomes dependent on the thing it is symlink'd to, not the
> symlink.
That depends on what the SONAME entry says It is technically
feasible to have lib
On Wed, 24 Sep 2003, Matthew N. Dodd wrote:
> On Wed, 24 Sep 2003, Daniel Eischen wrote:
> > It isn't clear that libmap can deal with libraries that are
> > linked to one specific threads library, and how libmap'd
> > applications work. If mplayer is libmap'd to libthr,
> > ogle is libmap'd to li
On Wed, 2003-09-24 at 07:05, Sang Woo Shim wrote:
> Hello.
> How about using xmms-cdread in ${PORTSDIR}/audio/xmms-cdread?
> With this module xmms can read the CDDA discs as data via IDE bus.
>
>
> On Tue, Sep 23, 2003 at 11:13:29PM +0200, Vitalis wrote:
> > Hi,
> >
> > On my box there is an Asu
In message <[EMAIL PROTECTED]>, Ulrich Spoerlein writes:
>
>--OwLcNYc0lM97+oe1
>Content-Type: text/plain; charset=iso-8859-1
>Content-Disposition: inline
>Content-Transfer-Encoding: quoted-printable
>
>On Tue, 23.09.2003 at 10:27:12 +0200, Poul-Henning Kamp wrote:
>> On sparc64 (or with geom_sunlab
On Wed, 24 Sep 2003, Daniel Eischen wrote:
> It isn't clear that libmap can deal with libraries that are
> linked to one specific threads library, and how libmap'd
> applications work. If mplayer is libmap'd to libthr,
> ogle is libmap'd to libpthread, and both are linked to
> libGL which is linke
Le 2003-09-19, Guillaume écrivait :
> Thanks for the patch. cd0 is faster now and ATAPICAM works great.
> Are you going to commit the patch?
DMA is now enabled for ATAPI/CAM i/o, as of atapi-cam.c rev. 1.26.
Thanks to all who tested and reviewed the change.
Thomas.
--
[EMAIL PROTECTED]
___
On Wed, Sep 24, 2003 at 05:03:28PM +0100, Ian Dowse wrote:
> Just to throw one further approach out on the table, below is a
> patch that makes gcc read from a file to determine what library to
> associate with the -pthread flag. It's a hack of course, and probably
> neither correct or optimal. If
On Wednesday 24 September 2003 19:36, Bruce M Simpson wrote:
> On Wed, Sep 24, 2003 at 06:14:52PM +0200, Michael Nottebrock wrote:
> Content-Description: signed data
>
> > On Wednesday 24 September 2003 04:18, Kris Kennaway wrote:
> > > icecast-1.3.12_1
> >
> > I don't have a -CURRENT machine to te
On Wed, 24 Sep 2003, Dan Nelson wrote:
> In the last episode (Sep 24), Daniel Eischen said:
> > On Wed, 24 Sep 2003, Scott Long wrote:
> > > Daniel Eischen wrote:
> > > > o Doesn't break applications that use both -pthread and
> > > > -l. We've been able to link both libc_r and libc
> > > >
On Wed, Sep 24, 2003 at 06:14:52PM +0200, Michael Nottebrock wrote:
Content-Description: signed data
> On Wednesday 24 September 2003 04:18, Kris Kennaway wrote:
>
> > icecast-1.3.12_1
>
> I don't have a -CURRENT machine to test with. I don't mind the port marked
> BROKEN, since it's unsupported
On Wed, 24 Sep 2003, Garrett Wollman wrote:
> I think it was John Baldwin who wrote:
>
> >> I think having a magic option to gcc that translates to 'link with the
> >> foo library' is rediculous. What's next, a gcc -math to get the math
> >> functions in libm?
>
> As far as POSIX is concerned, t
* Michael Edenfield <[EMAIL PROTECTED]> [030924 13:21]:
> * Ian Dowse <[EMAIL PROTECTED]> [030924 12:03]:
> > In message <[EMAIL PROTECTED]>, Daniel
> > Eischen writes:
> > >On Wed, 24 Sep 2003, Scott Long wrote:
> > >> PTHREAD_LIBS is a great tool for the /usr/ports mechanism, but doesn't
> > >>
* Ian Dowse <[EMAIL PROTECTED]> [030924 12:03]:
> In message <[EMAIL PROTECTED]>, Daniel
> Eischen writes:
> >On Wed, 24 Sep 2003, Scott Long wrote:
> >> PTHREAD_LIBS is a great tool for the /usr/ports mechanism, but doesn't
> >> mean anything outside of that.
> >
> >That just meant it makes it ea
On Wed, 24 Sep 2003, Dan Nelson wrote:
> Does it really matter if you end up linked to multiple threads
> libraries? The first library providing a symbol wins, so the other
> shlibs just won't get used at all. Libraries linked from the executable
> trump libraries linked from libraries, and LD_
In the last episode (Sep 24), Daniel Eischen said:
> On Wed, 24 Sep 2003, Scott Long wrote:
> > Daniel Eischen wrote:
> > > o Doesn't break applications that use both -pthread and
> > > -l. We've been able to link both libc_r and libc
> > > in -current for well over 2 years. Indeed, if y
I think it was John Baldwin who wrote:
>> I think having a magic option to gcc that translates to 'link with the
>> foo library' is rediculous. What's next, a gcc -math to get the math
>> functions in libm?
As far as POSIX is concerned, that's precisely how it works. `c99
foo.c -l m' means `lin
On 24-Sep-2003 Daniel Eischen wrote:
> On Wed, 24 Sep 2003, John Baldwin wrote:
>
>>
>> On 23-Sep-2003 Dan Naumov wrote:
>> > On Tue, 2003-09-23 at 23:25, Dan Naumov wrote:
>> >> On Tue, 2003-09-23 at 23:13, Daniel Eischen wrote:
>> >> > I understand that folks want to wave their hands and say "
Poul-Henning Kamp wrote:
This patch moves the SCSI cd driver under GEOM.
On sparc64 (or with geom_sunlabel in your kernel) try inserting a
solaris install CD and then:
true > /dev/cd0 # make GEOM taste media
ls -l /dev/cd*
You should now be able to see the boot partitions.
It
On Wed, 24 Sep 2003, Ian Dowse wrote:
> In message <[EMAIL PROTECTED]>, Daniel
> Eischen writes:
> >On Wed, 24 Sep 2003, Scott Long wrote:
> >> PTHREAD_LIBS is a great tool for the /usr/ports mechanism, but doesn't
> >> mean anything outside of that.
> >
> >That just meant it makes it easier to m
On Wednesday 24 September 2003 04:18, Kris Kennaway wrote:
> icecast-1.3.12_1
I don't have a -CURRENT machine to test with. I don't mind the port marked
BROKEN, since it's unsupported abandonware and due for deorbit anyway.
--
,_, | Michael Nottebrock | [EMAIL PROTECTED]
(/
In message <[EMAIL PROTECTED]>, Daniel
Eischen writes:
>On Wed, 24 Sep 2003, Scott Long wrote:
>> PTHREAD_LIBS is a great tool for the /usr/ports mechanism, but doesn't
>> mean anything outside of that.
>
>That just meant it makes it easier to maintain ports so that
>they are PTHREAD_LIBS complian
On Wed, Sep 24, 2003 at 10:27:29AM -0500, Jacques A. Vidrine wrote:
> At link time, either (a) I want *this* threaded library damnit, or (b)
^^^
> that one threading library might provide but not another.
As an aside, apparently I
[Mostly trying to stay out of this thread, but I must comment at
least on this point.]
On Wed, Sep 24, 2003 at 11:01:01AM -0400, Daniel Eischen wrote:
> On Wed, 24 Sep 2003, Scott Long wrote:
> > Daniel Eischen wrote:
> > > o Allows shared libraries (Qt, GTK, OpenGL, etc) to be built that
> > >
On Wed, 24 Sep 2003, John Baldwin wrote:
>
> On 23-Sep-2003 Dan Naumov wrote:
> > On Tue, 2003-09-23 at 23:25, Dan Naumov wrote:
> >> On Tue, 2003-09-23 at 23:13, Daniel Eischen wrote:
> >> > I understand that folks want to wave their hands and say "just make
> >> > -pthread work and do whatever
On Wed, 24 Sep 2003, Scott Long wrote:
> Daniel Eischen wrote:
> > I'm running out of energy here. None of the threads guys want -pthread
> > and if forced on them would prefer it to be a NOOP. I am trying very
> > hard not to be biased towards one threads library over another, and
> > having -p
On 23-Sep-2003 Scott Long wrote:
> Daniel Eischen wrote:
>> This is about 3rd party applications built outside of
>> ports. The only possible problem you are going to
>> have is on the link command, and it should be obvious
>> that you're missing a link to the threads library.
>> This is trivial
>
> On Wed, 24 Sep 2003, Scott Long wrote:
>
>> I'm a big advocate of using libmap to deal with this.
>
> Ditto.
>
> Based on the results seen thus far, my preference would really be for:
>
> (1) Keep -pthread, make it imply -lpthread, saving a lot of hassle.
>
> (2) Ship all packages and binaries
On Wed, 24 Sep 2003, Scott Long wrote:
> I'm a big advocate of using libmap to deal with this.
Ditto.
Based on the results seen thus far, my preference would really be for:
(1) Keep -pthread, make it imply -lpthread, saving a lot of hassle.
(2) Ship all packages and binaries using threading w
* Will Andrews <[EMAIL PROTECTED]> [030924 01:50]:
> On Wed, Sep 24, 2003 at 01:34:13AM -0400, Michael Edenfield wrote:
> > One very important group of ports that should get looked at when this
> > gets worked out is KDE. Apparently, Qt uses a different means of
> > determining wether to use threa
On 23-Sep-2003 Dan Naumov wrote:
> On Tue, 2003-09-23 at 23:25, Dan Naumov wrote:
>> On Tue, 2003-09-23 at 23:13, Daniel Eischen wrote:
>> > I understand that folks want to wave their hands and say "just make
>> > -pthread work and do whatever it needs to".
>>
>> I am one of those folks as well.
>Date: Wed, 24 Sep 2003 00:58:12 -0500
>From: "Conrad J. Sabatier" <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: dhclient/ipfw conflict on boot
>I just ran into this today after upgrading. It seems that dhclient is
>unable to initialize properly at boot time, due to the prior initializati
At 7:35 PM -0400 2003/09/23, Daniel Eischen wrote:
The applications is free to link to whatever it wants;
we're not changing that. If it wants to link to 1:1
libthr or whatever, then it had better be sure to use
-lthr because -pthread won't do it regardless of whether
it is a NOOP or not.
I
On (2003/09/24 20:18), John Birrell wrote:
> > Okay, so what are we supposed to do to ports that are now broken because
> > -pthread doesn't exist (e.g. devel/pwlib)?
>
> -pthread is back in current. It just had a little holiday. It's back,
> refreshed, eager and willing to do the deed. 8-)
That
Why don't we make -pthread link to the *default*
thread library (kse)?
Solaris has a similar -mt option:
-mt Passes D_REENTRANT to preprocessor. Appends
-lthread after all other user-specified libraries
on
the command line. If you are doing your own
multithread coding, you must u
On Wed, Sep 24, 2003 at 11:51:53AM +0200, Sheldon Hearn wrote:
> Okay, so what are we supposed to do to ports that are now broken because
> -pthread doesn't exist (e.g. devel/pwlib)?
-pthread is back in current. It just had a little holiday. It's back,
refreshed, eager and willing to do the deed.
On (2003/09/23 19:35), Daniel Eischen wrote:
> The applications is free to link to whatever it wants;
> we're not changing that. If it wants to link to 1:1
> libthr or whatever, then it had better be sure to use
> -lthr because -pthread won't do it regardless of whether
> it is a NOOP or not.
Ok
Hello,
With the help of Adriaan de Groot, Andy Fawcett, and Lauri Watts,
I've successfully built KDE on 5.1-CURRENT as of 2003/09/19.
The following patch can be applied:
http://www.fruitsalad.org/patches/kde314-fixpth.diff
using:
cd /usr/ports && patch < kde314-fixpth.diff
Please test thi
On Tue, Sep 23, 2003 at 07:18:21PM -0700, Kris Kennaway wrote:
> pwlib-1.5.0_2
I have sent patches for pwlib and gnomemeeting to the maintainer
shortly after the gnome2.4 import, and he said they would be commited
(with a slight modification) when the ports freeze was lifted.
--
Morten Rodal
__
Kris Kennaway wrote:
Here is a partial list of the ports that need to be taught to respect
PTHREAD_LIBS and PTHREAD_CFLAGS, from the latest 5.x package build (I
[skipped]
omniORB-4.0.2
PR/56862 is waiting for ports unfreezing.
--
Sem.
___
[EMAIL PROTEC
Daniel Eischen wrote:
Making -pthread a NOOP _would_ (*) break the application
in the link stage; it would be obvious when the application
failed to link with lots of unresolved pthread symbols.
Yeah it would break. It would break in a way where the first
thing I would suppose to be the case would
On Tue, Sep 23, 2003 at 09:54:06PM -0400, Michael W. Oliver wrote:
Content-Description: signed data
>Well, I didn't know somebody was patching it, so I started using the
>following in ripit.pl (not exactly as below) instead of 'dagrab':
>
>dd if=/dev/acd0t01 ibs=2352 obs=2048 | sox -t raw -r 44100
62 matches
Mail list logo
