Re: sasl build failure with db-4.3 and db-4.4

On Mon, 30 Oct 2006 10:54:47 -0800 (PST)
"David Carrel" <carrel <at> netbsd.org> wrote:

> I'm trying to build cyrus-sasl on a Fedora Core 5 system and I am getting
> a weird failure.  FC5 contains a native libdb-4.3 but pkgsrc has also
> built a libdb-4.4.  Other pkgsrc apps seem to only use the pkgsrc built
> libdb-4.4.  However cyrus-sasl is using a mix of both.  The build includes
> are only compiling with the pkgsrc 4.4 include file(s).  But for linking,
> some files are linked with -ldb-4.3 and some with -ldb-4.4.  In the end,
> using ldd to look at the installed binaries (ie.
> /usr/pkg/sbin/sasldblistusers2) shows they are linked to the native
> system's libdb-4.3 which doesn't work since everything was compiled
> against pkgsrc' db-4.4.
> 
> Other packages (such as postfix) are linking against the pkgsrc db-4.4 and
> working correctly.
> 
> Any ideas?

Attached patch solve your problem?

--
"Of course I love NetBSD"
OBATA Akio / obata <at> lins.jp

Index: Makefile
===================================================================
RCS file: /cvsroot/pkgsrc/security/cyrus-sasl/Makefile,v
retrieving revision 1.52

security/john doesn't use optimised build types

security/john has assembler versions of some of its functions which can be 
selected by specifying a different make target. It has a number of OpenBSD 
targets, but I don't see any reason why these shouldn't be the same for 
NetBSD (certainly the Makefile sections are the same for OpenBSD and 
FreeBSD). Therefore, we ought to add something like the following to 
Makefile:

--- Makefile.orig	2006-11-01 15:01:06.000000000 +0000
+++ Makefile	2006-11-01 15:01:06.000000000 +0000
 <at>  <at>  -29,6 +29,20  <at>  <at> 
  .  endif
  .elif ${OPSYS} == "SunOS" && ${MACHINE_ARCH} == "i386"
  BUILD_TARGET=	solaris-x86-any
+.elif ${OPSYS} == "NetBSD" || ${OPSYS} == "OpenBSD"
+.  if ${MACHINE_ARCH} == "i386"
+BUILD_TARGET=	openbsd-x86-any
+.  elif ${MACHINE_ARCH} == "sparc64"
+BUILD_TARGET=	openbsd-sparc64
+.  elif ${MACHINE_ARCH} == "sparc"
+BUILD_TARGET=	openbsd-sparc
+.  elif ${MACHINE_ARCH} == "alpha"
+BUILD_TARGET=	openbsd-alpha
+.  elif ${MACHINE_ARCH} == "powerpc"
+BUILD_TARGET=	openbsd-powerpc
+.  else
+BUILD_TARGET=	generic
+.  endif
  .else
  BUILD_TARGET=	generic
  .endif

pkgsrc math/gap and pkgtools/bootstrap-mk-files

Hello-

While installing GAP on i386 Darwin, the ${CC} variable is set in a way
that breaks GAP's installation.

	$ bmake -dvx install
	...
	Global:CC = gcc -pipe
	...
	/usr/bin/install -d -o root -g wheel -m 755
	/usr/pkg/lib/gap4.3/bin/i386-apple-darwin8-gcc -pipe
	/usr/bin/install -c -s -o root -g wheel -m 555 
	/Volumes/absolute-pkgsrc/pkgsrc/math/gap/work/gap4r3/bin/i386-apple-darwin8-gcc -pipe/gap 
	/usr/pkg/lib/gap4.3/bin/i386-apple-darwin8-gcc -pipe
	install:
	/Volumes/absolute-pkgsrc/pkgsrc/math/gap/work/gap4r3/bin/i386-apple-darwin8-gcc:
	Inappropriate file type or format
	*** Error code 71

