Re: Where is my SLIP interface

[Lanny Baron]

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 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_sl compiled into the kernel as well as a module.
> >>>
> >>> In neither case does ifconfig show a sl0 device.
> >>
> >> IIRC it doesn't show now until it's configured.
> >
> > Perhaps 'The Complete FreeBSD' by Greg Lehey will help out.
> 
> Not any more.  I removed that chapter from the book.  The chapter's
> available (also covers UUCP) if anybody wants it; just ask.  But it
> seems that Willem has already had SLIP up and running.
> 
> Greg
> --
> See complete headers for address and phone numbers
-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
Lanny Baron
Proud to be 100% FreeBSD
http://www.FreeBSDsystems.COM
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Where is my SLIP interface

[Greg 'groggy' Lehey]

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
>>> 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_sl compiled into the kernel as well as a module.
>>>
>>> In neither case does ifconfig show a sl0 device.
>>
>> IIRC it doesn't show now until it's configured.
>
> Perhaps 'The Complete FreeBSD' by Greg Lehey will help out.

Not any more.  I removed that chapter from the book.  The chapter's
available (also covers UUCP) if anybody wants it; just ask.  But it
seems that Willem has already had SLIP up and running.

Greg
--
See complete headers for address and phone numbers


pgp0.pgp
Description: PGP signature

Re: Fixing -pthreads (Re: ports and -current)

[Daniel Eischen]

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 fileexists("libpthread") then LDFLAGS += -lpthread
> >* elseif fileexists("libthr") then LDFLAGS += -lthr
> >* elseif fileexists("libc_r") then LDFLAGS += -lc_r
> >* else error("Threading not supported.")
> 
> Hello Mike,
> 
> I too thought about making -pthread an exact alias for
> env("PTHREADS_LIBS") (and, if empty, pick -lpthread or the classic
> default -lc_r).  The main issue is that the FSF gcc has not accepted
> any code into the gcc driver which depends on environment variables.

What is FSF gcc policy with regard to having multiple
thread switches, ala Solaris?  An alternative would be
to retain -pthread = -lc_r and switch it over to -lpthread
once sparc64 and alpha ports are done, then add a -thread
switch for -lthr if folks want similar treatment for libthr.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Where is my SLIP interface

[Lanny Baron]

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 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_sl compiled into the kernel as well as a module.
> >
> > In neither case does ifconfig show a sl0 device.
> 
> IIRC it doesn't show now until it's configured.
> 
> Greg
> --
> See complete headers for address and phone numbers
-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
Lanny Baron
Proud to be 100% FreeBSD
http://www.FreeBSDsystems.COM
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Problem w/ ACPI in -CURRENT

[Jeremy Bingham]

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 go into debugging mode and get a stack trace. When I was
looking at where it was dying before with verbose logging turned on, it
seemed to be dying when it was trying to initialize the battery. I
looked at the ACPI stuff in the kernel, and I think I may have found
where it stops working. (It's where the kernel tries to initialize the
battery - somewhere in sys/dev/acpia/acpi_cmbat.c.)

What should I do? I can't even seem to get the kernel to core dump right
for some reason, so should I insert some code to spit out messages in
the kernel where I think it might be hanging, or am I totally going down
the wrong path here?

-j

--
/* You are not expected to understand this. */

Captain_Tenille
http://www.satanosphere.com/
[EMAIL PROTECTED]



pgp0.pgp
Description: PGP signature

Re: Fixing -pthreads (Re: ports and -current)

[Loren James Rittle]

>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 fileexists("libthr") then LDFLAGS += -lthr
>* elseif fileexists("libc_r") then LDFLAGS += -lc_r
>* else error("Threading not supported.")

Hello Mike,

I too thought about making -pthread an exact alias for
env("PTHREADS_LIBS") (and, if empty, pick -lpthread or the classic
default -lc_r).  The main issue is that the FSF gcc has not accepted
any code into the gcc driver which depends on environment variables.

Loren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Where is my SLIP interface

[Greg 'groggy' Lehey]

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_sl compiled into the kernel as well as a module.
>
> In neither case does ifconfig show a sl0 device.

IIRC it doesn't show now until it's configured.

Greg
--
See complete headers for address and phone numbers


pgp0.pgp
Description: PGP signature

Where is my SLIP interface

[Willem Jan Withagen]

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 loaded, and unloading is
refused (as is clear from the code)
Sep 25 02:32:32 router kernel: if_sl module unload - not possible for
this module

When it is compiled into the kernel, if_sl.ko does not want to register,
since it is already there.
Sep 25 01:56:43 router kernel: module_register: module if_sl already
exists!
Sep 25 01:56:43 router kernel: Module if_sl failed to register: 17

running ifconfig sl0 loads the module but still generates:
router# ifconfig sl0
ifconfig: interface sl0 does not exist

The other interfaces are correctly reported.

kernel config is attached, but what am I missing or how do I debug this??

Thanx,
--WjW


machine i386
cpu I586_CPU
cpu I686_CPU
ident   "GTW.5"

#To statically compile in device wiring instead of /boot/device.hints
#hints  "GENERIC.hints" #Default places to look for devices.

makeoptions DEBUG=-g#Build kernel with gdb(1) debug
symbols

options SCHED_4BSD  #4BSD scheduler
options INET#InterNETworking
options INET6   #IPv6 communications protocols
options FFS #Berkeley Fast Filesystem
options SOFTUPDATES #Enable FFS soft updates support
options NFSCLIENT   #Network Filesystem Client
options CD9660  #ISO 9660 Filesystem
options COMPAT_43   #Compatible with BSD 4.3 [KEEP
THIS!]
options COMPAT_FREEBSD4 #Compatible with FreeBSD4

#optionsIPFIREWALL
options IPDIVERT

device  isa
device  pci

# Floppy drives
device  fdc

# ATA and ATAPI devices
device  ata
device  atadisk # ATA disk drives
device  atapicd # ATAPI CDROM drives
options ATA_STATIC_ID   #Static device numbering

# atkbdc0 controls both the keyboard and the PS/2 mouse
device  atkbdc  # AT keyboard controller
device  atkbd   # AT keyboard

device  vga # VGA video card driver

# syscons is the default console driver, resembling an SCO console
device  sc
device  sio

# Floating point support - do not disable.
device  npx

# Add suspend/resume support for the i8254.
device  pmtimer

# PCI Ethernet NICs.
device  de  # DEC/Intel DC21x4x (``Tulip'')

# PCI Ethernet NICs that use the common MII bus controller code.
# NOTE: Be sure to keep the 'device miibus' line in order to use these NICs!
device  miibus  # MII bus support
device  dc  # DEC/Intel 21143 and various workalikes
device  fxp # Intel EtherExpress PRO/100B (82557, 82558)
device  rl  # RealTek 8129/8139

# ISA Ethernet NICs.  pccard nics included.
# 'device ed' requires 'device miibus'
device  ed  # NE[12]000, SMC Ultra, 3c503, DS8390 cards
device  ep  # Etherlink III based cards

