Re: pkg/42265: devel/libdaemon build complains (and fails) with undefined libc symbols (NetBSD 4.0/i386)

[Joerg Sonnenberger]

The following reply was made to PR pkg/42265; it has been noted by GNATS.

From: Joerg Sonnenberger <joerg@...>
To: gnats-bugs@...
Cc:
Subject: Re: pkg/42265: devel/libdaemon build complains (and fails) with
 undefined libc symbols (NetBSD 4.0/i386)
Date: Wed, 4 Nov 2009 15:58:47 +0100

 On Wed, Nov 04, 2009 at 02:55:00PM +0000, kre@... wrote:
 > This doesn't appear to be something that pkgsrc is doing,
 > I get the same results if I build outside pkgsrc.
 
 gcc was changed somewhere in the 4.99 days to always link with -lc,
 before shared libraries have been linked without.
 
 Joerg
 

[Robert Elz]

The following reply was made to PR pkg/42265; it has been noted by GNATS.

From: Robert Elz <kre@...>
To: gnats-bugs@...
Cc:
Subject: Re: pkg/42265: devel/libdaemon build complains (and fails) with undefined libc symbols (NetBSD 4.0/i386)
Date: Wed, 04 Nov 2009 22:18:54 +0700

     Date:        Wed,  4 Nov 2009 15:00:06 +0000 (UTC)
     From:        Joerg Sonnenberger <joerg@...>
     Message-ID:  <20091104150006.A243B63B844@...>
 
   |  gcc was changed somewhere in the 4.99 days to always link with -lc,
   |  before shared libraries have been linked without.
 
 Ah, the missing piece - thanks - that explains why I am seeing
 what I am seeing, and perhaps suggests that either of the two
 possible fixes (removing the link option that causes the error,
 and so making the package essentially the same as the previous
 version, or adding -lc, and so making the NetBSD 4 package more
 like the NetBSD 5 (etc) versions), should work.
 
 Which is considered to be the preferred way?
 
 If I know which way pkgsrc would prefer, I can generate a patch that
 should fix this bug.
 
 kre
 

[Robert Elz]

The following reply was made to PR pkg/42265; it has been noted by GNATS.