The culprit is this part of the Makefile:

    31  GAP_PLATFORM=   ${MACHINE_GNU_PLATFORM}-${CC}
    32
    33  PLIST_SUBST+=   GAP_PLATFORM=${GAP_PLATFORM:Q}

A space in CC, and therefore GAP_PLATFORM, inserts a space in the
install command line, which attempts to install into a bogus directory,
and creates an empty directory math/gap/-pipe

'-pipe' is appended to CC by pkgtools/bootstrap-mk-files in

Re: pkgsrc math/gap and pkgtools/bootstrap-mk-files

On 2006-11-01 12:55 -0500, oliver gould wrote:

> 	--- share/mk/sys.mk	2006-10-18 17:17:20.000000000 -0400
> 	+++ /tmp/sys.mk		2006-11-01 12:34:57.000000000 -0500
> 	 <at>  <at>  -21,9 +21,11  <at>  <at> 
> 	 LINK.S?=	${CC} ${AFLAGS} ${CPPFLAGS} ${LDFLAGS}
> 	 
> 	 .if exists(/usr/bin/gcc)
> 	-CC?=		gcc -pipe
> 	+CC?=		gcc
> 	+CFLAGS+=	-pipe
> 	 .else
> 	-CC?=		cc -pipe
> 	+CC?=		cc
> 	+CFLAGS+=	-pipe
> 	 .endif
> 	 DBG?=		-O2
> 	 CFLAGS?=	${DBG}

Uh, oops.  I realized how braindead this patch was after sending it.  It
should be more like:

--- pkg/share/mk/sys.mk	2006-10-18 17:17:20.000000000 -0400
+++ /home/ogould/work/sys.mk	2006-11-01 13:07:03.000000000 -0500
 <at>  <at>  -21,12 +21,12  <at>  <at> 
 LINK.S?=	${CC} ${AFLAGS} ${CPPFLAGS} ${LDFLAGS}

 .if exists(/usr/bin/gcc)
-CC?=		gcc -pipe
+CC?=		gcc

RE: pkgsrc math/gap and pkgtools/bootstrap-mk-files

Can someone on the list with bootstrap kit knowledge and a Darwin setup look
at this please to see if this is a general error? Oliver: please would you
file a PR at http://www.netbsd.org/Misc/send-pr.html

> -----Original Message-----
> From: oliver gould [mailto:ogould <at> cs.stevens.edu]
> Sent: 01 November 2006 17:55
> To: cjep <at> netbsd.org
> Cc: pkgsrc-users <at> netbsd.org
> Subject: pkgsrc math/gap and pkgtools/bootstrap-mk-files
> 
> Hello-
> 
> While installing GAP on i386 Darwin, the ${CC} variable is set in a way
> that breaks GAP's installation.
> 
> 	$ bmake -dvx install
> 	...
> 	Global:CC = gcc -pipe
> 	...
> 	/usr/bin/install -d -o root -g wheel -m 755
> 	/usr/pkg/lib/gap4.3/bin/i386-apple-darwin8-gcc -pipe
> 	/usr/bin/install -c -s -o root -g wheel -m 555
> 	/Volumes/absolute-pkgsrc/pkgsrc/math/gap/work/gap4r3/bin/i386-apple-
> darwin8-gcc -pipe/gap
> 	/usr/pkg/lib/gap4.3/bin/i386-apple-darwin8-gcc -pipe
> 	install:
> 	/Volumes/absolute-pkgsrc/pkgsrc/math/gap/work/gap4r3/bin/i386-apple-
> darwin8-gcc:
> 	Inappropriate file type or format

Re: pkgsrc math/gap and pkgtools/bootstrap-mk-files

Chris Pinnock <cjep <at> fawlty.net> wrote:
> Can someone on the list with bootstrap kit knowledge and a Darwin setup look
> at this please to see if this is a general error? Oliver: please would you
> file a PR at http://www.netbsd.org/Misc/send-pr.html

Rui reported the same issue to me a few days ago.  I haven't had time to
look at it yet, but I'll try to make some time this weekend.