# Pseudo devices - the number indicates how many units to allocate.
device  random  # Entropy device
device  loop# Network loopback
device  ether   # Ethernet support
#device sl  # Kernel SLIP
#device ppp # Kernel PPP
device  tun # Packet tunnel.
device  pty # Pseudo-ttys (telnet etc)
device  gif # IPv6 and IPv4 tunneling
device  faith   # IPv6-to-IPv4 relaying (translation)

# The `bpf' device enables the Berkeley Packet Filter.
# Be aware of the administrative consequences of enabling this!
device  bpf # Berkeley packet filter

makeoptions SC_DFLT_FONT=cp850
options DDB
options DDB_UNATTENDED
options TCP_DROP_SYNFIN
options IPR_VJ
options MAXCONS=16  # number of virtual consoles
options MSGBUF_SIZE=40960
options PPC_PROBE_CHIPSET # Enable chipset specific detection
options SC_DFLT_FONT# Compile font in
options INCLUDE_CONFIG_FILE # Include this file in kernel
options IPSEC   #IP security
options IPSEC_DEBUG #debug for IP security
options IPSEC_ESP   #IP security (crypto; define w/
IPSEC)
options SC_DFLT_FONT# compile font in
options SC_HISTORY_SIZE=2000# number of history buffer lines
options SC_KERNEL_CONS_ATTR="(FG_RED|BG_BLACK)"
options SC_KERNEL_CONS_REV_ATTR=

ThinkPad R40 hangs during ACPI power down

[Don Lewis]

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 thing I can do at this point is to hold the power button
down to force it to power off.  The next boot is clean.

I've seen the same behaviour with September 8th and September 21st
versions of 5.1-CURRENT.

Attempting to use 'acpiconf -s" to suspend produces similar hangs.


I tried compiling a version of the kernel with the ACPI_DEBUG option
listed in NOTES, but buildkernel dies here:

cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstric
t-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fforma
t-extensions -std=c99 -g -nostdinc -I-  -I. -I/usr/src/sys -I/usr/src/sys/contri
b/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath -I/u
sr/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -
finline-limit=15000 -fno-strict-aliasing  -mno-align-long-strings -mpreferred-st
ack-boundary=2 -ffreestanding -Werror  /usr/src/sys/dev/acpica/acpi_button.c
/usr/src/sys/dev/acpica/acpi_button.c: In function `acpi_button_fixed_handler':
/usr/src/sys/dev/acpica/acpi_button.c:246: error: `_Dbg' undeclared (first use i
n this function)
/usr/src/sys/dev/acpica/acpi_button.c:246: error: (Each undeclared identifier is
 reported only once
/usr/src/sys/dev/acpica/acpi_button.c:246: error: for each function it appears i
n.)
*** Error code 1

Stop in /usr/obj/usr/src/sys/ACPI_DEBUG.
*** Error code 1

Stop in /usr/src.

NOTES says that to use this option, the Intel code must have the
USE_DEBUGGER flag set.  I didn't see references to this in the code, but
there are a bunch of #ifdefs that refer to ACPI_DEBUGGER.  I tried
adding this to my kernel configuration, but config barfs on it.

The APCI asl file is at 
and the dmesg.boot is at
.  I downloaded the
ACPI spec and attempted to use it to decipher my asl file, but I decided
it was hopeless since I didn't even know far the ACPI code was getting.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ata-lowlevel.c ate my slave disc

[Fred Souza]

