Failed to build kdesupport2 port
Hi folks...
I am on a FreeBSD 5.0-20010210-CURRENT box. This is a clean system, I
installed it from current.freebsd.org
I tried to build kdesupport2 port, but it failed. Somehow, when checking
for Qt, kdesupport2 configure script died. However, I installed qt 2.2.4
from port cleanly, no errors whatsoever.
My version of /usr/src/contrib/gcc.295/config/freebsd.h is
v 1.32 2001/02/08 05:27:17
BTW the only different file from my system is that I applied this
patch from Maxim Sobolev to /usr/port/Mk/bsd.port.mk:
--- bsd.port.mk 2001/02/08 19:09:54 1.2
+++ bsd.port.mk 2001/02/08 19:15:50
@@ -948,6 +948,14 @@
MAKEFILE?= Makefile
MAKE_ENV+= PREFIX=${PREFIX} LOCALBASE=${LOCALBASE} X11BASE=${X11BAS
E} MOTIFLIB="${MOTIFLIB}" LIBDIR="${LIBDIR}" CFLAGS="${CFLAGS}" CXXFLAGS="${CXXF
LAGS}"
+.if ${OSVERSION} 50
+PTHREAD_CFLAGS=-D_THREAD_SAFE
+PTHREAD_LIBS= "-pthread"
+.else
+PTHREAD_CFLAGS=""
+PTHREAD_LIBS= "-lc_r"
+.endif
+
.if exists(/usr/bin/fetch)
# avoid -A for 2.2 -- it's not ported to that branch
.if ${OSVERSION} 30
Attached is the failure log of my kdesupport2 build.
Am I the only one having this problem?
Thanks...
/john
Script started on Thu Feb 15 11:01:48 2001
[root@dante kdesupport2]# make install
=== Extracting for kdesupport-2.0.1
Checksum OK for kdesupport-2.0.1.tar.bz2.
=== kdesupport-2.0.1 depends on executable: bzip2 - found
=== kdesupport-2.0.1 depends on executable: gmake - found
=== kdesupport-2.0.1 depends on shared library: png.4 - found
=== kdesupport-2.0.1 depends on shared library: jpeg.9 - found
=== kdesupport-2.0.1 depends on shared library: qt2.4 - found
=== Patching for kdesupport-2.0.1
=== Applying FreeBSD patches for kdesupport-2.0.1
=== Configuring for kdesupport-2.0.1
/usr/bin/perl -pi -e "s@TOPSUBDIRS libaps@TOPSUBDIRS@g ; s@odbc libaps@odbc@g"
/usr/ports/converters/kdesupport2/work/kdesupport-2.0.1/configure
/usr/bin/perl -pi -e "s@-version-info 1:1@-version-info 3:0@g"
/usr/ports/converters/kdesupport2/work/kdesupport-2.0.1/mimelib/Makefile.in
creating cache ./config.cache
checking host system type... i386--freebsd5.0
checking target system type... i386--freebsd5.0
checking build system type... i386--freebsd5.0
checking for a BSD compatible install... /usr/bin/install -c -o root -g wheel
checking whether build environment is sane... yes
checking whether gmake sets ${MAKE}... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking for a C-Compiler... cc
checking whether the C compiler (cc -O -pipe -mcpu=i686 -march=i686 ) works... yes
checking whether the C compiler (cc -O -pipe -mcpu=i686 -march=i686 ) is a
cross-compiler... no
checking whether we are using GNU C... yes
checking how to run the C preprocessor... cc -E
checking for a C++-Compiler... c++
checking whether the C++ compiler (c++ -O -pipe -mcpu=i686 -march=i686 ) works... yes
checking whether the C++ compiler (c++ -O -pipe -mcpu=i686 -march=i686 ) is a
cross-compiler... no
checking whether we are using GNU C++... yes
checking whether c++ supports -fno-exceptions... yes
checking whether c++ supports -fno-check-new... yes
checking whether c++ supports -Wno-long-long... yes
checking whether c++ supports -fno-builtin... yes
checking whether c++ supports -fexceptions... yes
checking whether c++ supports -frtti... yes
checking how to run the C++ preprocessor... c++ -E
checking whether c++ supports -frepo... yes
checking for ld used by GCC... /usr/libexec/elf/ld
checking if the linker (/usr/libexec/elf/ld) is GNU ld... yes
checking for /usr/libexec/elf/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
checking how to recognise dependant libraries... pass_all
checking for ranlib... ranlib
checking for strip... strip
checking for Cygwin environment... no
checking for mingw32 environment... no
updating cache ./config.cache
loading cache ./config.cache within ltconfig
checking whether -lc should be explicitly linked in... yes
checking for objdir... .libs
checking for cc option to produce PIC... -fPIC -DPIC
checking if cc PIC flag -fPIC -DPIC works... yes
checking if cc static flag -static works... yes
checking if cc supports -c -o file.o... yes
checking if cc supports -fno-rtti -fno-exceptions ... yes
checking whether the linker (/usr/libexec/elf/ld) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... freebsd5.0 ld.so
checking command to parse /usr/bin/nm -B output... ok
checking if libtool supports shared libraries... yes
checking whether to build shared lib
-lc_r against shared library (Re: Failed to build kdesupport2 port)
If you paid attention to -ports, you found adding CONFIGURE_ARGS= "LIBS=-pthread" to kdesupport2/Makefile would help. There are some way to ``fix'' this problem: a) linking -lc_r against libGL. This is denied by John Polstra and he suggested (b). He said libc and libc_r must be strictly synchronized. If so, this might be a bad idea. b) adding -pthread to each port which uses libGL. This method needs some work but if this is the way to go, we should start fixing broken ports. So many ports are broken with -pthread now. c) Use -lc_r instead of -pthread. As -pthread will be depreciated, we should use -lc_r for FreeBSD 5.0 and later, shouldn't we? d) [Please add your opinions] -- FUJISHIMA Satsuki To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -lc_r against shared library (Re: Failed to build kdesupport2 port)
FUJISHIMA Satsuki wrote: If you paid attention to -ports, you found adding CONFIGURE_ARGS= "LIBS=-pthread" to kdesupport2/Makefile would help. There are some way to ``fix'' this problem: c) Use -lc_r instead of -pthread. As -pthread will be depreciated, we should use -lc_r for FreeBSD 5.0 and later, shouldn't we? Yes, it looks like a most appropriate solution to me. If you read -ports, recently I proposed to add a small patch for the bsd.port.mk to help with transition process, but have not heard anything back from PW yet. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -lc_r against shared library (Re: Failed to build kdesupport2 port)
On Thu, Feb 15, 2001 at 02:51:51PM +0200, Maxim Sobolev wrote:
CONFIGURE_ARGS= "LIBS=-pthread"
to kdesupport2/Makefile would help.
There are some way to ``fix'' this problem:
c) Use -lc_r instead of -pthread.
As -pthread will be depreciated, we should use -lc_r for FreeBSD
5.0 and later, shouldn't we?
Yes, it looks like a most appropriate solution to me. If you read -ports,
recently I proposed to add a small patch for the bsd.port.mk to help with
transition process, but have not heard anything back from PW yet.
Either I do it the wrong way, or you are not paying attention to my
first message thoroughly. I HAVE applied your patch to my
/usr/ports/Mk/bsd.port.mk! But still, I failed to build kdesupport2
So, here's the summary of what I have done:
1. Reformat hard drive (cause I have a broken -CURRENT caused by FILE struct
changes)
2. Install from current.freebsd.org a -CURRENT snapshot of 2210
3. cvsup the latest ports tree
4. Applied Maxim Sobolev patch against my /usr/ports/Mk/bsd.port.mk
The patch is:
--- bsd.port.mk 2001/02/08 19:09:54 1.2
+++ bsd.port.mk 2001/02/08 19:15:50
@@ -948,6 +948,14 @@
MAKEFILE?= Makefile
MAKE_ENV+= PREFIX=${PREFIX} LOCALBASE=${LOCALBASE} X11BASE=${X11BASE}
MOTIFLIB="${MOTIFLIB}" LIBDIR="${LIBDIR}" CFLAGS="${CFLAGS}" CXXFLAGS="${CXXFLAGS}"
+.if ${OSVERSION} 50
+PTHREAD_CFLAGS=-D_THREAD_SAFE
+PTHREAD_LIBS= "-pthread"
+.else
+PTHREAD_CFLAGS=""
+PTHREAD_LIBS= "-lc_r"
+.endif
+
.if exists(/usr/bin/fetch)
# avoid -A for 2.2 -- it's not ported to that branch
.if ${OSVERSION} 30
Correct isn't it?
5. Start building my ports
6. Everything from XFree86-4.0.2_6 to qt-2.2.4 build and installed just fine
7. kdesupport2 started bombing error messages
So, if after all of this I SHOULD have not undergone any errors, then the
mistakes is on me, please forgive me for wasting your time and bandwith.
I am only seeking for some enlightenment.
-Maxim
/john
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: -lc_r against shared library (Re: Failed to build kdesupport2 port)
John Indra wrote:
On Thu, Feb 15, 2001 at 02:51:51PM +0200, Maxim Sobolev wrote:
CONFIGURE_ARGS= "LIBS=-pthread"
to kdesupport2/Makefile would help.
There are some way to ``fix'' this problem:
c) Use -lc_r instead of -pthread.
As -pthread will be depreciated, we should use -lc_r for FreeBSD
5.0 and later, shouldn't we?
Yes, it looks like a most appropriate solution to me. If you read -ports,
recently I proposed to add a small patch for the bsd.port.mk to help with
transition process, but have not heard anything back from PW yet.
Either I do it the wrong way, or you are not paying attention to my
first message thoroughly. I HAVE applied your patch to my
/usr/ports/Mk/bsd.port.mk! But still, I failed to build kdesupport2
So, here's the summary of what I have done:
1. Reformat hard drive (cause I have a broken -CURRENT caused by FILE struct
changes)
2. Install from current.freebsd.org a -CURRENT snapshot of 2210
3. cvsup the latest ports tree
4. Applied Maxim Sobolev patch against my /usr/ports/Mk/bsd.port.mk
The patch is:
--- bsd.port.mk 2001/02/08 19:09:54 1.2
+++ bsd.port.mk 2001/02/08 19:15:50
@@ -948,6 +948,14 @@
MAKEFILE?= Makefile
MAKE_ENV+= PREFIX=${PREFIX} LOCALBASE=${LOCALBASE} X11BASE=${X11BASE}
MOTIFLIB="${MOTIFLIB}" LIBDIR="${LIBDIR}" CFLAGS="${CFLAGS}" CXXFLAGS="${CXXFLAGS}"
+.if ${OSVERSION} 50
+PTHREAD_CFLAGS=-D_THREAD_SAFE
+PTHREAD_LIBS= "-pthread"
+.else
+PTHREAD_CFLAGS=""
+PTHREAD_LIBS= "-lc_r"
+.endif
+
.if exists(/usr/bin/fetch)
# avoid -A for 2.2 -- it's not ported to that branch
.if ${OSVERSION} 30
Correct isn't it?
5. Start building my ports
6. Everything from XFree86-4.0.2_6 to qt-2.2.4 build and installed just fine
7. kdesupport2 started bombing error messages
So, if after all of this I SHOULD have not undergone any errors, then the
mistakes is on me, please forgive me for wasting your time and bandwith.
I am only seeking for some enlightenment.
You have totally misunderstood the purpose of my patch. The patch *isn't* intended as
a quick fix for the recent -lc_r/-pthread weirdness, but instead it would provide
porting team with infrastructure necessary to start converting existing ports to the
new world order. In a nutshell, -pthread should be replaced with ${PTHREAD_LIBS} and
-D_THREAD_SAFE with ${PTHREAD_CFLAGS} in all Makefiles from the ports collection. In
addition all places where -pthread hardcoded in patches should also be identified and
adjusted to respect ${PTHREAD_LIBS} and ${PTHREAD_CFLAGS}.
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: -lc_r against shared library (Re: Failed to build kdesupport2 port)
[ CC list trimmed ]
On Thu, 15 Feb 2001, Maxim Sobolev wrote:
You have totally misunderstood the purpose of my patch. The patch *isn't* intended
as a quick fix for the recent -lc_r/-pthread weirdness, but instead it would provide
porting team with infrastructure necessary to start converting existing ports to the
new world order. In a nutshell, -pthread should be replaced with ${PTHREAD_LIBS} and
-D_THREAD_SAFE with ${PTHREAD_CFLAGS} in all Makefiles from the ports collection. In
addition all places where -pthread hardcoded in patches should also be identified and
adjusted to respect ${PTHREAD_LIBS} and ${PTHREAD_CFLAGS}.
I support the addition of PTHREAD_CFLAGS/PTHREAD_LIBS to bsd.port.mk. It
allows one to specify exactly which threads library they want to use
(build against), even linuxthreads I would think.
If it matters, I think we've decided to keep the -pthread linker
option until FreeBSD gets its own libpthread at which point -pthread
will be deprecated. So there's no urgent rush to convert ports
to use the new mechanism if it's adopted.
--
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: -lc_r against shared library (Re: Failed to build kdesupport2 port)
Daniel Eischen wrote:
[ CC list trimmed ]
On Thu, 15 Feb 2001, Maxim Sobolev wrote:
You have totally misunderstood the purpose of my patch. The patch *isn't* intended
as a quick fix for the recent -lc_r/-pthread weirdness, but instead it would provide
porting team with infrastructure necessary to start converting existing ports to
the new world order. In a nutshell, -pthread should be replaced with ${PTHREAD_LIBS}
and
-D_THREAD_SAFE with ${PTHREAD_CFLAGS} in all Makefiles from the ports collection.
In addition all places where -pthread hardcoded in patches should also be identified
and
adjusted to respect ${PTHREAD_LIBS} and ${PTHREAD_CFLAGS}.
I support the addition of PTHREAD_CFLAGS/PTHREAD_LIBS to bsd.port.mk. It
allows one to specify exactly which threads library they want to use
(build against), even linuxthreads I would think.
If it matters, I think we've decided to keep the -pthread linker
option until FreeBSD gets its own libpthread at which point -pthread
will be deprecated. So there's no urgent rush to convert ports
to use the new mechanism if it's adopted.
You are not quite right (unfortunately). The current behaviour or -pthread breaks lots
of ports because by default gcc doesn't link shared modules with -lc_r even with this
flag, thus requiring that you to explicitly specify -pthread or -lc_r when linking
program with shared library that uses pthreads. Good example of such breakage is libGL
from
XFree86-4. This library requires pthreads, but most programs that use this library
don't use threads and as such have no idea why they need -pthread to link with libGL.
Therefore we have several choices:
1. Fix bazillion GL ports and ports with similar breakage by explicitly adding
-pthread into each one (poor choice IMO);
2. Make -pthread flag link shared modules with -lc_r (jdp is against this for not very
clear to me reasons);
3. Use -lc_r instead of -pthread in all threaded ports, which is equivalent to 2, BTW,
but jdp have no control over this.
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
