Monday 15 August 2005 11:08 am, Patrick Gerken wrote:
What happens is that, the moc compiler makes a header file which has an
include lice this:

#include <thread/somelib.h>
I tried to understand what is going on, and it seems moc is getting started
with all the compiler flags like CPPFLAGS and stuff, and these include
-pthread.
It seems that this gets defined in kde-admin, but this is a wild
guess,which I am not sure about.

Ah! That would explain this same problem:

I don't have a solution, but in my case, this hunk of code in configure.in.in
inserts "-pthread" into GST_CFLAGS, which is then referenced in the INCLUDES
section of Makefile.am. (BTW, multimedia/juk/configure.in.in has the same
code):

have_gst=no
if test "x$with_gstreamer" != xno; then
# pkg-config seems to have a bug where it masks needed -L entries when it
# shouldn't, so disable that.

PKG_CNFIG_ALLW_SYSTEM_LIBS=1
export PKG_CNFIG_ALLW_SYSTEM_LIBS

dnl start with 0.8
GST_MAJRMINR=0.8
dnl Actually need 0.8.7, but plugins were version 0.8.5. argh!
GST_REQ=0.8.5

PKG_CHECK_MDULES(GST, \
gstreamer-$GST_MAJRMINR >= $GST_REQ \
gstreamer-control-$GST_MAJRMINR >= $GST_REQ \
gstreamer-libs-$GST_MAJRMINR >= $GST_REQ,
have_gst=yes, have_gst=no)

if test "x$with_gstreamer" != xcheck && test "x$have_gst" != xyes; then
AC_MSG_ERRR([ was given, but test for GStreamer >= 0.8.5
failed])
fi
fi

if test "x$have_gst" = "xno"; then
GST_CFLAGS=""
LDADD_GST=""
LDFLAGS_GST=""
AC_DEFINE(HAVE_GSTREAMER, 0, [have GStreamer])
else
LDADD_GST=`$PKG_CNFIG gstreamer-$GST_MAJRMINR`
LDFLAGS_GST=`$PKG_CNFIG gstreamer-$GST_MAJRMINR`

# Append -L entries, since they are masked by and
#
LIBDIRS_GST=`$PKG_CNFIG gstreamer-$GST_MAJRMINR`
LDADD_GST="$LDADD_GST $LIBDIRS_GST"

AC_MSG_NTICE([GStreamer version >= $GST_REQ found.])
AC_DEFINE(HAVE_GSTREAMER, 1, [have GStreamer])

if test "x$with_gstreamer" != xcheck && test "x$have_gst" != xyes; then
AC_MSG_ERRR([ was given, but test for GStreamer >= 0.8.7
failed])
fi
fi

AC_SUBST(GST_CFLAGS)
AC_SUBST(LDADD_GST)
AC_SUBST(LDFLAGS_GST)

Monday 15 August 2005 06:04 pm, Gary Cramblitt wrote:
Ah! That would explain this same problem:

I don't have a solution, but in my case, this hunk of code in
configure.in.in inserts "-pthread" into GST_CFLAGS, which is then
referenced in the INCLUDES section of Makefile.am. (BTW,
multimedia/juk/configure.in.in has the same code):

I was able to work around the problem in my configure.in.in.

The attached patch is possibly a more general fix, allowing scripts to use
either "pkg-config " or "pkg-config ". The latter
does not include the "-pthread". But I'm no automake/autoconf expert.

Monday 15 August 2005 09:39 pm, Michael Pyne wrote:
Monday 15 August 2005 21:22, Gary Cramblitt wrote:
Monday 15 August 2005 06:04 pm, Gary Cramblitt wrote:
Ah! That would explain this same problem:

I was able to work around the problem in my configure.in.in.

The attached patch is possibly a more general fix, allowing scripts to
use either "pkg-config " or "pkg-config ". The
latter does not include the "-pthread". But I'm no automake/autoconf
expert.

Well if the -pthread was actually needed in the gcc command line then we
will have problems. We need to find out why the CFLAGS/CXXFLAGS are being
passed to moc. If it's because moc needs the include paths, then we need
to run pkg-config , but only for moc (and similar tools).

The difference seems to be the following. In my
, there's this line:

s,@MC@,/,;t t

but in

s,@MC@,/ $(AM_CPPFLAGS) $(CPPFLAGS)
$(KDE_CPPFLAGS) $(INCLUDES),;t t