> 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 same later on.

  I'm not sure if my problem is also related to these changes in
  ata-lowlevel.c, but my ATAPI CDROM does not work with a kernel built
  today (sep 24th). The revision of that file here is 1.16. I even tried
  reverting to 1.1[012], but when I do that it doesn't even compile
  anymore (gcc spews complaints about opt_ata.h, if I'm not mistaken).

  I have a kernel working right, built off sources of sep 11th, and
  that's why I stuck with versions 1.1[012], which are the ones around
  that date. However, I understand I should also revert opt_ata.h, I
  just don't have the time for it right now. If someone has ideas on
  what could possibly fix/clarify the problem more easily, I'd love to
  try it. But recompiling kernel after kernel here is a real pain,
  because it takes over 2 hours in the process.


  Fred


-- 
"Everything takes longer than you expect."


pgp0.pgp
Description: PGP signature

Re: acd0 vs cd0 (ATAPICAM)

[Bryan Liesner]

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 reviewed the change.
>

No, thank you!  dd'ing a full data CD before this fix had top showing
at least 50% of the CPU time in interrupt - it's now down to the usual
5% or less.

-Bryan

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[David Xu]

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 their hands and say "just make
> > >> > -pthread work and do whatever it needs to".
> > >>
> > >> I am one of those folks as well. As an end-user, I am not interested
> > >> in hacking around the source of 3rd-party applications that use
> > >> -pthread when compiling them from source myself. Not in the slightest.
> > >> This is BAD BAD BAD for usability.
> > >>
> > >> Sincerely,
> > >> Dan Naumov
> > >
> > > I also believe that a question has to be asked, what do the -core and
> > > -arch people think of all this ? I think that they should have the
> > > final say in the matter.
> >
> > 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?  The fact that functions live in libraries and that
> > to get access to said functions you link with said libraries has been
> > the practice on Un*x for longer than I've been alive.  Please, people,
> > let the -pthread hack die and just use -l.
> > I think any FreeBSD-specific -pthread bits should just be removed
> > and have the compiler complain about a bogus option.  If gcc chooses
> > to have a machine independent -pthread (or -thread) to turn on TLS or
> > some such, that's great and all, but that would be gcc code, not
> > FreeBSD-specific code.
>
> Where were you a few days ago!

I definitly agree with Dan, -pthread is too ugly, it really really is
nothing to do with compiler and should be removed. If someone thinks -pthread
should be kept, then think about Microsoft, you are doing Microsoft way and
cause lots of trouble when I am programmming on Windows, Microsoft has two 
version of c library, threaded library and non-threaded library, it need a 
compiler flag -MT to link a thread library, then lots of library conflict
with this flag at linking time because some were compiled with -MT some were
not, this is rather annoying. This is a bit OT, but I hope we can avoid such
decision bug. Many software use autoconf, autconf prefers -lpthread than 
-pthread, it even prefers -lc_r then -pthread (if I remembered it right ).
if system has a libpthread there, it will generate Makefile to use -lpthread
not -pthread, obviously -pthread is not suggested to use.
One word, just let -pthread die.

David Xu

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ata-lowlevel.c ate my slave disc

[Peter Wemm]

> 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 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 same later on.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

FYI: gcc 3.4 has -pthread accross the board

[M. Warner Losh]

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 to mean "use
whatever the right threading package/library/etc for your system is."
It would be unwise of us to deviate substantially from that.  The
changelog also suggests that the right #defines for your system will
be added when -pthread is specified on the command line for compiles
(as opposed to linking).

Peace,

Warner

P.S. Samples from http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog:

Wed Sep 17 14:04:38 2003 UTC (7 days, 8 hours ago) by drow
* config/rs6000/sysv4.h (LIB_LINUX_SPEC): Make -pthread apply
to shared libraries.

Tue Aug 26 06:54:11 2003 UTC (4 weeks, 1 day ago) by zack
gcc:
* config.gcc (hppa*-*-hpux11*, ia64*-*-hpux*): Remove
commented-out logic to use DCE threads (if present), add
support for POSIX threads.
* config/ia64/hpux.h: Define CPP_SPEC to set appropriate
#defines for -pthread.  Add -lpthread to LIB_SPEC when
-pthread.  In both cases take -mt as a synonym for -pthread
for acc compatibility.
Define GTHREAD_USE_WEAK to 0.
* config/pa/pa-hpux11.h: Likewise for CPP_SPEC and LIB_SPEC.
Remove old logic for DCE threads from LIB_SPEC.
* config/pa/pa64-hpux.h: Define GTHREAD_USE_WEAK to 0.
libstdc++-v3:
* config/os/hpux/os_defines.h: Unconditionally define
_GLIBCXX_GTHREAD_USE_WEAK to 0.

Sun Aug 3 00:48:46 2003 UTC (7 weeks, 3 days ago) by kkojima
* config/sh/linux.h (SUBTARGET_LINK_SPEC): Don't set rpath.
(LIB_SPEC): Set -lpthread always when -pthread set.  Set -lieee
when -mieee-fp set and -shared not set.
(SH_FALLBACK_FRAME_FLOAT_STATE): Don't define for SH5.

Thu Jul 31 12:00:54 2003 UTC (7 weeks, 6 days ago) by ro
* config.gcc (alpha*-dec-osf[45]*): Enable POSIX thread support by
default.

* gthr-posix.c: New file.
* gthr-posix.h: Define _REENTRANT if missing.
Make _LIBOBJC #pragma weak visible with _LIBOBJC_WEAK.

* config/alpha/t-osf4 (SHLIB_LINK): Hide dummy functions provided
by gthr-posix.o.
* config/alpha/t-osf-pthread: New file.

* fixinc/inclhack.def (alpha_pthread): New fix.
* fixinc/fixincl.x: Regenerate.
* fixinc/tests/base/pthread.h [ALPHA_PTHREAD_CHECK]: New testcase.

* doc/install.texi (alpha*-dec-osf*): Remove --enable-threads
warning.
Fixes PR bootstrap/9330.

Fri Feb 28 19:05:20 2003 UTC (6 months, 3 weeks ago) by thorpej
* config/netbsd.h: Update copyright years.
(NETBSD_CPP_SPEC): Define _REENTRANT and _PTHREADS if
-pthread is specified on the command line.

Tue Dec 10 10:55:22 2002 UTC (9 months, 2 weeks ago) by jakub
* config/linux.h (LIB_SPEC): If -pthread, add -lpthread even if
-shared.
* config/alpha/linux-elf.h (LIB_SPEC): Likewise.
* config/alpha/linux.h (LIB_SPEC): Likewise.
* config/arm/linux-elf.h (LIB_SPEC): Likewise.
* config/pa/pa-linux.h (LIB_SPEC): Likewise.
* config/sparc/linux.h (LIB_SPEC): Likewise.
* config/sparc/linux64.h (LIB_SPEC): Likewise.

Mon Oct 28 17:20:31 2002 UTC (10 months, 3 weeks ago) by thorpej
* config.gcc (*-*-netbsd*): Add NETBSD_ENABLE_PTHREADS to
tm_defines if pthreads are enabled.
* config/netbsd.h (LIB_SPEC): Only support the -pthread option
if NETBSD_ENABLE_PTHREADS is defined.

Sun Sep 15 18:14:15 2002 UTC (12 months, 1 week ago) by thorpej
* config/netbsd.h (LIB_SPEC): Include the appropriate pthread
library if -pthread is specified.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[Peter Wemm]

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 platforms.
On some systems it also implies -D_REENTRANT and other flags as well.

-pthread cannot go away.  We'd just be hurting ourselves for no good reason,
especially when the rest of the world is syncing up with us.

Samples from http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog:


* config/linux.h (LIB_SPEC): If -pthread, add -lpthread even if
-shared.
* config/alpha/linux-elf.h (LIB_SPEC): Likewise.

* config/ia64/hpux.h: Define CPP_SPEC to set appropriate
#defines for -pthread.  Add -lpthread to LIB_SPEC when
-pthread.  In both cases take -mt as a synonym for -pthread
for acc compatibility.
... 
* config/netbsd.h: Update copyright years.
(NETBSD_CPP_SPEC): Define _REENTRANT and _PTHREADS if
-pthread is specified on the command line.
...


Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

ata-lowlevel.c ate my slave disc

[Pav Lucistnik]

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 (#ifdef 0 a section of
probing code), the disc is back and works absolutely fine.

Full verbose boots are available at http://hood.oook.cz/techno/
one with old kernel (14th Sep), one with new kernel (25th Sep), and one
with new kernel with reverted 1.10 revision.

I hope this will help you fixing it.

-- 
Pav Lucistnik <[EMAIL PROTECTED]>
What do we know about love? Love is like a pear. Pear is sweet and have
a specific shape. Try to exactly define the shape of a pear.
  -- Marigold: 50 Years Of Poetry


signature.asc
Description: Toto je =?iso-8859-2?Q?digit=E1ln=EC?=	=?ISO-8859-1?Q?_podepsan=E1?= =?iso-8859-2?Q?_=E8=E1st?=	=?ISO-8859-1?Q?_zpr=E1vy?=

Re: Can't hear audio CDs (Asus P4P800 / Soundmax)

[Pav Lucistnik]

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/xmms/Input/libcdread.so: Undefined symbol
> "playlist_generate_shuffle_list"
> 
> and the plug-in does not appear in xmms configuration.
> 
> Any idea?

It's broken with xmms-1.2.8. The patch that fixes this was committed 10
hours ago by edwin. Update your ports collection and give it a new try.

But, rather than work around your problem, try to solve it. Are you sure
your CD-ROM drive and sound chip are connected by audio cable?

-- 
Pav Lucistnik <[EMAIL PROTECTED]>
What do we know about love? Love is like a pear. Pear is sweet and have
a specific shape. Try to exactly define the shape of a pear.
  -- Marigold: 50 Years Of Poetry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[Daniel Eischen]

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 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 compliant (they would break when linked).
> > > >I know it has no bearing on 3rd party stuff.
> > > 
> > > 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 you want to make -pthread mean libkse,
> > > create an /etc/pthread.libs that looks like:
> > 
> > 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 fileexists("libthr") then LDFLAGS += -lthr
> > * elseif fileexists("libc_r") then LDFLAGS += -lc_r
> > * else error("Threading not supported.")
> 
> Out of all the suggestions (aside from making -pthread a NOOP),
> this is my favorite one.  I would also make -pthread a NOOP
> when building shared && dynamic.

I didn't think of it, but something like this also lets
me set PTHREAD_LIBS to "" which would effectively become
a NOOP.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Strange system responsiveness issues with 5.1-CURRENT

[Eric Hodel]

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.
> > 
> > Same here with audio lagging. But I would say it lags only a second or
> > a half, but it is clearly noticeable, when seeking in mp3s or clicking
> > stop.
> > 
> > Perhaps some buffering issue?
> 
> I'm experiencing the same on my 5.1-RELEASE with all debugging turned
> off and the 'ln -s aj' thingy to malloc.
> Pausing XMMS will continue to play music for about 1-2 seconds. Running
> bzip/tar/gzip/md5 (extracting big ports) will make XMMS stutter (XMMS is
> playing via NFS, so it's not 'slow' hardware, it's somewhere else).
> 
> Funny thing is, I recently had to 'portupgrade -raf', and I swear XMMS
> was very responsive afterwards. But right now (without recompiling
> anything else) it's back to normal.

I have had similar problems playing music for several months, if I moved
the mouse (ps2) on the console, static would be added to the audio,
some heavy disk activity could also trigger it, but that was very rare.

At any rate, I decided my system had too much cruft on it, and did a rm -rf
/usr/local, then re-built everything from scratch (the filesystem dated
from late in 3-CURRENT).  After the complete rebuild, the problem
disappeared.  It seems that I had a stale library or header somewhere
that contributed to this.

-- 
Eric Hodel - [EMAIL PROTECTED] - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E  7C11 332A 551C 796C 9F04



pgp0.pgp
Description: PGP signature

Re: Fixing -pthreads (Re: ports and -current)

[Daniel Eischen]

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 anything outside of that.
> > >
> > >That just meant it makes it easier to maintain ports so that
> > >they are PTHREAD_LIBS compliant (they would break when linked).
> > >I know it has no bearing on 3rd party stuff.
> > 
> > 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 you want to make -pthread mean libkse,
> > create an /etc/pthread.libs that looks like:
> 
> 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 fileexists("libthr") then LDFLAGS += -lthr
> * elseif fileexists("libc_r") then LDFLAGS += -lc_r
> * else error("Threading not supported.")

Out of all the suggestions (aside from making -pthread a NOOP),
this is my favorite one.  I would also make -pthread a NOOP
when building shared && dynamic.

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.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: What's happened to CDIOCREADAUDIO & friends?

[Julian St.]

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. Think" said Pooh, and got a headache.


pgp0.pgp
Description: PGP signature

Re: Fixing -pthreads (Re: ports and -current)

[Garrett Wollman]

< 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 libpthread.so by a symlink, provided that all three
thread libraries cooperate by announcing an SONAME of libpthread.so.N.

-GAWollman

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[Daniel Eischen]

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 libpthread, and both are linked to
> > libGL which is linked to libc_r, what happens?
> 
> This is why its important to use the same name for the threading library
> and never link directly with libkse, libthr, libc_r etc.  Make libpthread
> a symlink, please.

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.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Can't hear audio CDs (Asus P4P800 / Soundmax)

[Vitalis]

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 Asus P4P800 motherboard with an integrated
> > Soundmax soundcard. I can play audio files through it thanks to the
> > snd_ich and snd_pcm drivers. But when I play audio CDs, with cdcontrol
> > or X11 apps, no sound is heard, though the mixer settings are correct.
> > 
> > The audio tracks are recognized correctly by all players, they actually
> > seem to play them, but without any sound (which could be useful 8)
> > 
> > TIA
> > 
> > (FreeBSD 5.1-CURRENT)
> > 
> > 
> > ___
> > [EMAIL PROTECTED] mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> 

Thanks for your answer. I've just installed the port, but when I launch
xmms, I get this message:
/usr/X11R6/lib/xmms/Input/libcdread.so: Undefined symbol
"playlist_generate_shuffle_list"

and the plug-in does not appear in xmms configuration.

Any idea?



bash-2.05b# xmms -version
xmms 1.2.8



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: TEST PLEASE: http://phk.freebsd.dk/patch/scsi_cd.patch

[Poul-Henning Kamp]

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_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.
>>=20
>> It also alows GBDE encryption of CD images.
>
>Is this supposed to work through ATAPICAM?

Should be I pressume.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[Matthew N. Dodd]

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 linked to libc_r, what happens?

This is why its important to use the same name for the threading library
and never link directly with libkse, libthr, libc_r etc.  Make libpthread
a symlink, please.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: acd0 vs cd0 (ATAPICAM)

[Thomas Quinot]

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]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[Andrea Campi]

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 you want to make -pthread mean libkse,
> create an /etc/pthread.libs that looks like:

