Works for me, and works on build.g.o. I don't see how it could fail, given that the paste above shows that -pthread is part of the link command.

Seems to be triggered by the "-Wl,-z -Wl defs" link flag, which doesnt seem right, maybe its a toolchain bug

Does it happen only when compiled from git (./autogen.sh run locally) or also from tarball?

How about 0.42.x?

The 0-42 branch doesn't use that function. (The call was introduced during the pty-cleanup work.)

http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20160129160146.ovitters.valstar.10797/log/vte3-0.43.2-1.mga6/build.0.20160129160205.log

This is likely due to --as-needed usage. See above for Mageia build failure using 0.43.2 tarball.

Its caused by linking with "-Wl,-z, defs" not --as-needed.

However I tried with a very simple pthread C program and that linked fine with both "-Wl,-z, defs" and --as-needed enabled so long as -pthread is supplied.

my testing was with the 0.43.2 tarball, I can't build git master at the moment due to unrelated vala error about new api needing 0.44

Adding "-lpthread" to the linker command will solve this, but given pthread being "special" this is not something you want to do unconditionally for portability reasons or so....

There seems to be a plethora of ways of how to handle this in different projects.

I've tested borrowing the following from netatalk and verified it fixes the build here:

AC_SEARCH_LIBS(pthread_sigmask, pthread,,
               [AC_MSG_ERROR([cannot find pthread_sigmask in libc or libpthread])])
if test x"$ac_cv_search_pthread_sigmask" != x"none required" ; then
   PTHREAD_LIBS=$ac_cv_search_pthread_sigmask
fi
AC_SUBST(PTHREAD_LIBS)

LIBS="$LIBS $PTHREAD_LIBS"


See http://sources.debian.net/src/netatalk/2.2.5-1/configure.ac/?hl=88#L88

You might also want to check out AX_PTHREAD, but watch out for pitfalls as mentioned in mesa: 

"AX_PTHREADS leaves PTHREAD_LIBS empty for gcc..."

See http://sources.debian.net/src/mesa/11.1.2-1/configure.ac/?hl=713#L713

http://www.gnu.org/software/autoconf-archive/ax_pthread.html

The link line as shown in comment 0 already contains '-pthread' which according to g++ docs should do the right thing: "Adds support for multithreading with the "pthreads" library.  This option sets flags for both the preprocessor and linker."

(In reply to Christian Persch from comment #9)
> The link line as shown in comment 0 already contains '-pthread' which
> according to g++ docs should do the right thing: "Adds support for
> multithreading with the "pthreads" library.  This option sets flags for both
> the preprocessor and linker."

Yes, it does contain -pthread, but not -lpthread (which both are confusingly similar). "Should" do the right thing, sure maybe but apparently it doesn't and just about every other project in the universe seems to decide to fix this issue in similar ways to what I pointed out. It's up to you ofcourse.... it was just a suggestion. Trying to be helpful pointing out an actual working solution (that lets us still verify there are no unresolved symbols). Dropping "-Wl,-z, defs" is not a solution I consider a good one, but that's my opinion and you're free to ignore it.

You could do a build without extra flags, and one with your zdefs flag, and compare the build log and config.log files to see what exactly changes.

'-pthread' should cause '-lpthread' to be passed to the linker, however since libtool is calling 'g++ -nostdlib', that actually takes priority and causes the '-lpthread' to be stripped.

This seems to be a long standing issue that has never been dealt with upstream, so I guess explicitly setting '-lpthread' is the correct way to go.

For example there was this patch (but doesnt ever seem to have been accepted)
http://permalink.gmane.org/gmane.comp.gnu.libtool.patches/11704

I see. NOTGNOME since it's a libtool problem, and NOTABUG since it's caused by adding zdefs to the LD flags, so you can just as well add -lpthread too.

(In reply to Christian Persch from comment #13)
> I see. NOTGNOME since it's a libtool problem, and NOTABUG since it's caused
> by adding zdefs to the LD flags, so you can just as well add -lpthread too.

Just have to say (again) since everyone seems to misunderstand what -Wl,-z,defs does: the problem is not *caused* by this flag. That flag only makes it possible to *detect* underlinking issues like this one. Adding this flag is a way to detect, at link-time,  issues instead of experience them at runtime! (Which in this particular case might not be a big practical problem, but anyway if we drop it there might creep in other underlinking issues which is actually practical problems. But ofcourse we can handle all of this downstream if you prefer us not to bother you about this.)

(Also, apparently libtool people seems to disagree with you about this being a libtool issue.)

I've removed libtool use from git master, please check if the problem still occurs.

Actually that didn't work out, so I've reverted that for now.