So, by including (in my case) GST_CFLAGS in my INCLUDES variable in
Makefile.am, I send the -pthread to moc. With my patch, I would include
GST_IFLAGS rather than GST_CFLAGS.

Perhaps a better fix would be for unsermake to filter out "-pthread" from
INCLUDES before adding them to the MC symbol.

Monday 15 August 2005 09:55 pm, Gary Cramblitt wrote:
In my
, there's this line:
s,@MC@,/,;t t
but in
s,@MC@,/ $(AM_CPPFLAGS)
$(CPPFLAGS) $(KDE_CPPFLAGS) $(INCLUDES),;t t
Make those file names config.status.

Tuesday 16 August 2005 04.00, Gary Cramblitt wrote:
Monday 15 August 2005 09:55 pm, Gary Cramblitt wrote:
In my
, there's this line:

s,@MC@,/,;t t

but in

s,@MC@,/ $(AM_CPPFLAGS)
$(CPPFLAGS) $(KDE_CPPFLAGS) $(INCLUDES),;t t

Make those file names config.status.

I got this on my first build too, and it went away on my second: The only
difference, I did builddir != srcdir on the first, and not on the second (I
can reproduce using kdesvn-build, kde-build, and doing it by hand, but only
if I build to a separate directory.

Weird it is, indeed.

Regards,

Tuesday 16 August 2005 08:58 am, Lauri Watts wrote:
I got this on my first build too, and it went away on my second: The only
difference, I did builddir != srcdir on the first, and not on the second
That doesn't make any difference in my case, but I don't use svnbuild.

Monday 15 August 2005 11:08 am, Patrick Gerken wrote:
I tried to understand what is going on, and it seems moc is getting started
with all the compiler flags like CPPFLAGS and stuff, and these include
-pthread.

I started to make a patch to admin/acinclude.m4.in to filter out "-pthread"
from the $INCLUDES when building the MC symbol. But comparing the Qt4 moc
code and gcc manpages, the following are also potential option conflicts
similar to -pthread:

moc option gcc option
-ppath -pthread
-ppath -pthreads
-ppath -pedantic
-ppath -pedantic-errors
-ppath -p
-ppath -pg
-ppath -print-file-name=library
-ppath -print-libgcc-file-name
-ppath -print-multi-directory
-ppath -print-multi-lib
-ppath -print-prog-name=program
-ppath -print-search-dirs
-ppath -pagezero_size darwin
-ppath -prebind darwin
-ppath -prebind_all_twolevel_modules darwin
-ppath -private_bundle darwin
-ppath -pass-exit-codes
-ppath -pipe
-f -foption
-i -idirafter dir
-i -iinclude file
-i -imacros file
-i -iprefix file
-i -iwithprefix dir
-i -iwithprefixbefore dir
-i -isystem dir
-i -image_base darwin
-i -init darwin
-i -install_name darwin
-v -v
-E -EL
-E -EB
-Ipath -I (search working dir)
-n -no-integrated-cpp
-n -nostdinc++
-n -nostdinc
-n -nostartfiles
-n -nodefaultlibs
-n -nostdlib
-n -noall_load darwin
-n -nomultidefs darwin
-n -noprebind darwin
-n -noseglinkedit darwin
-n -nocpp MIPS
-n -nolibdld HPPA
-h -headerpad_max_install_names

Given the large number of potential conflicts, I'm wondering why the flags
were added to the MC symbol for KDE4? This wasn't done in KDE3.

Here's the code in KDE4 version of acinclude.m4.in:

KDE_FIND_PATH(moc, MC_PATH, [$qt_bindirs], [KDE_MC_ERRR_MESSAGE])
MC="$MC_PATH \$(AM_CPPFLAGS) \$(CPPFLAGS) \$(KDE_CPPFLAGS) \$(INCLUDES)"

and in KDE3 version:

KDE_FIND_PATH(moc, MC, [$qt_bindirs], [KDE_MC_ERRR_MESSAGE])

According to websvn, the additional line was added here:

Revision 440074 - (view) (download) - [select for diffs]
Modified Fri Jul 29 18:58:31 2005 UTC (2 weeks, 4 days ago) by coolo
File length: 151235 byte(s)
Diff to previous 439784
merge kde4 into trunk even for kde-common

which I suppose means the change occured while the file was in
branches/work/kde4, but I couldn't find the history there.