Kudos to you! That's the general direction of my thoughts, but I had no
idea where to look in gcc's guts...

And I agree, maybe it's not the best option, but we should at least
consider it.

Bye,
Andrea

-- 
Failure is not an option. It comes bundled with your Microsoft product.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Initial list of ports that fail due to -pthread

[Michael Nottebrock]

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 test with. I don't mind the port
> > marked BROKEN, since it's unsupported abandonware and due for deorbit
> > anyway.
>
> I object. The Icecast team have barely even documented how to configure
> Icecast 2 nor have they provided a means of cleanly migrating to the new
> XML configuration format.
>
> SPC is one organization who make a lot of use of this particular port, I
> am sure there are others.
>
> If you must kill it off at least give us time to bury it properly.

Don't worry, a port deorbit takes a very long time and right now I'm merely 
thinking out loud, there's no countdown started yet. But keep in mind that 
this doesn't change the facts: Icecast 1 _is_ unsupported abandonware, and it 
is by any means not too early to start investigating the migration to other 
software.

That said, if you have a fix going for the -pthread issue on -CURRENT, I'd 
appreciate (and commit).

-- 
   ,_,   | Michael Nottebrock   | [EMAIL PROTECTED]
 (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
   \u/   | K Desktop Environment on FreeBSD | http://freebsd.kde.org


pgp0.pgp
Description: signature

Re: Fixing -pthreads (Re: ports and -current)

[Daniel Eischen]

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
> > > > in -current for well over 2 years.  Indeed, if you build KDE
> > > > and X with libpthread installed, you will see binaries that
> > > > are linked to both libc_r and libpthread.
> > > 
> > > I can't see how this behaviour would not be considered a bug, if it
> > > is indeed true.  Are you saying that there are packages out there
> > > that will detect both -lpthread and -pthread and attempt to use
> > > both on the compilers and linker lines?
> > 
> > Yes, it's not just that.  They can also find libc_r and include that
> > (-lc_r) with -pthread.  I installed libkse as libpthread and made the
> > appropriate links and built X and KDE and there were a lot of
> > binaries that were linked to both libc_r and libpthread.
> 
> 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_PRELOAD wins
> above all.  If one threads library exports a symbol not in the others,
> I'd call that an API bug in the first library.

Yes, it does matter.  There are no problems with exported pthread
symbols that I know of.  I believe it is private symbols (__foo)
that are causing problems and C++ style autoinit that is needed
to initialize the libraries.

We don't want applications to link to multiple thread
libraries anyways.  I don't know how to prevent it...

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Initial list of ports that fail due to -pthread

[Bruce M Simpson]

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 abandonware and due for deorbit anyway.

I object. The Icecast team have barely even documented how to configure
Icecast 2 nor have they provided a means of cleanly migrating to the new
XML configuration format.

SPC is one organization who make a lot of use of this particular port, I
am sure there are others.

If you must kill it off at least give us time to bury it properly.

BMS
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: Fixing -pthreads (Re: ports and -current)

[Andre Guibert de Bruet]

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, that's precisely how it works.  `c99
> foo.c -l m' means `link in the math functions, wherever they may
> happen to live'.  Likewise `-l rt' for realtime -- and (relevant to
> this discussion) `-l pthread' for threads.  There is no requirement
> that any of these libraries exist as such.

That may be true, but these libraries don't have gcc options like
'-pthread' does to have them linked against. Why should a threaded library
be any different than libz, libpng or lib?

> Andre Guibert de Bruet | Enterprise Software Consultant >
> Silicon Landmark, LLC. | http://siliconlandmark.com/>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[Michael Edenfield]

* 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
> > >> mean anything outside of that.
> > >
> > >That just meant it makes it easier to maintain ports so that
> > >they are PTHREAD_LIBS compliant (they would break when linked).
> > >I know it has no bearing on 3rd party stuff.
> > 
> > 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 you want to make -pthread mean libkse,
> > create an /etc/pthread.libs that looks like:
> 
> 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:
  
I should point out that my main concern here is not technical but
policy.  Right now -pthread is implemented entirely as a gcc spec as
part of LIB_SPEC.  I didn't have time to get very far so I'm not sure
how much special-case argument handling is done in gcc currently.  Would
this kind of approach, to moving the "-pthread" handling out of a
specfile and into args handling code, fly with the FSF people?

--Mike



pgp0.pgp
Description: PGP signature

Re: Fixing -pthreads (Re: ports and -current)

[Michael Edenfield]

* 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 easier to maintain ports so that
> >they are PTHREAD_LIBS compliant (they would break when linked).
> >I know it has no bearing on 3rd party stuff.
> 
> 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 you want to make -pthread mean libkse,
> create an /etc/pthread.libs that looks like:

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 fileexists("libthr") then LDFLAGS += -lthr
* elseif fileexists("libc_r") then LDFLAGS += -lc_r
* else error("Threading not supported.")

or whatever.  At that point, simply having PTHREADS_LIBS moved into the
environment in bsd.port.mk and leaving all the ports using -pthread
alone would automatically have them support PTHREADS_LIBS.  Even better,
the existing bsd.port.mk construct could become just another pre-defined
environment variable, similar to LD_PRELOAD for the runtime linker, but
which affects the compiler/link editor instead.

--Mike



pgp0.pgp
Description: PGP signature

Re: Fixing -pthreads (Re: ports and -current)

[Robert Watson]

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_PRELOAD wins above all. 
> If one threads library exports a symbol not in the others, I'd call that
> an API bug in the first library. 
> 
> This should be no different from explicitly linking in dmalloc to
> override the malloc functions in libc, for example. 

One potential downside to the LD_PRELOAD approach is that it will only
work for applications that aren't setuid/setgid.  While today most of our
privileged and credential-munging applications aren't threaded, I'd like
to avoid precluding that in the future as much as possible.  What
mechanism should be used when LD_PRELOAD is being ignored due to
issetugid() returning true?

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[Dan Nelson]

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 you build KDE
> > > and X with libpthread installed, you will see binaries that
> > > are linked to both libc_r and libpthread.
> > 
> > I can't see how this behaviour would not be considered a bug, if it
> > is indeed true.  Are you saying that there are packages out there
> > that will detect both -lpthread and -pthread and attempt to use
> > both on the compilers and linker lines?
> 
> Yes, it's not just that.  They can also find libc_r and include that
> (-lc_r) with -pthread.  I installed libkse as libpthread and made the
> appropriate links and built X and KDE and there were a lot of
> binaries that were linked to both libc_r and libpthread.

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_PRELOAD wins
above all.  If one threads library exports a symbol not in the others,
I'd call that an API bug in the first library.

This should be no different from explicitly linking in dmalloc to
override the malloc functions in libc, for example.

-- 
Dan Nelson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: Fixing -pthreads (Re: ports and -current)

[Garrett Wollman]

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 `link in the math functions, wherever they may
happen to live'.  Likewise `-l rt' for realtime -- and (relevant to
this discussion) `-l pthread' for threads.  There is no requirement
that any of these libraries exist as such.

-GAWollman

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: Fixing -pthreads (Re: ports and -current)

[John Baldwin]

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 "just make
>> >> > -pthread work and do whatever it needs to".
>> >> 
>> >> I am one of those folks as well. As an end-user, I am not interested in
>> >> hacking around the source of 3rd-party applications that use -pthread
>> >> when compiling them from source myself. Not in the slightest. This is
>> >> BAD BAD BAD for usability.
>> >> 
>> >> Sincerely,
>> >> Dan Naumov
>> > 
>> > I also believe that a question has to be asked, what do the -core and
>> > -arch people think of all this ? I think that they should have the final
>> > say in the matter.
>> 
>> 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?  The fact that functions live in libraries and that
>> to get access to said functions you link with said libraries has been
>> the practice on Un*x for longer than I've been alive.  Please, people,
>> let the -pthread hack die and just use -l.
>> I think any FreeBSD-specific -pthread bits should just be removed
>> and have the compiler complain about a bogus option.  If gcc chooses
>> to have a machine independent -pthread (or -thread) to turn on TLS or
>> some such, that's great and all, but that would be gcc code, not
>> FreeBSD-specific code.
> 
> Where were you a few days ago!

DNS problems == no outbound e-mail. :-P   If gcc does want to go with
a gcc-mandated -pthread option, then we should follow suit with that
(and it seems that gcc might), but I don't think we need a FreeBSD-only
flag if gcc doesn't mandate a -pthread option.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: TEST PLEASE: http://phk.freebsd.dk/patch/scsi_cd.patch

[Florian C. Smeets]

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 also alows GBDE encryption of CD images.

Hi!

I gave the patch a try and everything seems fine. I can read and write 
CDRs on my SCSI-CDR.

Regards,
flo
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[Daniel Eischen]

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 maintain ports so that
> >they are PTHREAD_LIBS compliant (they would break when linked).
> >I know it has no bearing on 3rd party stuff.
> 
> 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.

Hey, neat.  I wouldn't have known how to do such a thing from
gcc.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Initial list of ports that fail due to -pthread

[Michael Nottebrock]

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]
 (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
   \u/   | K Desktop Environment on FreeBSD | http://freebsd.kde.org


pgp0.pgp
Description: signature

Re: Fixing -pthreads (Re: ports and -current)

[Ian Dowse]

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 compliant (they would break when linked).
>I know it has no bearing on 3rd party stuff.

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 you want to make -pthread mean libkse,
create an /etc/pthread.libs that looks like:

-lc_r:  -lkse
-lc_r_p:-lkse_p

I haven't been following the discussion in any detail - this is
just another possibility that is worth mentioning as it could retain
compatibility for users that want -pthread to mean use the default
thread library.

Ian

Index: gcc.c
===
RCS file: /dump/FreeBSD-CVS/src/contrib/gcc/gcc.c,v
retrieving revision 1.36
diff -u -r1.36 gcc.c
--- gcc.c   11 Jul 2003 04:45:39 -  1.36
+++ gcc.c   24 Sep 2003 15:37:14 -
@@ -331,6 +331,7 @@
 
 static const char *if_exists_spec_function PARAMS ((int, const char **));
 static const char *if_exists_else_spec_function PARAMS ((int, const char **));
+static const char *thread_lib_override_spec_function PARAMS ((int, const char **));
 
 /* The Specs Language
 
@@ -1440,6 +1441,7 @@
 {
   { "if-exists",   if_exists_spec_function },
   { "if-exists-else",  if_exists_else_spec_function },
+  { "thread-lib-override", thread_lib_override_spec_function },
   { 0, 0 }
 };
 
@@ -7335,4 +7337,46 @@
 return argv[0];
 
   return argv[1];
+}
+
+/* thread-lib-override built-in spec function.
+
+   Override a thread library according to /etc/pthread.libs  */
+
+static const char *
+thread_lib_override_spec_function (argc, argv)
+ int argc;
+ const char **argv;
+{
+  static char buf[256];
+  FILE *fp;
+  int n;
+  
+  /* Must have exactly one argument.  */
+  if (argc != 1)
+return NULL;
+
+  fp = fopen ("/etc/pthread.libs", "r");
+  if (fp == NULL)
+return argv[0];
+
+  while (fgets (buf, sizeof(buf), fp) != NULL)
+{
+  n = strlen (buf);
+  while (n > 0 && buf[n - 1] == '\n')
+   buf[--n] = '\0';
+  if (buf[0] == '#' || buf[0] == '\0')
+   continue;
+  n = strlen (argv[0]);
+  if (strncmp (buf, argv[0], n) != 0 || n >= sizeof (buf) || buf[n] != ':')
+   continue;
+  n++;
+  while (buf[n] != '\0' && isspace ((unsigned char)buf[n]))
+   n++;
+  fclose (fp);
+
+  return &buf[n];
+}
+  fclose (fp);
+  return argv[0];
 }
Index: config/freebsd-spec.h
===
RCS file: /dump/FreeBSD-CVS/src/contrib/gcc/config/freebsd-spec.h,v
retrieving revision 1.14
diff -u -r1.14 freebsd-spec.h
--- config/freebsd-spec.h   21 Sep 2003 07:59:16 -  1.14
+++ config/freebsd-spec.h   24 Sep 2003 15:38:11 -
@@ -160,8 +160,8 @@
 #if __FreeBSD_version >= 500016
 #define FBSD_LIB_SPEC "\
   %{!shared:   \
-%{!pg: %{pthread:-lc_r} -lc}   \
-%{pg:  %{pthread:-lc_r_p} -lc_p}   \
+%{!pg: %{pthread:%:thread-lib-override(-lc_r)} -lc}\
+%{pg:  %{pthread:%:thread-lib-override(-lc_r_p)} -lc_p}\
   }"
 #else
 #define FBSD_LIB_SPEC "\
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[Jacques A. Vidrine]

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 couldn't (or at least didn't) decide
between `threaded library' and `threading library'.  I wasn't trying to
make some subtle distinction here :-)   Probably I should have said
`thread library' throughout.

Cheers,
-- 
Jacques Vidrine   . NTT/Verio SME  . FreeBSD UNIX   . Heimdal
[EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[Jacques A. Vidrine]

[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
> > > are not dependent on a particular threads library, but will use
> > > whatever threads library the application uses (i.e., you want mplayer
> > > to use libpthread and ogle to use libthr).
> > 
> > I'm a big advocate of using libmap to deal with this.
> 
> 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 linked to libc_r, what happens?
> 
> At the least, -pthread should be a NOOP when building
> shared and dynamic.

While libmap is a very neat hack and very useful, it is indeed
a hack and I do not think it should be the primary method of
determining what libraries to load.  The mere existance of a
libmap.conf file means additional file opening and parsing every time
a dynamically linked executable is loaded; as well as one or more
string searches/substitutions for every dynamic object name that rtld
encounters (not just thread libraries).

I believe that we should be able to make decisions at link time and at
run time.

At link time, either (a) I want *this* threaded library damnit, or (b)
choose a threaded library at run time, with (b) being the default.
Choosing (a) probably allows you to shoot your foot by mixing
threading libraries, but it may also allow you to use `extensions'
that one threading library might provide but not another.