From: Robert Elz <kre@...>
To: gnats-bugs@...
Cc:
Subject: Re: pkg/42265: devel/libdaemon build complains (and fails) with undefined libc symbols (NetBSD 4.0/i386)
Date: Mon, 09 Nov 2009 20:28:32 +0700

     Date:        Wed,  4 Nov 2009 15:25:01 +0000 (UTC)
     From:        Robert Elz <kre@...>
     Message-ID:  <20091104152501.D283663B844@...>
 
   |  If I know which way pkgsrc would prefer, I can generate a patch that
   |  should fix this bug.
 
 OK, no-one was able (or perhaps willing) to suggest whether it would be
 better to have the new version linked the same way the old one was, or
 whether it would be better to do it the new way, so I just decided that
 minimal risk was keeping things the way they have always been, and so
 made the appended patch which seems to allow me to both build libdaemon
 on NetBSD 4 again, and also to build those packages that depend upon it
 (as I type this, some of that is still happening, but there have been
 enough successfully completed for me to declare the patch below a success).
 
 That having been said, the patch below is almost certainly utter nonsense
 and nothing at all like the way it should be done, I rather doubt that
 pkgsrc Makefiles are intended to go explicitly setting LOWER_OPSYS_VERSUFFIX
 explicitly, and I have no idea at all what effect that will (would) have
 on anything that is not NetBSD, and perhaps even anything that is not
 NetBSD 4 (though I doubt other NetBSD versions would be adversely affected).
 
 The reason i did it this way, is that I needed to be able to patch the
 configure script to behave differently on NetBSD 4 from more recent NetBSDs.
 But the way pkgsrc runs configure, it passes an explicit --host arg, which
 does not include any version information for NetBSD - so other than
 making the configure script ignore the passed in system ID and just
 run "uname -r" internally (which would make this stuff even less likely to
 ever cross-compile than it is now) I thought a better fix would be to
 just get the version number added to the --host arg to configure, and
 defining LOWER_OPSYS_VERSUFFIX seems to make that happen.
 
 Protecting that assignment, so it only happens for NetBSD 4 would be a
 simple way to avoid problems on other systems, I didn't do that as I simply
 can't believe that this is even an approximation of the right way to
 handle this problem - the people who wonder why I often just report
 problems, and rarely supply fixes can now stop wondering, this is the
 quality you'd be getting if I did (I guess that someone will see this
 attempt at a fix, become violently ill, and then when they recover, will
 figure out a better way to solve the problem!)
 
 For me now, at least until libdaemon gets updated again, the problem
 appears to be solved...
 
 kre
 
 diff -u -r --unidirectional-new-file ../libdaemon/Makefile ./Makefile
 --- ../libdaemon/Makefile 2009-10-31 09:54:34.000000000 +0700
 +++ ./Makefile 2009-11-09 19:27:14.000000000 +0700
 @@ -18,6 +18,7 @@
  GNU_CONFIGURE= YES
 
  CONFIGURE_ARGS+= --disable-lynx
 +LOWER_OPSYS_VERSUFFIX!= uname -r | sed 's/\..*//'
 
  INSTALLATION_DIRS= share/doc/libdaemon
 
 diff -u -r --unidirectional-new-file ../libdaemon/distinfo ./distinfo
 --- ../libdaemon/distinfo 2009-10-31 09:54:34.000000000 +0700
 +++ ./distinfo 2009-11-09 17:53:18.000000000 +0700
 @@ -3,3 +3,4 @@
  SHA1 (libdaemon-0.14.tar.gz) = 78a4db58cf3a7a8906c35592434e37680ca83b8f
  RMD160 (libdaemon-0.14.tar.gz) = 952ae993fecfe3ec765dfa43b2690a83f1a5c939
  Size (libdaemon-0.14.tar.gz) = 340474 bytes
 +SHA1 (patch-aa) = 1b7a9cc2cae4d9aa19b135df93d18515bb290d7b
 diff -u -r --unidirectional-new-file ../libdaemon/patches/patch-aa ./patches/patch-aa
 --- ../libdaemon/patches/patch-aa 1970-01-01 07:00:00.000000000 +0700
 +++ ./patches/patch-aa 2009-11-09 17:53:11.000000000 +0700
 @@ -0,0 +1,16 @@
 +--- configure.REAL 2009-10-17 02:08:49.000000000 +0000
 ++++ configure 2009-11-09 10:48:45.000000000 +0000
 +@@ -14447,9 +14447,10 @@
 + ;;
 +   esac
 +
 +-
 +-
 +-
 ++# gcc on NetBSD 4 does not link with -lc, undefined symbols are expected
 ++case "$host" in
 ++*-netbsdelf4*) LDFLAGS_NOUNDEFINED="";;
 ++esac
 +
 +   # Check whether --enable-lynx was given.
 + if test "${enable_lynx+set}" = set; then
 
 

[wiz-2]

The following reply was made to PR pkg/42265; it has been noted by GNATS.

From: Thomas Klausner <wiz@...>
To: Robert Elz <kre@...>
Cc: NetBSD bugtracking <gnats-bugs@...>
Subject: Re: pkg/42265: devel/libdaemon build complains (and fails) with
 undefined libc symbols (NetBSD 4.0/i386)
