How to replace libpthread correctly on 7.0?
LukeD at pobox.com
Sun Mar 30 15:41:57 PDT 2008
On Sun, 30 Mar 2008, Luke Dean wrote:
> This weekend I upgraded a desktop system from 6.2 to 7-STABLE using source.
> I removed and rebuilt all my ports using the ports system, and so far I
> haven't noticed any problems with them.
> When I attempted to rebuild some software outside the ports system, I ran
> into problems. I like to use the Code::Blocks IDE. It's in the FreeBSD
> ports system, but it's lagging about three years behind what's current, so
> I've been tracking the current code from the project's subversion system. It
> was working on FreeBSD 6.2.
> When I attempted to rebuild Code::Blocks, the build failed with an error
> relating to libpthread.so.2. I didn't get rid of old libraries when I
> upgraded to 7, so I still had this old libpthread.so.2 that hadn't been
> rebuilt. I know. Bad. I searched the web a bit and discovered that
> libpthread had fallen out of favor in 7 and was being replaced by something
> else. Ok, fine, so I got rid of my old broken libpthread.so.2.
> I tried to rebuild Code::Blocks again, and found that it was still attempting
> to link to libpthread. I threw away all the code and configurations, fetched
> the latest code, ran "bootstrap", "configure", and "make" and it's STILL
> running g++ with the -pthread switch and complaining about a missing
> libpthread.so.2. It finally dies with an "undefined reference to
> `system at LIBTHREAD_1_0'
> Should I expect the new standard threading library ("libthr" I think?) to be
> a drop-in replacement for libpthread? If so, do you have any ideas where I
> need to look to convince this code to use it?
> For my personal projects, is the -pthread switch any good anymore, or is
> there a different switch I should be using now?
> Is libpthread even an option at all anymore? If so, how do I build it?
> I'm just not sure what direction I should start troubleshooting in now.
Never mind. It was my stupid mistake.
I thought that "make" was making all new executables and libraries, but in
fact it was pulling in an old library that was linked to libpthread.
If this had been in the ports system I would've run "make deinstall"
first and avoided this problem.
I removed the old library, which forced "make" to rebuild it and all was
The Porter's Handbook answered my question about the -pthread switch, I
I have to go through this every now and then just to remind myself why I
like the ports system so much.
More information about the freebsd-questions