At run time (if (b) was chosen at link time): use *this* threaded
library.  By what mechanism?  I imagined that there could be a library
(say libpthread :-P) that made the decision and loaded the *real*
threading library and forwarded or fixed-up thread-related functions.
A degenerate-but-simple implementation might be a symlink.

This seems to be more-or-less what GCC developer Loren James Rittle
<[EMAIL PROTECTED]> had in mind when he posted the
following suggestion to freebsd-threads some weeks back:

  Thank you for considering these words.  BTW, wouldn't it be cooler
  if (example only):
  
  -pthread (whatever the system default)
  -pthread=1 (1 process, aka -lc_r)
  -pthread=1:1 (1 process per thread, aka -lthr)
  -pthread=M:N (M threads in N processes, aka -lkse)
  -pthread=late/weak (perhaps not good ELF form, link against a stub to
  which all POSIX thread libraries on FreeBSD must conform, do not
  record the dependency ala FreeBSD4 default for -lc; or that does it in
  a weak manner en mass such that binding is deferred to the final
  selection made at a final link time)

Cheers,
-- 
Jacques Vidrine   . NTT/Verio SME  . FreeBSD UNIX   . Heimdal
[EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: Fixing -pthreads (Re: ports and -current)

[Daniel Eischen]

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 it needs to".
> >> 
> >> I am one of those folks as well. As an end-user, I am not interested in
> >> hacking around the source of 3rd-party applications that use -pthread
> >> when compiling them from source myself. Not in the slightest. This is
> >> BAD BAD BAD for usability.
> >> 
> >> Sincerely,
> >> Dan Naumov
> > 
> > I also believe that a question has to be asked, what do the -core and
> > -arch people think of all this ? I think that they should have the final
> > say in the matter.
> 
> 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?  The fact that functions live in libraries and that
> to get access to said functions you link with said libraries has been
> the practice on Un*x for longer than I've been alive.  Please, people,
> let the -pthread hack die and just use -l.
> I think any FreeBSD-specific -pthread bits should just be removed
> and have the compiler complain about a bogus option.  If gcc chooses
> to have a machine independent -pthread (or -thread) to turn on TLS or
> some such, that's great and all, but that would be gcc code, not
> FreeBSD-specific code.

Where were you a few days ago!

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[Daniel Eischen]

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 -pthread automatically link to libpthread gives preference to
> > it over libthr (or libthread (KSE in 1:1 mode) or libc_r).
> > 
> > Pros:
> >   o Allows us to define macros common to all the threads libraries.
> >   o Allows shared libraries (Qt, GTK, OpenGL, etc) to be built that
> > are not dependent on a particular threads library, but will use
> > whatever threads library the application uses (i.e., you want mplayer
> > to use libpthread and ogle to use libthr).
> 
> I'm a big advocate of using libmap to deal with this.

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 linked to libc_r, what happens?

At the least, -pthread should be a NOOP when building
shared and dynamic.

> >   o If we support LD_PRELOAD properly, will allow us to select the
> > threads library without having to rebuild/relink the application.
> 
> I'm a big advocate of using libmap to deal with this.

libmap is in /etc and not writable by normal users.
LD_PRELOAD can be set in a script or command line.
Our FSF GCC maintainer has been advocating it and
it solves the problem without the need for libmap.

> 
> >   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 you build KDE and X with libpthread installed,
> > you will see binaries that are linked to both libc_r and libpthread.
> 
> I can't see how this behaviour would not be considered a bug, if it is
> indeed true.  Are you saying that there are packages out there that will
> detect both -lpthread and -pthread and attempt to use both on the
> compilers and linker lines?

Yes, it's not just that.  They can also find libc_r and include
that (-lc_r) with -pthread.  I installed libkse as libpthread and
made the appropriate links and built X and KDE and there were
a lot of binaries that were linked to both libc_r and libpthread.
Perhaps this is because some shared libraries were linked to
one or the other while the applications got linked to the other
one -- I don't know.  Making -pthread a NOOP when building
shared libraries may help the situation.

> >   o Makes it easier to spot ports that are not PTHREAD_LIBS compliant.
> 
> 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 compliant (they would break when linked).
I know it has no bearing on 3rd party stuff.

> I suspect that the majority of users won't give a hoot about the
> mechanics of all of this as long as it Just Works.  The more 
> sophisticated users that want to mix/match threading libraries can be
> expected to exert a little more effort and learn the tools like libmap,
> etc.
> 
> > 
> > Cons:
> >   o Third party applications that use -pthread exclusively (without
> > linking to a threads library) will have to add a link option.
> 
> This is where I have the biggest problem.  I firmly believe that it is
> incorrect for you to downplay this scenario, and it appears that others
> agree too.  This is the case that will give us the black eye with users
> and developers that want things to Just Work.

Well, we can agree to disagree :-)  I think folks are getting
upset that -pthread is an error and seeing all the problems
in ports and thinking the same thing is going to happen in
3rd party applications.  Things aren't nearly as broke when
it is a NOOP _and_ we have libpthread installed.  Any configure
script I've seen looks for -lpthread and will use it.

