Date: Tue, 2 Dec 2008 22:37:51 +0100 From: Sylvain Beucler <beuc@beuc.net> To: Stephen Hurd <shurd@sasktel.net> Cc: gnome@FreeBSD.org, bug-freedink@gnu.org, miwi@FreeBSD.org Subject: Re: intltool.m4 and FreeBSD Message-ID: <20081202213751.GA4045@perso.beuc.net> In-Reply-To: <4934E791.9000209@sasktel.net> References: <20081130090104.GA3356@perso.beuc.net> <49326D91.7070501@sasktel.net> <20081130130819.GA13746@perso.beuc.net> <493350C0.6060302@sasktel.net> <20081201192733.GA30088@perso.beuc.net> <4934BE7D.6020908@sasktel.net> <20081202070447.GC32358@perso.beuc.net> <4934E791.9000209@sasktel.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@beuc.net> > Subject: Re: FreeDink in FreeBSD > To: Stephen Hurd <shurd@sasktel.net> > Cc: miwi@FreeBSD.org, bug-freedink@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@beuc.net> > Subject: Re: FreeDink in FreeBSD > To: Stephen Hurd <shurd@sasktel.net> > Cc: miwi@FreeBSD.org, bug-freedink@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@gnu.org > info-gnu@gnu.org > > -- > Sylvain
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081202213751.GA4045>