GNOME Bugzilla – Bug 592587
Fix build on FreeBSD.
Last modified: 2009-10-05 14:06:32 UTC
These pathes (hope they will be attached... thank's git) fix portability issues that makes Banshee fail building on FreeBSD.
Created attachment 141333 [details] [review] Fix bash location. The autogen.sh script expects bash to be installed in /bin. Rely on env to determine where the binary is located instead.
Created attachment 141335 [details] [review] Fix libmtp.so.* detection. FreeBSD find(1) rely on a POSIX.2 compliant implementation of regular expressions for it's non-POSIX.1 compliant -regex operand. It thus does not support the \w construct in regular expressions, and by default, does not support the '+' bound of extended regular expressions (unless asked to use extended re). Expand the '\w+' to '[0-9][0-9]*' so that we have a POSIX regular expression likely to be portable and don't introduce any new non-POSIX constructs to rely on extended regular expressions.
Created attachment 141336 [details] [review] Remove bashisms. The == argument to test(1) is a non POSIX extension of GNU bash built-in test(1) command.
Created attachment 141337 [details] [review] Use sed detected by the autotools. FreeBSD sed(1) does not provides some non POSIX extensions to sed featured in GNU sed(1). GNU sed(1) is installed as gsed(1) on FreeBSD and is detected by the autotools. Use $SED to use the correct version on sed(1) on all platforms.
Created attachment 141338 [details] [review] Fix bash(1) location.
Created attachment 141339 [details] [review] Remove bashism. The shave script use bash(1) extensions but the shee bang is set on /bin/sh. Since there is a single extension, get rid of it instead of fixing the shee bang to locate bash and the autohell stuff to run shave with bash(1).
Created attachment 141340 [details] [review] Use the sed(1) utility detected by the autotools. Replace a direct use of sed(1) with $SED which is setup correctly by the autotools (likely to gsed(1) on systems where sed(1) is not GNU sed(1)).
Created attachment 141427 [details] [review] Fix library mapping on FreeBSD. Edit the *.config files so that plateforms such as GNU/Linux and FreeBSD use the same library names (letting dll's to windows and dynlibs to OSX).
Created attachment 141428 [details] [review] Use env(1) to detect bash(1) I am fedup with this. Changed all #!/bin/bash to #!/usr/bien/env bash using sed(1).
Created attachment 141430 [details] [review] Add forgotten *.config files Another s/linux/!windows,osx in #.config files so that mono look for the right files on FreeBSD (at least). Should have did that in the first time for all *.config files but only focussed on those that prevented banshee to start.
Fine, will all this patch banshee is somewhat usable. A few features are not available, but at least I can listen to music on my computer. Startup log (basnshee configured --without-ipod): ----8<---------------------------- [Info 18:15:41.374] Running Banshee 1.5.1: [git-checkout (freebsd7.2, i386) @ 2009-08-22 18:10:06 CEST] [Warn 18:15:41.973] Hardware manager extension failed to load - Exception has been thrown by the target of an invocation. [Warn 18:15:41.973] Service `Banshee.Hardware.HardwareManager' not started: No HardwareManager extensions could be loaded. Hardware support will be disabled. [Warn 18:15:41.977] Caught an exception - No HardwareManager extensions could be loaded. Hardware support will be disabled. (in `Banshee.Services') at Banshee.Hardware.HardwareManager..ctor () [0x00000] at (wrapper managed-to-native) System.Reflection.MonoCMethod:InternalInvoke (object,object[],System.Exception&) at System.Reflection.MonoCMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] [Warn 18:15:42.828] Caught an exception - Object reference not set to an instance of an object (in `Banshee.AudioCd') at Banshee.AudioCd.AudioCdService.Initialize () [0x00000] at Banshee.ServiceStack.ServiceManager.StartExtension (Mono.Addins.TypeExtensionNode node) [0x00000] [Warn 18:15:42.834] Extension `Banshee.AudioCd.AudioCdService' not started: Object reference not set to an instance of an object [Warn 18:15:42.938] Cannot connect to NetworkManager - An available, working network connection will be assumed [Warn 18:15:43.020] Caught an exception - Object reference not set to an instance of an object (in `Banshee.AudioCd') at Banshee.AudioCd.AudioCdService.Initialize () [0x00000] at Banshee.ServiceStack.ServiceManager.StartExtension (Mono.Addins.TypeExtensionNode node) [0x00000] [Warn 18:15:43.020] Extension `Banshee.AudioCd.AudioCdService' not started: Object reference not set to an instance of an object [Info 18:15:43.022] All services are started 1,410897s [Info 18:15:44.975] nereid Client Started ----8<---------------------------- Thank you for checking these patches do not mess up banshee on GNU/Linux / Windows / OSX and merging them. Sorry for the number of patches, I guess I have to get a bit more training with git before being efficient with it.
Comment on attachment 141427 [details] [review] Fix library mapping on FreeBSD. Bug 559773 already had a patch for this, using the same approach but more complete. So I just committed it.
Comment on attachment 141430 [details] [review] Add forgotten *.config files Same as the previous comment : just committed the patch from Bug 559773.
Comment on attachment 141337 [details] [review] Use sed detected by the autotools. Committed, thanks !
Comment on attachment 141340 [details] [review] Use the sed(1) utility detected by the autotools. Committed, thanks !
Comment on attachment 141335 [details] [review] Fix libmtp.so.* detection. The new regular expression doesn't seems to work for me. After removing one of the [[0-9]], it seems to work. Could you check it on your side ?
(In reply to comment #16) > (From update of attachment 141335 [details] [review]) > The new regular expression doesn't seems to work for me. > After removing one of the [[0-9]], it seems to work. > > Could you check it on your side ? Well, the extended regexp /[0-9]+/ means "one or more digit"... On FreeBSD, grep(1) need to have the -E argument set to use extended regular expressions, so I changed it to /[0-9][0-9]*/ to rely on old style regular expressions, which mean "one digit followed by any number of digits". With just /[0-9]*/, grep will also match no digit at all, for example this file name would match: "libmtp.so.". It is incorect, but unlikely to happen since he name makes no sense though. Full example: ----8<--------------- romain@marvin ~ % cat << EOT | grep -E '.*libmtp\.so\.[0-9]+$' pipe heredoc> Plolp./libmtp.so pipe heredoc> Plolp./libmtp.so. pipe heredoc> Plolp./libmtp.so.0 pipe heredoc> Plolp./libmtp.so.10 pipe heredoc> EOT Plolp./libmtp.so.0 Plolp./libmtp.so.10 romain@marvin ~ % cat << EOT | grep '.*libmtp\.so\.[0-9]*$' pipe heredoc> Plolp./libmtp.so pipe heredoc> Plolp./libmtp.so. pipe heredoc> Plolp./libmtp.so.0 pipe heredoc> Plolp./libmtp.so.10 pipe heredoc> EOT Plolp./libmtp.so. Plolp./libmtp.so.0 Plolp./libmtp.so.10 romain@marvin ~ % cat << EOT | grep '.*libmtp\.so\.[0-9][0-9]*$' pipe heredoc> Plolp./libmtp.so pipe heredoc> Plolp./libmtp.so. pipe heredoc> Plolp./libmtp.so.0 pipe heredoc> Plolp./libmtp.so.10 pipe heredoc> EOT Plolp./libmtp.so.0 Plolp./libmtp.so.10 romain@marvin ~ % ----8<--------------- Unfortunately, I don't have a GNU/Linux box to find out what is the problem with GNU grep(1). I assume however that something portable that matches wrong stuff with GNU grep(1) is better than failling with non-GNU grep(1) implementations...
Argh, stupid me : I was testing the regexp manually, but kept the extra []. Sorry about that. The patch works fine, I just committed it. I'm not sure yet about the "/usr/bin/env bash" thing, I'll have to look into it.
Comment on attachment 141339 [details] [review] Remove bashism. I think this doesn't work when /bin/sh is a link to /bin/bash : What gets printed during the build is something like MCS -out:../../../bin/Hyena.dll but it should be MCS ../../../bin/Hyena.dll lt_output should be a substring of opt starting at the 5th character.
(In reply to comment #18) > I'm not sure yet about the "/usr/bin/env bash" thing, I'll have to look into > it. /bin/bash is a bad practive. More details here: http://romain.blogreen.org/Blog/You_bash_users_are_driving_me_crazy (In reply to comment #19) > (From update of attachment 141339 [details] [review]) > I think this doesn't work when /bin/sh is a link to /bin/bash : > What gets printed during the build is something like > MCS -out:../../../bin/Hyena.dll > but it should be > MCS ../../../bin/Hyena.dll > > lt_output should be a substring of opt starting at the 5th character. D'oh, I thouh the goal was to set opt to 5 if it was not defined. ---8<------------- $ echo ${FOO:=Hello} Hello ---8<------------- The POSIX syntax is therefore "#?????" (5 chars --- strictly equivalent) or "#*:" (any number of char followed by a column --- simpler) or "#-out:" (most obvious to read, strip "-out:"): ---8<------------- $ opt=-out:Hello $ echo ${opt#?????} Hello $ echo ${opt#*:} Hello $ echo ${opt#-out:} Hello ---8<------------- Choose your favourite one ;-)
Comment on attachment 141339 [details] [review] Remove bashism. I went with the #*: solution. I'll also notify the original author of shave about the issue.
Created attachment 141715 [details] [review] Remove another usage of a GNU extension. \n in replacement strings is a GNU sed extension. Quoting IEEE Std 1003.1, « The meaning of a '\' immediately followed by any character other than '&', '\', a digit, or the delimiter character used for this command, is unspecified ». Source: http://www.opengroup.org/onlinepubs/009695399/utilities/sed.html This patch prevents FreeBSD from replacing banshee-1.desktop.mime's contents with a single inconsistent line (/;/ being dropped and not replaced by anything). Please note that the file's content is still changed because of GNU sort and BSD sort not sorting the same way (maybe caused by the program implementation of the user environment).
Created attachment 141718 [details] [review] Fix invalid? locale name (en_US.utf8 instead of en_US.UTF-8). "en_US.utf8" is an invalid locale for FreeBSD. Example: -----8<------------------------- romain@marvin ~ % LC_ALL=en_US.utf8 locale LANG=fr_FR.UTF-8 LC_CTYPE="C" LC_COLLATE="C" LC_TIME="C" LC_NUMERIC="C" LC_MONETARY="C" LC_MESSAGES="C" LC_ALL=en_US.utf8 romain@marvin ~ % LC_ALL=en_US.UTF-8 locale LANG=fr_FR.UTF-8 LC_CTYPE="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_ALL=en_US.UTF-8 -----8<------------------------- This results in invalid characters in src/Core/Banshee.Core/Resources/translators.xml. As far as I remember, "en_US.UTF-8" is also valid on GNU/Linux so it might be interesting to use it instead.
Comment on attachment 141428 [details] [review] Use env(1) to detect bash(1) I just committed this change, but only for the scripts used for building, installing or running (6 in total). I didn't touch the scripts used on MacOSX. Please check that I haven't missed any.
Comment on attachment 141715 [details] [review] Remove another usage of a GNU extension. Committed. Thanks for the detailed explanation ! The content of banshee-1.desktop.mime is not changed : the sorting was locale-dependent, but that's fixed now.
Closing this bug, as all patches have been dealt with. Thank you for your work on this ! Feel free to open new bugs of you have any other FreeBSD-related issue, or any type of issue ;)
Created attachment 144783 [details] [review] Avoid using GNU sed extended regular extensions. GNU sed can use extended regular expressions using the non-POSIX -r switch while FreeBSD sed rely on a -E non-POSIX switch to do the same. Expand the regular expression so that it is a simple one to avoid relying on those switches.
Reopen since I added another patch which avoids depending on GNU sed just for a single regular expression. Now, banshee trunk compiles smoothly on FreeBSD! Yay!
Thanks again ! Please open a new bug for any other issue, this one is getting a bit unwieldy and hard to follow.