> > I understand that folks want to wave their hands and say "just make
> > -pthread work and do whatever it needs to".  I'm like that myself.
> > I just don't think it's a good idea.
> > 
> 
> I'm unclear why it is impossible to do this.  The whole point of 
> -pthread is to make it Just Work.  We have complete control over how
> we make that happen.  Why is it impossible to make -pthread honor
> PTHREAD_LIBS?

PTHREAD_LIBS is an bsd.port.mk thing.  -pthread is a compiler
switch (contrib/gcc/config/freebsd-spec.h).  I certainly don't
know how you would do this.

>  Why is it impossible to fix ports that try to
> mix pthread schemas?

It's not impossible, it's just not as easy to spot them because
they don't break when building.  You have to wade through complaints
saying "X doesn't work correctly, what happened?" and hopefully
get an 'ldd X' out of them so you can spot the problem.  Then
you have to figure out if it

Re: Fixing -pthreads (Re: ports and -current)

[John Baldwin]

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 to fix.  It's not like we're making
>> someone change their code to accomodate library or
>> kernel interface changes.
>> 
> 
> This is exactly the case the is going to cause the problems, though.
> For you, compiling a 3rd party app and dealing with failures in the
> linker is easy to deal with.  For someone else, it might not be.  If
> they go to compile an app and it compiles and runs fine on linux but
> fails on FreeBSD with linker errors, it will likely leave a negative
> impression in their mind.
> 
> I'm comparing my arguments to linux because a lot more apps are written
> with linux in mind than with solaris in mind these days.  People who are
> writing for linux or switching from linux might not know that
> '-lpthread' is a requirement, but they are more likely to know that
> '-pthread' will take care of all of that magic for them.  This argument
> really comes down to ease of use and user experience.  Steering away
> from de-facto standards steers us away from a positive user and
> developer experience.
> 
> I'm perfectly happy to support the libkse->libpthread switch, and I'm
> perfectly happy to support making libpthread be the default threading
> library.  But, I strongly believe that we need to also treat -pthread
> sanely.

