libpthread vs libthr.
Nikolay Pavlov
advantages of some special threading model, but still i would like to
figure out why libthr in it current state is not our default posix
thread library and could it be so in time of 7-STABLE?
As a user and administrator of FreeBSD i want to mention some benefits
of libthr:
1. It's simpler.
2. It's stable and has been used by many of us for a long time.
3. It proved to be very productive on real world applications.
4. It has active talented developers.
5. If it was a default library it would couse a incrase of users
feedback which would lead to futher improvement of it's code by the time
7 becomes a stable branch.
And some flaws of libpthread:
1. It's more difficult.
2. It's slow in compare of libthr.
3. The last, but the worst. IMHO the position under which libpthread is
the library by default is the source of a bad myth that threading model
in FreeBSD sucks and threading applications is slow. If 7.0 had libthr
as a default posix threads library we could brake that belief.
This point of view may seem one-sided that is why someone with good
knowledge of the current state of code could tell other pros and cons
of both libraries.
Another interesting question is which of the libraries will better work
with multikernel and multiprocessor systems which will be very popular
by the time 7.0 branch launches its stable releases.
--
======================================================================
- Best regards, Nikolay Pavlov. <<<-----------------------------------
======================================================================
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
George V. Neville-Neil
discussed on the threads@ mailing list. You might want to read over
the recent mail there.
Best,
George
Norikatsu Shigemura
Nikolay Pavlov <que...@zone3000.net> wrote:
> Hi. In this post i am not trying to raise a discussion about teoretical
> advantages of some special threading model, but still i would like to
> figure out why libthr in it current state is not our default posix
> thread library and could it be so in time of 7-STABLE?
I don't agree. Do test, run by again, do test.
I read a discussion about libpthread vs libthr, so I tested on
my environments(7-current SMP and 6-stable UP). My result is
NOT YET, and I resurrected to libpthread environment.
1. libthr is not enough mature.
At this time, libpthread's pthread API support > libthr's
pthread API support. So libthr lacks of compatibility with
libpthread. It is not good.
2. Not PTHREAD_CFLAGS/PTHREAD_LIBS clean
At this time, tinderbox doesn't test PTHREAD_CFLAGS/
PTHREAD_LIBS clean. We have need to check PTHREAD_CFLAGS/
PTHREAD_LIBS clean on all ports.
3. Is libthr environments useful?
I don't think. Yes, I think that some applications like mysql
are useful. However, in all FreeBSD environment system, by 1
and 2, libthr is not useful.
Ruslan Ermilov
To make user's life easier, I suggest the following simple patch.
Its effect on platforms where libpthread is available is to (sym)link
libthr to libpthread if WITHOUT_LIBPTHREAD is set in /etc/src.conf.
This would allow more people interested in libthr testing to more
easily do it. (Of course already linked applications wouldn't
magically start using libthr without also patching /etc/libmap.conf.)
%%%
Index: Makefile
===================================================================
RCS file: /home/ncvs/src/lib/libthr/Makefile,v
retrieving revision 1.20
diff -u -p -r1.20 Makefile
--- Makefile 22 Aug 2006 07:51:06 -0000 1.20
+++ Makefile 10 Nov 2006 17:27:40 -0000
@@ -42,7 +42,7 @@ PRECIOUSLIB=
.include "${.CURDIR}/sys/Makefile.inc"
.include "${.CURDIR}/thread/Makefile.inc"
-.if ${MACHINE_ARCH} == "sparc64"
+.if ${MACHINE_ARCH} == "sparc64" || ${MK_LIBPTHREAD} == "no"
SYMLINKS+=lib${LIB}.a ${LIBDIR}/libpthread.a
.if !defined(NO_PIC)
SYMLINKS+=lib${LIB}.so ${LIBDIR}/libpthread.so
%%%
Cheers,
--
Ruslan Ermilov
r...@FreeBSD.org
FreeBSD committer
David Xu
Hi,
I think this patch is useful. :-)
Thanks,
David Xu
Kris Kennaway
> On Fri, 10 Nov 2006 17:12:47 +0200
> Nikolay Pavlov <que...@zone3000.net> wrote:
> > Hi. In this post i am not trying to raise a discussion about teoretical
> > advantages of some special threading model, but still i would like to
> > figure out why libthr in it current state is not our default posix
> > thread library and could it be so in time of 7-STABLE?
>
> I don't agree. Do test, run by again, do test.
>
> I read a discussion about libpthread vs libthr, so I tested on
> my environments(7-current SMP and 6-stable UP). My result is
> NOT YET, and I resurrected to libpthread environment.
>
> 1. libthr is not enough mature.
> At this time, libpthread's pthread API support > libthr's
> pthread API support. So libthr lacks of compatibility with
> libpthread. It is not good.
Which applications does this effect? I'm not aware of any (see
below).
> 2. Not PTHREAD_CFLAGS/PTHREAD_LIBS clean
> At this time, tinderbox doesn't test PTHREAD_CFLAGS/
> PTHREAD_LIBS clean. We have need to check PTHREAD_CFLAGS/
> PTHREAD_LIBS clean on all ports.
The existence of libmap makes this objection irrelevant. Also,
sparc64 uses libthr by default and I'm not aware of any resulting port
build problems. So apparently any missing API features are not widely
used, or are successfully worked around. Can you provide evidence to
the contrary?
> 3. Is libthr environments useful?
> I don't think. Yes, I think that some applications like mysql
> are useful. However, in all FreeBSD environment system, by 1
> and 2, libthr is not useful.
Maybe you don't care that libpthread's performance is terrible and
e.g. this makes FreeBSD look bad on benchmarks, both published and
when a user evaluates FreeBSD against other systems to decide whether
or not to use it on their workloads - but surely most people do.
Kris
Norikatsu Shigemura
My case is gdm (x11/gdm). gdm doesn't works by using libthr
instead of libpthread (changing by libmap). gdm couldn't
resolve a symbol, sched_yield(2). So X server didn't run.
In this case, gdm tried to resolve a symbol,
sched_yield@LIBTHREAD_1_0 instead of sched_yield. So by changing
libthr by libmap, gdm couldn't resolve a symbol, sched_yield(2).
libthr doesn't have a sched_yield@LIBTHREAD_1_0, Yes, libc have
a sched_yield, but sched_yield@LIBTHREAD_1_0.
This problem can resolve by recompiling all applications by using
libthr like PTHREAD_LIBS=-lthr, I believe. And I don't have
confidence about all applications conforming PTHREAD_LIB=-lthr.
In sparc64 case, -pthread is libthr(by symlink), but in i386 and
some other arch case, -pthread is libpthread. So compiling
condition is too different.
> > 3. Is libthr environments useful?
> > I don't think. Yes, I think that some applications like mysql
> > are useful. However, in all FreeBSD environment system, by 1
> > and 2, libthr is not useful.
> Maybe you don't care that libpthread's performance is terrible and
> e.g. this makes FreeBSD look bad on benchmarks, both published and
> when a user evaluates FreeBSD against other systems to decide whether
> or not to use it on their workloads - but surely most people do.
I agree about a performance problem and libthr bringing
performance UP. But we cannot mix libpthread and libthr in a
application (= a process). One application use libthr, but one
plugin called by it use libpthread. it doesn't work:-(. By
using libthr, libthr brings performance UP but application is
crashed, it is not good.
Therefore, I like ru's suggestion (${MK_LIBPTHREAD}=="no" check).
But it is not evidence of PTHREAD_CFLAGS/PTHREAD_LIBS clean.
Dag-Erling Smørgrav
This is not a libthr issue, it's a symbol versioning issue. Arguably,
sched_yield should be removed from libpthread's symbol map, because
it's a wrapper for a syscall and we don't version syscalls.
DES
--
Dag-Erling Smørgrav - d...@des.no
Daniel Eischen
>> resolve a symbol, sched_yield(2). So X server didn't run.
>>
>> In this case, gdm tried to resolve a symbol,
>> sched_yield@LIBTHREAD_1_0 instead of sched_yield. So by changing
>> libthr by libmap, gdm couldn't resolve a symbol, sched_yield(2).
>> libthr doesn't have a sched_yield@LIBTHREAD_1_0, Yes, libc have
>> a sched_yield, but sched_yield@LIBTHREAD_1_0.
>
> This is not a libthr issue, it's a symbol versioning issue. Arguably,
> sched_yield should be removed from libpthread's symbol map, because
> it's a wrapper for a syscall and we don't version syscalls.
Yah we do, see src/lib/libc/sys/Symbol.map.
In the above case(s), libpthread and libthr use LIBTHREAD_1_0 as the
version namespace. This was done back in 5.x. But now that libc
has symbol versioning and the thread libraries want to override
some symbols in libc, they (libc and the thread libraries) need
to use the same version namespace. I added LIBTHREAD_1_0 as a
compatibility hack to libpthread in -current, but it also has
and defaults to FBSD_1_0 which is also used by libc.
The way to fix this for the above problem is to enable symbol
versioning (set SYMVER_ENABLED=yes in /etc/make.conf) and rebuild
world. Then rebuild your ports. After that, all your ports will
reference symbols in FBSD_1_0, and if libthr doesn't provide
sched_yield@FBSD_1_0, it'll find it in libc.
Before 7.0 goes out the door, symbol versioning will be enabled
by default so you won't have this problem.
--
DE
Norikatsu Shigemura
d...@des.no (Dag-Erling Smørgrav) wrote:
> Norikatsu Shigemura <no...@FreeBSD.org> writes:
> > In this case, gdm tried to resolve a symbol,
> > sched_yield@LIBTHREAD_1_0 instead of sched_yield. So by changing
> > libthr by libmap, gdm couldn't resolve a symbol, sched_yield(2).
> > libthr doesn't have a sched_yield@LIBTHREAD_1_0, Yes, libc have
> > a sched_yield, but sched_yield@LIBTHREAD_1_0.
> This is not a libthr issue, it's a symbol versioning issue. Arguably,
> sched_yield should be removed from libpthread's symbol map, because
> it's a wrapper for a syscall and we don't version syscalls.
Sigh... Yes, it is not a libthr issue and a symbol versioning
issue, but only a symbol versioning issue.
(I think it is a issue that libpthread/libthr using SYMVER
enabled by default. But TEST is significant:-)
The point of these issues is a relation of FreeBSD system, kernel
- libraries - userland(applications). We don't have a mutually
commutative layer changing(almost works, but...). At least, we
need re-compiling. At this time, I think that test is not enough.
Norikatsu Shigemura
Daniel Eischen <deis...@freebsd.org> wrote:
> The way to fix this for the above problem is to enable symbol
> versioning (set SYMVER_ENABLED=yes in /etc/make.conf) and rebuild
> world. Then rebuild your ports. After that, all your ports will
> reference symbols in FBSD_1_0, and if libthr doesn't provide
> sched_yield@FBSD_1_0, it'll find it in libc.
I don't know that this issue will fix. But I know many problems
with SYMVER_ENABLED=yes.
1. java_vm is too unstable.
I couldn't compile OOo (editors/openoffice.org-2.0) once.
However, in disabled SYMVER_ENABLED=yes environment,
I could compile OOo once.
2. some gtk applications are too unstable.
scim (textproc/scim and japanese/scim-canna) would crash
unexpenctedly.
3. firefox (www/firefox) cannot connect(2) to servers.
firefox issue connect(2) system call. But it failed.
4. synergys (sysutils/synergy) is locked.
synergyc connected to synergys, and synergys was locked.
I already reported above issues:
http://lists.freebsd.org/pipermail/freebsd-current/2006-July/064605.html
These issues are available with SYMVER_ENABLE=yes. So I disabled
SYMVER_ENABLE=yes, and these issues are fixed.
Norikatsu Shigemura
> reference symbols in FBSD_1_0, and if libthr doesn't provide
> sched_yield@FBSD_1_0, it'll find it in libc.
By the way, can gdm resolve sched_yield@FBSD_1_0 instead of
sched_yield@LIBTHREAD_1.0? I don't think so. Is there a
symbol resolving fallback mechanism which I don't know?
Daniel Eischen
> On Sat, 11 Nov 2006 12:33:37 -0500 (EST)
> Daniel Eischen <deis...@freebsd.org> wrote:
>> world. Then rebuild your ports. After that, all your ports will
>> reference symbols in FBSD_1_0, and if libthr doesn't provide
>> sched_yield@FBSD_1_0, it'll find it in libc.
>
> By the way, can gdm resolve sched_yield@FBSD_1_0 instead of
> sched_yield@LIBTHREAD_1.0? I don't think so. Is there a
> symbol resolving fallback mechanism which I don't know?
See previous email. You have to rebuild all your ports.
--
DE
Daniel Eischen
> On Sat, 11 Nov 2006 12:33:37 -0500 (EST)
> Daniel Eischen <deis...@freebsd.org> wrote:
>> The way to fix this for the above problem is to enable symbol
>> versioning (set SYMVER_ENABLED=yes in /etc/make.conf) and rebuild
>> world. Then rebuild your ports. After that, all your ports will
>> reference symbols in FBSD_1_0, and if libthr doesn't provide
>> sched_yield@FBSD_1_0, it'll find it in libc.
>
> I don't know that this issue will fix. But I know many problems
> with SYMVER_ENABLED=yes.
You have to rebuild all your ports if you want to do this.
Or wait until the libraries get bumped and symbol versioning
gets enabled.
--
DE
Chris
HI I posted in another thread about how my own experiences seem to
differ from all these benchmarks, they are based on 3 heavily loaded
web/mysql servers.
One is freebsd 6.1 dual core cpu (not htt). 2nd is dual xeon freebsd
6.1 and 3rd is another dual xeon freebsd 6.1.
All 3 of these machines perform better as well as more stable under
higher loads using libpthread process scope.
System scope appears to make mysql hog the system and everything slows
down except of course mysql.
Libthr appears to make mysql very sporadic with some requests fast
others with a unexplained 5-10 sec delay including timeouts.
Process scope on libpthread gives me the best results not making mysql
starve the server of resources and it has a consistent response time
of under 2 seconds under hevay loads.
I cant explain other then it maybe that test mysql data isnt a proper
way to test these threading libraries only real work loads can.
Chris
Norikatsu Shigemura
Daniel Eischen <deis...@freebsd.org> wrote:
> > I don't know that this issue will fix. But I know many problems
> > with SYMVER_ENABLED=yes.
> You have to rebuild all your ports if you want to do this.
> Or wait until the libraries get bumped and symbol versioning
> gets enabled.
Sigh. I already REBUILD ALL, system and ports like
following the procedure, again and again.
# pkg_info > /var/tmp/pkg_info.lst
# pkg_delete -a
# umount /compat/linux
# mv /usr/local /usr/local.old
# mv /usr/X11R6 /usr/X11R6.old
# mv /compat/linux /compat/linux.old
# mkdir -p /usr/local /usr/X11R6 /compat/linux/proc
# echo SYMVER_ENABLED=yes >> /etc/make.conf
# make buildworld buildkernel
# make installkernel installworld
# shutdown -r now
# (reinstall all ports to my envionment)
Daniel Eischen
> On Sat, 11 Nov 2006 14:27:11 -0500 (EST)
> Daniel Eischen <deis...@freebsd.org> wrote:
>>> I don't know that this issue will fix. But I know many problems
>>> with SYMVER_ENABLED=yes.
>> You have to rebuild all your ports if you want to do this.
>> Or wait until the libraries get bumped and symbol versioning
>> gets enabled.
>
> Sigh. I already REBUILD ALL, system and ports like
> following the procedure, again and again.
>
> # pkg_info > /var/tmp/pkg_info.lst
> # pkg_delete -a
> # umount /compat/linux
> # mv /usr/local /usr/local.old
> # mv /usr/X11R6 /usr/X11R6.old
> # mv /compat/linux /compat/linux.old
> # mkdir -p /usr/local /usr/X11R6 /compat/linux/proc
> # echo SYMVER_ENABLED=yes >> /etc/make.conf
> # make buildworld buildkernel
> # make installkernel installworld
> # shutdown -r now
> # (reinstall all ports to my envionment)
Well, I haven't heard of any other problems. I've been using
it on several machines with X, KDE, mplayer, mozilla, firefox,
etc. No problems. Do you have any local mods, like to rtld?
--
DE
Julian Elischer
[...]
>
>
> HI I posted in another thread about how my own experiences seem to
> differ from all these benchmarks, they are based on 3 heavily loaded
> web/mysql servers.
>
> One is freebsd 6.1 dual core cpu (not htt). 2nd is dual xeon freebsd
> 6.1 and 3rd is another dual xeon freebsd 6.1.
>
> All 3 of these machines perform better as well as more stable under
> higher loads using libpthread process scope.
>
> System scope appears to make mysql hog the system and everything slows
> down except of course mysql.
Is this libpthread "system scope" or libthr (which has system scope by
default)?
>
> Libthr appears to make mysql very sporadic with some requests fast
> others with a unexplained 5-10 sec delay including timeouts.
>
> Process scope on libpthread gives me the best results not making mysql
> starve the server of resources and it has a consistent response time
> of under 2 seconds under heavy loads.
this is interesting.. there has been a call to remove "fairness"
as a threading property as it complicates the scheduler.
It has been said by many that they do not consider this as an important
feature and it reduces throughput.
Ivan Voras
> this is interesting.. there has been a call to remove "fairness"
> as a threading property as it complicates the scheduler.
> It has been said by many that they do not consider this as an important
> feature and it reduces throughput.
IMO both sides are right and fairness should be optional. It will
certainly help some workloads and harm others; leaving it as a (default)
kernel compile option is fine for now, as long as it's documented how to
toggle it (in pthread man page at least).
David Xu
with process scope, it will use it, this is only removed in -CURRENT,
I don't know why you said that it starved server resource if KSEGRP
really works as expected.
Chris
Interesting libthr can use system or process scope? as far as I am
aware it was using whatever the default is for libthr.
David Xu
>
> Interesting libthr can use system or process scope? as far as I am
> aware it was using whatever the default is for libthr.
>
> Chris
FreeBSD 6.1, the default is libthr uses process scope, but I know
mysql explicitly uses system scope thread unless you forced it
to use process scope(there is a knob in the ports's Makefile).
if the mysql uses system scope (the default), you should see
the same effect with libpthread, i.e you said it starved your
server.
David Xu
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Chris
> On Monday 13 November 2006 12:20, Chris wrote:
> >
> > Interesting libthr can use system or process scope? as far as I am
> > aware it was using whatever the default is for libthr.
> >
> > Chris
>
> FreeBSD 6.1, the default is libthr uses process scope, but I know
> mysql explicitly uses system scope thread unless you forced it
> to use process scope(there is a knob in the ports's Makefile).
> if the mysql uses system scope (the default), you should see
> the same effect with libpthread, i.e you said it starved your
> server.
>
> David Xu
>
Chris
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
--
Norikatsu Shigemura
In the case you said (echo WITHOUT_LIBPTHREAD=yes >> /etc/src.conf),
we cannot get libkse.*. Because lib/libpthread is omitted in
lib/Makefile:-(.
I'm trying to test PTHREAD_CFLAGS/PTHREAD_LIBS. So I prepared
following environment.
x libpthread.* (removed as passible as)
o libkse.*
o libthr.*
But WITHOUT_LIBPTHREAD (MK_LIBPTHREAD=no) option is too danger.
$ cd /usr/src
$ fgrep -r MK_LIBPTHREAD .
./lib/Makefile:.if ${MK_LIBPTHREAD} != "no"
./sbin/ggate/Makefile:.elif ${MK_LIBPTHREAD} != "no"
./share/man/man3/Makefile:.if ${MK_LIBPTHREAD} != "no" || ${MK_LIBTHR} != "no"
./tools/build/mk/OptionalObsoleteFiles.inc:#.if ${MK_LIBPTHREAD} == no
./usr.bin/Makefile:.elif ${MK_LIBPTHREAD} != "no"
./usr.sbin/Makefile:.if ${MK_LIBPTHREAD} != "no"
./usr.sbin/Makefile:.if ${MK_LIBPTHREAD} != "no"
./usr.sbin/Makefile:.if ${MK_LIBPTHREAD} != "no"
ok lib/Makefile has no problem.
ng In case of sbin/ggate/Makefile, ggatec and ggated will not be
installed.
ok share/man/man3/Makefile has no problem.
ok tools/build/mk/OptionalObsoleteFiles.inc has no problem.
ng In case of usr.bin/Makefile, csup will not be installed.
ng In case of usr.sbin/Makefile, pppctl will not be installed.
And usr.sbin/cached/Makefile and usr.sbin/ngctl/Makefile is not
good WITHOUT_LIBPTHREAD. I couldn't compile them. I think that
these should be omitted in usr.sbin/Makefile like pppctl case.
And FreeBSD src tree don't have PTHREAD_CFLAGS/PTHREAD_LIBS clean
mechanism. I think that there are some way to adopt PTHREAD_CFLAGS/
PTHREAD_LIBS to src tree, maybe. But I don't know how do I do
anyway.
1. force lib/libpthread install libkse.* to /usr/lib, and symlink
to /lib/libpthread.*. I don't know KEYWORD to symlink to /lib/
libpthread.* from libkse.*/libthr.*.
2. Fix like following in usr.bin/Makefile and usr.sbin/Makefile:
.if ${MK_LIBPTHREAD} != "no"
.....
:
to
.if ${MK_LIBPTHREAD} != "no" || ${MK_LIBTHR} != "no"
.....
:
And compile force lib/libpthread. And in case of
MK_LIBPTHREAD=no, symlink libthr.* to libpthread.*.
Norikatsu Shigemura
Norikatsu Shigemura <no...@FreeBSD.org> wrote:
> In the case you said (echo WITHOUT_LIBPTHREAD=yes >> /etc/src.conf),
> we cannot get libkse.*. Because lib/libpthread is omitted in
> lib/Makefile:-(.
Oops, it is right that we cannot get libkse.*. ru is right.
I'm sorry.
Because, however, I cannot test PTHREAD_CFLAGS/PTHREAD_LIBS clean.
So I modifed like following patches.
--- usr.bin/Makefile.orig Tue Aug 22 12:22:17 2006
+++ usr.bin/Makefile Sun Nov 26 12:12:09 2006
@@ -266,7 +266,7 @@
.if ${MK_LIBTHR} != "no"
_csup= csup
.endif
-.elif ${MK_LIBPTHREAD} != "no"
+.elif ${MK_LIBPTHREAD} != "no" || ${MK_LIBTHR} != "no"
_csup= csup
.endif
.endif
--- usr.bin/csup/Makefile.orig Tue Mar 14 12:53:50 2006
+++ usr.bin/csup/Makefile Sun Nov 26 12:17:33 2006
@@ -30,7 +30,7 @@
CFLAGS+= -DHAVE_FFLAGS -DNDEBUG
WARNS?= 6
-DPADD= ${LIBCRYPTO} ${LIBZ} ${LIBPTHREAD}
-LDADD= -lcrypto -lz -lpthread
+DPADD= ${LIBCRYPTO} ${LIBZ} ${LIBTHR}
+LDADD= -lcrypto -lz -lthr
.include <bsd.prog.mk>
--- usr.sbin/Makefile.orig Wed Nov 15 23:57:05 2006
+++ usr.sbin/Makefile Sun Nov 26 12:11:18 2006
@@ -305,7 +305,7 @@
_mptable= mptable
_ndiscvt= ndiscvt
_pnpinfo= pnpinfo
-.if ${MK_LIBPTHREAD} != "no"
+.if ${MK_LIBPTHREAD} != "no" || ${MK_LIBTHR} != "no"
_pppctl= pppctl
.endif
_sicontrol= sicontrol
--- usr.sbin/cached/Makefile.orig Fri Apr 28 21:03:37 2006
+++ usr.sbin/cached/Makefile Sun Nov 26 12:19:43 2006
@@ -9,8 +9,8 @@
config.c query.c mp_ws_query.c mp_rs_query.c singletons.c protocol.c \
parser.c
CFLAGS+= -DCONFIG_PATH="\"${PREFIX}/etc/cached.conf\""
-DPADD+=${LIBM} ${LIBPTHREAD} ${LIBUTIL}
-LDADD+=${LIBM} ${LIBPTHREAD} ${LIBUTIL}
+DPADD+=${LIBM} ${LIBTHR} ${LIBUTIL}
+LDADD+=${LIBM} ${LIBTHR} ${LIBUTIL}
LDFLAGS+= -Xlinker --export-dynamic
.PATH: ${.CURDIR}/agents
--- usr.sbin/ngctl/Makefile.orig Mon Aug 7 23:17:05 2006
+++ usr.sbin/ngctl/Makefile Sun Nov 26 12:27:36 2006
@@ -16,8 +16,8 @@
.if !defined(NGCTL_NO_LIBEDIT)
CFLAGS+= -DEDITLINE
-DPADD+= ${LIBPTHREAD} ${LIBEDIT} ${LIBTERMCAP}
-LDADD+= -pthread -ledit -ltermcap
+DPADD+= ${LIBTHR} ${LIBEDIT} ${LIBTERMCAP}
+LDADD+= -lthr -ledit -ltermcap
.endif
.include <bsd.prog.mk>
--- usr.sbin/pppctl/Makefile.orig Sun Feb 1 02:28:09 2004
+++ usr.sbin/pppctl/Makefile Sun Nov 26 12:22:34 2006
@@ -3,7 +3,7 @@
PROG= pppctl
MAN= pppctl.8
-DPADD= ${LIBPTHREAD} ${LIBEDIT} ${LIBTERMCAP}
-LDADD= -lpthread -ledit -ltermcap
+DPADD= ${LIBTHR} ${LIBEDIT} ${LIBTERMCAP}
+LDADD= -lthr -ledit -ltermcap
.include <bsd.prog.mk>
--- share/mk/bsd.libnames.mk.orig Sat Sep 30 20:32:46 2006
+++ share/mk/bsd.libnames.mk Sun Nov 26 15:55:35 2006
@@ -119,6 +119,7 @@
LIBPCAP?= ${DESTDIR}${LIBDIR}/libpcap.a
LIBPMC?= ${DESTDIR}${LIBDIR}/libpmc.a
LIBPTHREAD?= ${DESTDIR}${LIBDIR}/libpthread.a
+LIBTHR?= ${DESTDIR}${LIBDIR}/libthr.a
LIBRADIUS?= ${DESTDIR}${LIBDIR}/libradius.a
LIBREADLINE?= ${DESTDIR}${LIBDIR}/libreadline.a
LIBROKEN?= ${DESTDIR}${LIBDIR}/libroken.a
--- lib/libpthread/Makefile.orig Sun Nov 26 00:59:59 2006
+++ lib/libpthread/Makefile Sun Nov 26 00:59:23 2006
@@ -7,7 +7,7 @@
# To included legacy CSRG sccsid strings, add -DLIBC_SCCS and -DSYSLIBC_SCCS
# (for system call stubs) to CFLAGS below. -DSYSLIBC_SCCS affects just the
# system call stubs.
-.if ${MACHINE_ARCH} == "sparc64"
+.if ${MACHINE_ARCH} == "sparc64" || ${MK_LIBPTHREAD} == "no"
LIB=kse
.else
LIB=pthread
--- lib/Makefile.orig Sun Nov 26 19:48:02 2006
+++ lib/Makefile Sun Nov 26 19:47:06 2006
@@ -98,13 +98,13 @@
_libsmb= libsmb
.endif
-.if ${MK_LIBPTHREAD} != "no"
+#.if ${MK_LIBPTHREAD} != "no"
_libpthread= libpthread
-.endif
+#.endif
-.if ${MK_LIBTHR} != "no"
+#.if ${MK_LIBTHR} != "no"
_libthr= libthr
-.endif
+#.endif
.if ${MACHINE_ARCH} != "arm"
_libthread_db= libthread_db
Ruslan Ermilov
Why is it a problem? We don't want to hear about libkse.
> I'm trying to test PTHREAD_CFLAGS/PTHREAD_LIBS. So I prepared
> following environment.
>
> x libpthread.* (removed as passible as)
> o libkse.*
> o libthr.*
>
> But WITHOUT_LIBPTHREAD (MK_LIBPTHREAD=no) option is too danger.
>
> $ cd /usr/src
> $ fgrep -r MK_LIBPTHREAD .
> ./lib/Makefile:.if ${MK_LIBPTHREAD} != "no"
> ./sbin/ggate/Makefile:.elif ${MK_LIBPTHREAD} != "no"
> ./share/man/man3/Makefile:.if ${MK_LIBPTHREAD} != "no" || ${MK_LIBTHR} != "no"
> ./tools/build/mk/OptionalObsoleteFiles.inc:#.if ${MK_LIBPTHREAD} == no
> ./usr.bin/Makefile:.elif ${MK_LIBPTHREAD} != "no"
> ./usr.sbin/Makefile:.if ${MK_LIBPTHREAD} != "no"
> ./usr.sbin/Makefile:.if ${MK_LIBPTHREAD} != "no"
> ./usr.sbin/Makefile:.if ${MK_LIBPTHREAD} != "no"
>
[...]
> ng In case of sbin/ggate/Makefile, ggatec and ggated will not be
> installed.
>
The conditional should be changed to
.elif ${MK_LIBPTHREAD} != "no" || ${MK_LIBTHR} != "no"
so it benefits from my patch to libthr/Makefile.
> ng In case of usr.bin/Makefile, csup will not be installed.
> ng In case of usr.sbin/Makefile, pppctl will not be installed.
>
The same change here.
> And usr.sbin/cached/Makefile and usr.sbin/ngctl/Makefile is not
> good WITHOUT_LIBPTHREAD. I couldn't compile them. I think that
> these should be omitted in usr.sbin/Makefile like pppctl case.
>
You mean without my patch and with WITHOUT_LIBPTHREAD, and with my
patch and wit both WITHOUT_LIBPTHREAD and WITHOUT_LIBTHR? Yes, these
need to be fixed (see the patch).
> And FreeBSD src tree don't have PTHREAD_CFLAGS/PTHREAD_LIBS clean
> mechanism. I think that there are some way to adopt PTHREAD_CFLAGS/
> PTHREAD_LIBS to src tree, maybe. But I don't know how do I do
> anyway.
>
Why? Just using ${LIBPTHREAD} in DPADD and -lpthread in LDADD should
work. If it doesn't work, we will fix it.
> 1. force lib/libpthread install libkse.* to /usr/lib, and symlink
> to /lib/libpthread.*. I don't know KEYWORD to symlink to /lib/
> libpthread.* from libkse.*/libthr.*.
>
I don't see a reason for this; yet, this is a bad idea because binaries
will record libkse.so.X in them.
> 2. Fix like following in usr.bin/Makefile and usr.sbin/Makefile:
> .if ${MK_LIBPTHREAD} != "no"
> .....
> :
>
> to
>
> .if ${MK_LIBPTHREAD} != "no" || ${MK_LIBTHR} != "no"
>
Yes.
> .....
> :
> And compile force lib/libpthread.
>
Like I said, I fail to see a reason for this.
> And in case of
> MK_LIBPTHREAD=no, symlink libthr.* to libpthread.*.
>
This is what my patch to libthr/Makefile does. BTW, I'm testing
the attached patch now that should fix issues you mentioned.