Oliver, if you file a PR, please send me the PR #.

-Jan

--

-- 
Of course it runs NetBSD!		http://www.netbsd.org

Problems with 2006Q3

Hi!

Where to start? Huh, ok, first-things-first. 

I did try to "bootstrap" pkgsrc 2006Q3 (tar archive on site), on Alpha Tru64 
5.1B. I tried using built-in make and cc compiler. It didn't go far - it 
broke on registering pax package which required patch. It downloads new 
version of patch, which requires digest, which requires patch. End.

In general, default "make" is broken. I installed GNU make using tachometer 
and rpm packages. I still encountered the same problem - while 
in "registering packages" phase, again it requested patch package and broke. 
I did try to bootstrap same "tar" archive on linux and it went without 
problems! Wierd.

I did try many different options (CC, CFLAGS, LDFLAGS ..) - nothing helped.

Finaly, did give up on "tar" archive and switch to cvs version (as recommended 
on site). This time, bootstrap went successufuly! The difference is that cvs 
version is missing some files in pkgtools/pax directory.

# ls -al pkgsrc.cvs/pkgtools/pax/
total 25
drwxr-xr-x   3 root     system      8192 Oct 26 18:34 .
drwxr-xr-x  50 root     system      8192 Oct 26 18:34 ..
drwxr-xr-x   2 root     system      8192 Oct 26 18:34 CVS
-rw-r--r--   1 root     system       592 Jul 14 22:11 Makefile
# ls -al pkgsrc/pkgtools/pax/
total 49

Re: x11/kdelibs3 compile problems on Solaris

On Wednesday 18 October 2006 17:19, Jake Kupersmith wrote:
> > Hi, I'm building x11/kdelibs3 with GCC-4.1.1 on Sparc Solaris.
> > Could anyone who knows C++ suggest how to fix the following
> > error:
>
> This patch fixes the problem for me..
>
> $ cat /pkgsrc/local-patches/x11/kdelibs3/kjs_operations_cpp
	[...]

So both of these suggest that HAVE_FUNC_ISINF is being defined but 
that isinf() doesn't exist so whats causing HAVE_FUNC_ISINF to be 
defined?

cheers
mark

Re: x11/kdelibs3 compile problems on Solaris

On Wed, Oct 18, 2006 at 12:19:34AM -0400, Jake Kupersmith wrote:
> >Hi, I'm building x11/kdelibs3 with GCC-4.1.1 on Sparc Solaris. Could 
> >anyone who
> >knows C++ suggest how to fix the following error:
> 
> This patch fixes the problem for me..

config.log?

Joerg

Re: Problems with 2006Q3

On Thursday 02 November 2006 09:53, Hrvoje Habjanić wrote:
[snip]
>
> Few patches follow.
>

1. wrapper-sink-osf1.patch 
Ld on Tru64 doesn't know what to do with "-h <soname>" flag, but it 
understands "-soname" flag. This patch "fix"es this.

2. wrapper-buildcmd.patch
This one is my favorite. In short, Tru64 doent't have strict policy to 
put "imported" libraries in /usr/local or something similar. They all end up 
in default places. This include libraries like libjpeg and libz. Of course, 
those installed in default location are some quite old versions, custom made, 
needed for normal os operation (gui administration tools). Of course, ld 
linker first searches default places, and then if it doesn't found library, 
it searches for it in directories listed in "-L" flags.
So, i needed a way to modify linker search order to succesufuly compile netpbm 
package. For Tru 64 ld, to disable default search path, one must include "-L" 
empty option on command line. Of course, wrapper libraries doesn't allow 
this - then concatenate anything that comes after "-L"<space>. Instead of 
complicating with regular expressions, i introduced new flag "-no-std-libs", 
which bypasses sink wrappers (and others). This, probably, can be done 
better, but it works for me - all that needs to be done is to put this flag 
in LDFLAGS directive in mk.conf.

3. mk.conf settings
Following needs to be "added" to mk.conf file:
CC=                             gcc