intltool.m4 and FreeBSD
Sylvain Beucler
beuc at beuc.net
Tue Dec 2 14:12:32 PST 2008
Hi,
I went ahead and submitted a bugreport to intltool, after some more
testing:
http://bugzilla.gnome.org/show_bug.cgi?id=563034
Feel free to leave a comment if I said anything wrong :)
--
Sylvain
On Mon, Dec 01, 2008 at 11:45:21PM -0800, Stephen Hurd wrote:
> I've attached your previous emails and added gnome at FreeBSD.org (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'.
>>
>>
>
> Date: Mon, 01 Dec 2008 20:27:33 +0100
> From: Sylvain Beucler <beuc at beuc.net>
> Subject: Re: FreeDink in FreeBSD
> To: Stephen Hurd <shurd at sasktel.net>
> Cc: miwi at FreeBSD.org, bug-freedink at gnu.org
> 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
>
> Date: Sun, 30 Nov 2008 14:08:19 +0100
> From: Sylvain Beucler <beuc at beuc.net>
> Subject: Re: FreeDink in FreeBSD
> To: Stephen Hurd <shurd at sasktel.net>
> Cc: miwi at FreeBSD.org, bug-freedink at gnu.org
> 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
> bug-freedink at gnu.org
> info-gnu at gnu.org
>
> --
> Sylvain
More information about the freebsd-gnome
mailing list