Erm, I thought (if I remember correctly), that all the autoconf scripts,
etc., that I've seen for Linnex use -lpthread, not -pthread.  So we are
actually becoming more like the de facto standard by dropping -pthread,
not less.  -pthread is a hack, please let it die.  Either that or lets
have gcc -math (for libm), gcc -standalone (libstand?) gcc -X11
(for X libraries), gcc -kde, gcc -gnome, etc.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[freebsd-current]

>
> 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 with -lpthread --
> i.e.,
> a dynamic library dependency on libpthread.  This will mean that
> administrators don't have to list each possible threading library in
> /etc/libmap.conf in order to be sure they caught all of them.
>
> (3) Use libmap to perform the necessary substitution on a
> per-application
> or per-system basis.  If libpthread isn't available on an
> architecture, default ship libmap.conf to substitute libthr for
> libpthread on the platform for all applications.  Or libc_r, or
> whatever.
>
> This will result in all applications we ship having a consistent thread
> library name so that administrators can substitute more easily.
> libpthread would give you M:N threading by default, but it would be easy
> to perform local changes to improve performance for applications that
> specifically benefit from 1:1 threading, cothreads, etc.  Or if a
> serious compatibility bug is found between libpthread and an
> application, they can substitute easily as well.  I suppose this case
> might imply (4):
>
> (4) If an application is known to be compatible only with a specific
> threading model, do hard-code that in the application build somehow.

This sounds to me like the best solution I've seen so far. We have libmap,
so why not use it? Only expert users will probably want to play with
different thread libraries, and they can find out about libmap.conf
themselves.

Arjan


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[Robert Watson]

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 with -lpthread -- i.e.,
a dynamic library dependency on libpthread.  This will mean that
administrators don't have to list each possible threading library in
/etc/libmap.conf in order to be sure they caught all of them.

(3) Use libmap to perform the necessary substitution on a per-application
or per-system basis.  If libpthread isn't available on an
architecture, default ship libmap.conf to substitute libthr for
libpthread on the platform for all applications.  Or libc_r, or
whatever.

This will result in all applications we ship having a consistent thread
library name so that administrators can substitute more easily. libpthread
would give you M:N threading by default, but it would be easy to perform
local changes to improve performance for applications that specifically
benefit from 1:1 threading, cothreads, etc.  Or if a serious compatibility
bug is found between libpthread and an application, they can substitute
easily as well.  I suppose this case might imply (4):

(4) If an application is known to be compatible only with a specific
threading model, do hard-code that in the application build somehow.

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Initial list of ports that fail due to -pthread

[Michael Edenfield]

* 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 threading, than the ports that depend on it.
> > The qt-using ports appear to check for -lpthread, then c++ -pthread, and
> > if neither of those checks pass, disable threading:
> 
> Also, I believe I fixed qt32 on 18 September 2003.  It certainly
> built and works fine on my 5.1-CURRENT 2003/09/19 box.  It's just
> KDE that needs fixing at the moment.

Yes, Qt itself worked fine, it was just the rest of KDE that gave me
issues.  I've already fixed the issue temporarily by passing --enable-mt
and --enable-threading as CONFIGURE_ARGS and doing some post-configure
replacing of -{l}pthread, I just wanted to point out the problem since
it's slightly different than just 'cc breaks because -pthread is an
error.' 

But since you're already well ahead of me fixing it I'll skip the pr I
was about to send in :)

--Mike



pgp0.pgp
Description: PGP signature

RE: Fixing -pthreads (Re: ports and -current)

