[Bug-freedink] Re: intltool.m4 and FreeBSD (Was: FreeDink in FreeBSD)

[Stephen Hurd]

I've attached your previous emails and added address@hidden (the 
listed intltool maintainer) it looks suspiciously like a mailing list, 
but since I know nothing of m4 or intltool and you don't use FreeBSD, I 
don't think either of us can create a usefull bug report on this issue 
(I definitely can't since I don't understand the problem).

At the very least, I would expect an authorative answer from gnome@

For gnome@, this discussion is regarding the patch in 
games/freedink-dfarc apparently, $(DATADIRNAME) is "lib" in this case.

Sylvain Beucler wrote:
> Hi,
>
> On Mon, Dec 01, 2008 at 08:50:05PM -0800, Stephen Hurd wrote:
>   
> > Sylvain Beucler wrote:
> >     
> > > There's indeed something about it in /usr/share/aclocal/intltool.m4:
> > >
> > > Apparently it checks for '_nl_msg_cat_cntr' and doesn't find
> > > it. However this test isn't relevant here because DFArc uses
> > > wxWidget's i18n stack instead of directly using gettext.  It would
> > > worth checking if there are similar issues in other packages using
> > > wxWidgets.
> > >   
> > >       
> > Hrm... I wonder then if the intltool stuff is the "wrong" way do do it  
> > in configure and if there's some wx thing to use instead.  I have no  
> > auto-fu and don't know M4, so I'm going to just ignore this and hope it  
> > goes away.  :-)
> >     
>
> I did a quick search and I'm not sure that many packages use both
> intltool and wxWidgets!
>
> Some packages such as vlc use both the gettext M4 stuff and wxWidgets,
> but not intltool (they translate .desktop files manually). Other
> packages ship with libintl and maybe use it instead of Free/NetBSD's
> gettext.
>
> Anyway, the intltool M4 code essentially looks for _GNU_ gettext, and
> if it doesn't find it, it installs in /usr/lib, which apparently isn't
> standard for FreeBSD's gettext - so there's a bug in intltool (do you
> confirm?).
>
> Would you mind reporting this to
>   http://bugzilla.gnome.org/browse.cgi?product=intltool
> ? I used v0.40 to bootstrap './configure'.
>
>   

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: FreeDink in FreeBSD
>
>
>
>
> Date: 
>
> Mon, 01 Dec 2008 20:27:33 +0100
>
>
>
>
> User-agent: 
>
> Mutt/1.5.18 (2008-05-17)
>
>
>
>
> Hi,
>
> On Sun, Nov 30, 2008 at 06:49:36PM -0800, Stephen Hurd wrote:
> > Sylvain Beucler wrote:
> >>> and the itlocale change in the dfarc Makefile.in.in
> >>>     
> >>
> >> I didn't really understand this one :)
> >>
> >> Note that 'Makefile.in.in' is installed by 'intltoolize', so maybe the
> >> patch should go to the intltool project as well.
> >>   
> >
> > I don't either to be honest.  I just poked at it until it did what I  
> > wanted.  I *think* it was installing under lib rather than share, but I  
> > can't remember any more.  :-)
>
> There's indeed something about it in /usr/share/aclocal/intltool.m4:
>
>   # Set DATADIRNAME correctly if it is not set yet
>   # (copied from glib-gettext.m4)
>   if test -z "$DATADIRNAME"; then
>     AC_LINK_IFELSE(
>       [AC_LANG_PROGRAM([[]],
>                        [[extern int _nl_msg_cat_cntr;
>                          return _nl_msg_cat_cntr]])],
>       [DATADIRNAME=share],
>       [case $host in
>       *-*-solaris*)
>       dnl On Solaris, if bind_textdomain_codeset is in libc,
>       dnl GNU format message catalog is always supported,
>       dnl since both are added to the libc all together.
>       dnl Hence, we'd like to go with DATADIRNAME=share
>       dnl in this case.
>       AC_CHECK_FUNC(bind_textdomain_codeset,
>         [DATADIRNAME=share], [DATADIRNAME=lib])
>       ;;
>       *)
>       [DATADIRNAME=lib]
>       ;;
>       esac])
>   fi
>   AC_SUBST(DATADIRNAME)
>
> Apparently it checks for '_nl_msg_cat_cntr' and doesn't find
> it. However this test isn't relevant here because DFArc uses
> wxWidget's i18n stack instead of directly using gettext.  It would
> worth checking if there are similar issues in other packages using
> wxWidgets.
>
>
> > Hrm... I think the default install target strips executables as well...  
> > file shows it as stripped, how can I check if the embedded resources are  
> > there?
>
> Resources are essentially a .zip file appened to the executable (+
> some index relocation). Just 'unzip -l /usr/bin/freedink' :)
>
>
> >> Btw, your choice of options is actually the default :)
> >
> > Hah!  We all know that configure doesn't really have defaults, it has  
> > suggestions.  :-)
> >
> > If libzip isn't installed, embedded resources won't be used.
>
> Well configure does what tell him to :)
>
> In FreeDink I made sure that the dependency configuration wasn't
> "guessed" from the system, but specified from the command-line
> options.
>
> If you don't have libzip or zzip installed, ./configure will fail
> (unless you explicitely disabled embedded resources). Or there's a bug
> in my code ;)
>
>   if test x"$enable_embedded_resources" = x"yes"; then
>     if test "$LACK_LIBZIP" = 1 -a "$LACK_ZZIPLIB" = 1; then
>       echo "* You need to install libzip or ZZipLib (or 
> --disable-embedded-resources)."
>       error=1
>     fi
>     if test -z "$ZIP"; then
>       echo "* The 'zip' utility cannot be found. Please install it (or 
> --disable-embedded-resources)."
>       error=1
>     fi
>   fi
>
>
> > I seem to remember only a ZIP archive being available on one and a  
> > tarball being available on the other.
>
> I didn't upload .zip version at ftp.gnu.org essentially out of
> lazyness, but they are the same than the .tar.gz or .tar.bz2.
>
>
> > Ok, I've subscribed there... I'll try to get port updates done as new  
> > releases happen.
>
> Well for starters I uploaded a new release of freedink-data with a
> fixed Makefile.  I'd be glad if you could check if it's alright now :)
>
> -- 
> Sylvain
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: FreeDink in FreeBSD
>
>
>
>
> Date: 
>
> Sun, 30 Nov 2008 14:08:19 +0100
>
>
>
>
> User-agent: 
>
> Mutt/1.5.18 (2008-05-17)
>
>
>
>
> Hi,
>
> > Did you look over the patches in the port?  The rm/chmod path fixes in  
> > the makefile for freedink-data,
>
> I saw it, thanks for this :) I had partially fixed this in Git but now
> it should be good (I need to make a new freedink-data release.)
>
>
> > and the itlocale change in the dfarc Makefile.in.in
>
> I didn't really understand this one :)
>
> Note that 'Makefile.in.in' is installed by 'intltoolize', so maybe the
> patch should go to the intltool project as well.
>
>
> > I set up the options to default to enabling embedded resources, since it  
> > was hinted that's what was preferred, and hardcoded disabling upx since  
> > I couldn't figure out why anyone would want to enable it.  :-)
>
> I clarified './configure --help' about embedded resources; indeed
> that's the preferred way (so FreeDink can load the default font in all
> situations). I only added a way to disable it for distros that enforce
> stripping executables after the build process, which removes embedded
> resources anyway.
>
> UPX (like --static) is mainly used to generate compact executables for
> direct download (e.g. .exe), but it's not very useful for distros
> indeed.
>
> Btw, your choice of options is actually the default :)
>
>
> > Also, I noticed that the main site and the GNU mirror sites have  
> > different sets of files.  Haven't gone back and checked if that is fixed  
> > yet or not.
>
> freedink.org has some additional binary packages as well as snapshots,
> but the source releases are the same.
>
> It's best indeed to use the GNU mirrors directly, so that freedink.org
> doesn't use too much bandwidth.
>
>
> > It was pretty straightforward to do the port though... when I came  
> > across FreeDink, I was actually expecting to have to do some porting.  I  
> > looked at the code back when it was released and decided that I didn't  
> > care enough at the time to do anything about it.  Recently, I decided to  
> > go back and slowly pick away at it and discovered that it was already  
> > finished.  miwi@ stepped up and fixed my initial porting efforts and  
> > checked it in so now I just need to figure out where to subscribe to  
> > update announcements.  :-)
>
> Glad that the port was easy - this means FreeDink is truly portable :)
>
> There isn't a dedicated mailing list for release announcements (given
> the low traffic of bug-freedink), but I usually post release
> announcements at:
>
> http://savannah.gnu.org/news/atom.php?group=freedink
> address@hidden
> address@hidden
>
> -- 
> Sylvain
>
>
> --- End Message ---