Date: Sat, 23 Dec 2000 00:21:27 -0800 From: Jeremy Lea <reg@FreeBSD.ORG> To: Will Andrews <will@physics.purdue.edu> Cc: Anarcat <beaupran@IRO.UMontreal.CA>, freebsd-ports@FreeBSD.ORG Subject: Re: Porting ecasound suite to FreeBSD Message-ID: <20001223002127.B395@shale.csir.co.za> In-Reply-To: <20001223011305.U328@argon.firepipe.net>; from will@physics.purdue.edu on Sat, Dec 23, 2000 at 01:13:05AM -0500 References: <87puilbdwu.wl@localhost.anarcat.yi.org> <20001221224539.J328@argon.firepipe.net> <874rzwidpz.wl@localhost.anarcat.yi.org> <20001223011305.U328@argon.firepipe.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
On Sat, Dec 23, 2000 at 01:13:05AM -0500, Will Andrews wrote:
> On Fri, Dec 22, 2000 at 12:10:32PM -0500, Anarcat wrote:
> > Humm.. I agree. But FreeBSD way is kinda strange. Why doesn't it use
> > the '-lpthread' syntax? Autoconf has "problems" detecting libs that
> > are not link with -l<libname>. Actually, it's more a problem of not
> > having the good macro available..
>
> I don't really know why it does it that way. You'll have to ask Jason
> Evans, the pthread (libc_r) maintainer. I've never really understood
> why pthread was put in a library called "c_r" instead of "pthread",
> among a few other things.
Because on Linux you link with libpthread AND libc, while on FreeBSD you
link with libc_r OR libc. Linux's pthreads are also 'kernel threads',
meaning that each thread runs as a seperate scheduling entity,
while FreeBSD's are user level threads. There are also kthreads on
FreeBSD which are kernel threads. At the moment user level programs
can't start kthreads IIRC, but at some point in SMPNG, libc_r will be
able to make kthreads to match the pthreads...
When you link a C program, the compiler implictly assumes that you need
to link against libc.so.?, libgcc.a and some crt?.o files (which contain the
setup for main() and other things). When you link with the '-pthread'
flag, these assumptions are changed to libc_r and libgcc_r. When you
link with the '-nostdlib' option you will not get these at all - like
for the kernel or the boot loader.
The other difference between Linux and FreeBSD is that with Linux you
must define _REENTRANT when compiling C/C++ code, to get the correct
magic out of the headers. On FreeBSD you should define _THREAD_SAFE.
(Although, some of the math headers use _REENTRANT, and I never figured
out why that was...). Passsing the '-pthread' flag to gcc/g++ while it
is compiling does not result in _THREAD_SAFE being defined for you (and
is effectively a no-op).
> > I know it's there. The problem occurs upon link.
>
> It would be nice to see the exact error.
If you link with -pthread and -lc, or -lc_r and -lc, or one of the
libraries you are using was ever explictly linked with -lc, then you
will get a funny looking block of about 7 lines of non fatal warnings
from the linker. None of these warnings are anything to do with
pthreads...
> > Well-well-well.. It seems you're right! I have no idea how their
> > libtool stuff works, in fact, I know *nothing* about libtool. One
> > thing I know though... libtool is installed on my system
> > (/usr/local/bin/libtool) and the makefiles are usings the package's
> > libtool! And this one adds annoying -lc and -lc_r libs!
> >
> > Fixed.
>
> Yeah, libtool is pretty stupid when it comes to FreeBSD. Thankfully,
> this problem is not usually caused by libtool. Sometimes it is,
> usually not.
Libtool began life as a simple tool which knew the right magic to linked
shared libraries on various platforms, with the same set of commands.
Along the line it grew 10,000 lines of shell scripting which tries to
second guess the dynamic linker, and you still have to do most of the
work yourself. Libtool is evil.
The libtool in the port's collection is a special animal (like an ox is
a special version of a bull ;-). It installs /usr/local/bin/libtool,
but the only time this is used is to check it's version number in
bsd.port.mk, to see if the installed port is the latest version...
Port's always use their own libtool, which is custom built during
configure, from ltmain.sh, and ltconfig. When USE_LIBTOOL is defined
in a port's Makefile, sed is run on the configure script, causing it to
use the ltmain.sh and ltconfig installed in /usr/local/share/libtool,
rather than it's versions. As a result the libtool it builds (which
ends up in ${WRKSRC}, has a bunch of hacks. Most of these prevent
libtool from trying to second guess our linker, some fix incorrect ideas
on the part of the libtool maintainers about how FreeBSD works, and the
grossest prevents libtool from polluting the world with .la files, which
are supposed to contain information for linking, but they've never
worked...
Regards,
-Jeremy
--
FreeBSD - Because the best things in life are free...
http://www.freebsd.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001223002127.B395>