[John Baldwin]

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. As an end-user, I am not interested in
>> hacking around the source of 3rd-party applications that use -pthread
>> when compiling them from source myself. Not in the slightest. This is
>> BAD BAD BAD for usability.
>> 
>> Sincerely,
>> Dan Naumov
> 
> I also believe that a question has to be asked, what do the -core and
> -arch people think of all this ? I think that they should have the final
> say in the matter.

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?  The fact that functions live in libraries and that
to get access to said functions you link with said libraries has been
the practice on Un*x for longer than I've been alive.  Please, people,
let the -pthread hack die and just use -l.
I think any FreeBSD-specific -pthread bits should just be removed
and have the compiler complain about a bogus option.  If gcc chooses
to have a machine independent -pthread (or -thread) to turn on TLS or
some such, that's great and all, but that would be gcc code, not
FreeBSD-specific code.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: dhclient/ipfw conflict on boot

[David Wolfskill]

>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 initialization 
>of ipfw2 (default to deny policy).  As all traffic is denied until my 
>firewall ruleset gets loaded (not until just after dhclient fails), it's 
>unable to communicate with my ISP's DHCP server.

>This should be a quick and easy fix, right?  :-)

Well, my approach to a "quick and easy fix" is "Don't do that."

For my laptop, I set up an ipfw specification that, on boot, only
permitted DHCP traffic.

Then in /etc/dhclient-exit-hooks, once I've got a lease, I invoke a
different script that flushes the old rules and creates a new set, based
on such things as my new IP address and the address of the DHCP server.

Also in /etc/dhclient-exit-hooks, if it's invoked when dhclient is
exiting (leaving the network), the script re-invokes the "default" ipfw
script.

Peace,
david
-- 
David H. Wolfskill  [EMAIL PROTECTED]
If you want true virus-protection for your PC, install a non-Microsoft OS
on it.  Plausible candidates include FreeBSD, Linux, NetBSD, OpenBSD, and
Solaris (in alphabetical order).
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[Brad Knowles]

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.
	It strikes me that the compiler and linker should be able to 
detect -lthr vs. -lpthread vs. -lksethread (or whatever) on the 
command line, and if they see something like that to just DTRT with 
regards to a -pthread as well.

	Contrariwise, if there is a -pthread and no corresponding -lthr, 
-lpthread, or other thread library linkage that is explicitly 
specified, then we should be able to go through pmap.conf and figure 
out what the default "right thing" is that should be done.

	What am I missing?

 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.
 (*) Unless we want to support LD_PRELOAD being able
 to change the threads library.
	That would seem to be another reasonable option.

--
Brad Knowles, <[EMAIL PROTECTED]>
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[Sheldon Hearn]

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's really, REALLY good news.

Will Andrews recently posted a patch on -current and mentioned that
-pthread is back but will go away again soon.  Can I relax and disregard
his comment? :-)

> > Is there a simple rule we should follow when trying to fix ports, or do
> > we have to think now?
> 
> Someone has to think and make a decision. Is simplicity (the -pthread switch)
> reason enough to support one thread library by default?

I'm happy with -pthread providing a simple default, which I can override
if I think I know what my software really wants. :-)

Ciao,
Sheldon.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[Alex Keahan]

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 use this option in
the
 compile and link steps.  To obtain faster
execution,
 this option requires a multiprocessor system. On
a
 single-processor system, the resulting executable
 usually runs more slowly with this option.

Solaris 8 also has two pthread libraries, M:N and 1:1,
located in /usr/lib and /usr/lib/lwp, respectively.  
It
defaults to M:N, but the alternate libpthread can be
selected at runtime by setting the dynamic linker
search path as follows:

LD_LIBRARY_PATH=/usr/lib/lwp (32-bit)
LD_LIBRARY_PATH_64=/usr/lib/lwp/sparcv9 (64-bit)

Alternatively, the runpath can be specified at link
time:

cc -mt ... -R /usr/lib/lwp (32-bit)
cc -mt ... -R /usr/lib/lwp/sparcv9 (64-bit)

Alex Keahan



Want to chat instantly with your online friends?  Get the FREE Yahoo!
Messenger http://mail.messenger.yahoo.co.uk
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[John Birrell]

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. 8-)

> Is there a simple rule we should follow when trying to fix ports, or do
> we have to think now?

Someone has to think and make a decision. Is simplicity (the -pthread switch)
reason enough to support one thread library by default?

> At the moment, I'm just patching configure files
> to use ${PTHREAD_LIBS} instead of -pthread, and pushing PTHREAD_LIBS
> into the ports' CONFIGURE_ENV.

I don't think that CONFIGURE_ENV should be modified in each port's makefile
to cope with PTHREAD_LIBS. It's supposed to be a ports-wide thing, so it
belongs in bsd.port.mk.

-- 
John Birrell
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[Sheldon Hearn]

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.

Okay, so what are we supposed to do to ports that are now broken because
-pthread doesn't exist (e.g. devel/pwlib)?

This discussion has gone around in circles and I haven't read every
message, but it's pretty obvious there's a lot of confusion.

Is there a simple rule we should follow when trying to fix ports, or do
we have to think now?  At the moment, I'm just patching configure files
to use ${PTHREAD_LIBS} instead of -pthread, and pushing PTHREAD_LIBS
into the ports' CONFIGURE_ENV.

Ciao,
Sheldon.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

KDE 3.1.4 on 5.1-CURRENT fixes for PTHREAD_LIBS

[Will Andrews]

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 this.  Followups to [EMAIL PROTECTED], flames to
/dev/null.  Thanks for your time.

Note1: At the moment KDE hasn't been built on axp* for 4.9R, so
   this patch won't be committed in the meantime.

Note2: Yes, we know -pthread was temporarily put back.  It will
   be removed again soon.

Note3: There are several ports that use KDE's configure scripts
   but are not maintained by us.  These ports are most likely
   still broken.  Some of them use our Makefile.kde code, and
   for those, I've added a line to ignore our pthfix since
   they will need their own.

Note4: Patch has been applied to KDE HEAD to resolve the same issues.
   Therefore, this patch will be removed when 3.2 is released.

Regards,
-- 
wca
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Initial list of ports that fail due to -pthread

[Morten Rodal]

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

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Initial list of ports that fail due to -pthread

[Sergey Matveychuk]

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 PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fixing -pthreads (Re: ports and -current)

[Marcin Dalecki]

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 be a problem with
the compiler install instead of what it's supposed to tell me.
I still stay by this: This is silly and annoying for someone not
esp. interrested in all those wars about which thread lib is better then the other.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: What's happened to CDIOCREADAUDIO & friends?

[Peter Jeremy]

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 \
>-s -c 2 -w - -t wav -r 44100 -s -c 2 -w track01.wav
>
>Funny thing is, it is a hell of a lot faster than dagrab was.  Before, 
>dagrab would read the data in at about the same rate as flac would encode 
>it, but now I can rip a 12 track disc in the time it takes flac to encode 
>the first 6 tracks.  Go figure...

dagrab reads each block of data multiple times until it gets identical
results.  The code mentions "jitter correction" but doesn't include
any detailed explanation.  For a more equitable comparison, I suggest
you hack dagrab.c:cd_read_audio() to use read() ISO ioctl().

Peter
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"