It seems that GNU configure looks for the internal symbol

  extern int _nl_msg_cat_cntr;

to see whether or not libintl has the GNU gettext or not - should that
symbol be added to our libintl to fool it? (..and why not..)

If anyone cares (don't have pkgsrc handy to check) about make-3.79.1:

--- configure.orig	Mon Dec 25 12:20:15 2000
+++ configure	Mon Dec 25 13:13:08 2000
@@ -2528,7 +2528,7 @@
     # Check whether --with-included-gettext or --without-included-gettext was given.
 if test "${with_included_gettext+set}" = set; then
   withval="$with_included_gettext"
-  with_included_gettext=yes
+  with_included_gettext=$withval
 else
   with_included_gettext=maybe
 fi
@@ -2688,6 +2688,8 @@
   pds_cv_system_gnu_gettext=no
 fi
 rm -f conftest*
+# XXX to ignore the above test for an internal symbol:
+pds_cv_system_gnu_gettext=yes
 fi
 
 echo "$ac_t""$pds_cv_system_gnu_gettext" 1>&6

The first part of the patch is an error in configure - it sets
--without-included-gettext == --with-included-gettext
The second is to avoid the _nl_msg_cat_cntr check

--- getopt.c.orig	Mon Dec 25 12:35:45 2000
+++ getopt.c	Mon Dec 25 13:43:38 2000
@@ -79,9 +79,13 @@
 # endif
 #endif
 
+#ifdef HAVE_GETTEXT
+# include <libintl.h>
+#else
 /* This is for other GNU distributions with internationalized messages.
    When compiling libc, the _ macro is predefined.  */
-#include "gettext.h"
+# include "gettext.h"
+#endif
 #define _(msgid)    gettext (msgid)
 
 

and this last patch "works for me", but I'm not convinced that gettext() is
always defined in libintl..

and just to show that it works:

/usr/local/bin/gmake:
         -lutil.5 => /usr/lib/libutil.so.5
         -lkvm.5 => /usr/lib/libkvm.so.5
         -lintl.0 => /usr/lib/libintl.so.0
         -lc.12 => /usr/lib/libc.so.12
% env LANGUAGE=fr gmake foo
gmake: *** Pas de règle pour fabriquer la cible `foo'. Arrêt.

(Ca marche!)

(bison 1.28 fails to find dcgettext as it doesn't -lintl even though it
knows to look for gettext in -lintl)

Joyeux Noel,

Patrick