Date: Tue, 10 Nov 2009 19:29:15 +0100

 On Mon, Nov 09, 2009 at 01:35:03PM +0000, Robert Elz wrote:
 >  OK, no-one was able (or perhaps willing) to suggest whether it would be
 >  better to have the new version linked the same way the old one was, or
 >  whether it would be better to do it the new way, so I just decided that
 >  minimal risk was keeping things the way they have always been, and so
 >  made the appended patch which seems to allow me to both build libdaemon
 >  on NetBSD 4 again, and also to build those packages that depend upon it
 >  (as I type this, some of that is still happening, but there have been
 >  enough successfully completed for me to declare the patch below a success).
 
 Perhaps upstream can come up with a fix that doesn't hurt anyone ;)
 Have you tried talking to them?
  Thomas
 

[Robert Elz]

The following reply was made to PR pkg/42265; it has been noted by GNATS.

From: Robert Elz <kre@...>
To: gnats-bugs@...
Cc:
Subject: Re: pkg/42265: devel/libdaemon build complains (and fails) with undefined libc symbols (NetBSD 4.0/i386)
Date: Wed, 11 Nov 2009 06:18:05 +0700

     Date:        Tue, 10 Nov 2009 18:30:05 +0000 (UTC)
     From:        Thomas Klausner <wiz@...>
     Message-ID:  <20091110183005.6A78A63B8CD@...>
 
   |  Perhaps upstream can come up with a fix that doesn't hurt anyone ;)
 
 For anyone being the world excluding libdaemon developers, just deleting
 the option that caused the problems is perfectly fine - the option changes
 nothing as long as the library doesn't grow new external symbols,
 which is only something a libdaemon developer would do.
 
   |  Have you tried talking to them?
 
 No, I only care about libdaemon to the extent that it is used by other
 packages, as far as I'm concerned, the problem is solved now.   As soon
 as Joerg mentioned the gcc change that explained why things alterd, it
 stopped even being very interesting...
 
 kre
 

[Joerg Sonnenberger]

The following reply was made to PR pkg/42265; it has been noted by GNATS.

From: Joerg Sonnenberger <joerg@...>
To: gnats-bugs@...
Cc:
Subject: Re: pkg/42265: devel/libdaemon build complains (and fails) with
 undefined libc symbols (NetBSD 4.0/i386)
Date: Wed, 11 Nov 2009 00:21:08 +0100

 On Tue, Nov 10, 2009 at 06:30:05PM +0000, Thomas Klausner wrote:
 >  Perhaps upstream can come up with a fix that doesn't hurt anyone ;)
 >  Have you tried talking to them?
 
 Just add -lc.
 
 Joerg
 

[Robert Elz]

The following reply was made to PR pkg/42265; it has been noted by GNATS.

From: Robert Elz <kre@...>
To: gnats-bugs@...
Cc:
Subject: Re: pkg/42265: devel/libdaemon build complains (and fails) with undefined libc symbols (NetBSD 4.0/i386)
Date: Wed, 11 Nov 2009 16:37:23 +0700

     Date:        Tue, 10 Nov 2009 23:25:02 +0000 (UTC)
     From:        Joerg Sonnenberger <joerg@...>
     Message-ID:  <20091110232502.09A2063B8CD@...>
 
   |  Just add -lc.
 
 That's the "make the NetBSD 4 package look like a NetBSD 5 version"
 alternative fix ...
 
 If that's the best way, then the appended (simpler) patch should
 handle that, libdaemon builds on NetBSD 4.0 with this patch, and the
 resulting package works OK to build at least one of the packages that
 use it (too lazy to go rebuild all of them...), so this looks fine to me.
 
 It may be worthwhile to only set LIBS when the OS is NetBSD 4* - I'll
 leave that for someone else to decide.
 
 kre
 
 diff -u -r ../libdaemon/Makefile ./Makefile
 --- ../libdaemon/Makefile 2009-10-31 09:54:34.000000000 +0700
 +++ ./Makefile 2009-11-11 16:28:07.000000000 +0700
 @@ -18,6 +18,7 @@
  GNU_CONFIGURE= YES
 
  CONFIGURE_ARGS+= --disable-lynx
 +LIBS=-lc
 
  INSTALLATION_DIRS= share/doc/libdaemon