gcc and xgetbv
I'm trying to compile gnuradio using configure.compiler=macports-gcc-4.7
to see if their SIMD detection is working (a component they call VOLK).
VOLK was originally designed for GCC-based compilers, and they are
working on augmenting for CLANG. I've been told, and a quick internet
search ("xgetbv") agrees, that the following code snippet should be
appropriate to use for GCC >= 4.4:
{{{
#if __GNUC__ > 4 || __GNUC__ == 4 && __GNUC_MINOR__ >= 4
static inline unsigned long long _xgetbv(unsigned int index){
unsigned int eax, edx;
__asm__ __volatile__("xgetbv" : "=a"(eax), "=d"(edx) : "c"(index));
return ((unsigned long long)edx << 32) | eax;
}
#else
#define _xgetbv() 0
#endif
}}}
but, this code does not compile using MacPorts' gcc 4.7; it errors out
with "no such instruction: `xgetbv'". Apple's clang compiles this code
without the #if, but it errors out when running with "Illegal
instruction: 4". Ditto for MacPorts' clang 3.1. If I change the __asm__
line to us the raw opcode instead:
{{{
__asm__ (".byte 0x0f, 0x01, 0xd0" : "=a"(eax), "=d"(edx) : "c"
(index));
}}}
then gcc 4.7 compiles it, but returns the same runtime error as with
clang. Hence I'm guessing that my CPU does not support this instruction.
I'm using a 2009 MacBook Pro with Core 2 Duo, 10.8 with most recent OS
and Xcode tools; latest MacPorts from SVN trunk. Can anyone tell me
what's going on, and/or provide any advice on why GCC 4.7 isn't allowing
this instruction? Thanks! - MLD
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [101989] trunk/dports/net/bind9
On Jan 24, 2013, at 12:39 PM, Daniel J. Luke wrote: >> I spent 5 minutes looking on http://www.isc.org for a way to actually send >> them the patch only to be presented with requests to fill out a sponsorship >> application before I could join their forums. As such, ISC doesn't have the >> patch. > > ack, I'll see about getting it to someone at ISC. Thanks. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [101949] trunk/dports/kde/kde4-runtime
OMG, now we depend on clang for some of the KDE ports?!!! So much hassle just to get kde4-(runtime|baseapps) built… :-( Is there no way around this? ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [101989] trunk/dports/net/bind9
On Jan 24, 2013, at 1:34 PM, Jeremy Huddleston Sequoia wrote: >> (If so, it wasn't a minimal fix, since it affected more than that variant - >> if not, it wasn't something that prevented the build on my local boxes or >> the buildboxes, so I don't think it really qualifies under that policy). > > Well, that's your opinion. I'm sorry we disagree. When the policy was written, the only thing it originally included was stuff that just didn't build (security updates were later also considered important enough/broken enough to be included). >>> The second is permitted for non-openmaintainer ports, and the former was >>> recently suggested as an extension of that allowance. >> >> It may have been suggested, but as far as I know, it wasn't actually added >> to the policy. > > Well, my apologies for not wanting to bother you with something trivial. by not including 'openmaintainer' I'm specifically saying that I want to be bothered by things that might be considered 'trivial' >>> bind9's "checking for static inline breakage... " check was broken and >>> returning "yes" incorrectly because their check was not valid. >> >> ... but the build still worked fine even though it wasn't inlining things >> that it maybe should have been, right? >> Did you push your patch back upstream? > > I spent 5 minutes looking on http://www.isc.org for a way to actually send > them the patch only to be presented with requests to fill out a sponsorship > application before I could join their forums. As such, ISC doesn't have the > patch. ack, I'll see about getting it to someone at ISC. >> In any event - I always appreciate getting a note and/or ticket if someone >> is going to work on one of my non-openmaintainer ports (they aren't >> openmaintainer for a reason, after all). > > Well, you didn't give me much time to send you a note. You replied to my > comment seconds after I pushed it ;) which is sort of my point - if you had ping'd me first I probably would have given the OK for you to commit - and it's not like you would have been sitting on it waiting for me for a long time :) -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [101464] trunk/dports/_resources/port1.0/group/ compiler_blacklist_versions-1.0.tcl
On Jan 24, 2013, at 9:46 AM, Rainer Müller wrote: > Fun fact: These quotes are used differently depending on the language. > “English” > „German“ > Note that the English left quote is the same as the German right quote. > That is why I just cannot remember which of these symbols has to appear > at the beginning or at the end. Mmm, that yummy localization goodness. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [101989] trunk/dports/net/bind9
On Jan 24, 2013, at 7:13 AM, Daniel J. Luke wrote: > On Jan 23, 2013, at 10:55 PM, Jeremy Huddleston Sequoia > wrote: >> On Jan 23, 2013, at 7:39 PM, Daniel J. Luke wrote: >>> On Jan 23, 2013, at 7:38 PM, jerem...@macports.org wrote: bind9: Fix inlining >>> >>> What ticket is this for? and/or what was broken that you fixed on this >>> non-openmaintainer port? >> >> This is an obvious fix for a build failure. > > What build failure? Just the +dlz_mysql5 variant? No. It has nothing to do with the dlz_mysql5 variant. > (If so, it wasn't a minimal fix, since it affected more than that variant - > if not, it wasn't something that prevented the build on my local boxes or the > buildboxes, so I don't think it really qualifies under that policy). Well, that's your opinion. I'm sorry we disagree. >> The second is permitted for non-openmaintainer ports, and the former was >> recently suggested as an extension of that allowance. > > It may have been suggested, but as far as I know, it wasn't actually added to > the policy. Well, my apologies for not wanting to bother you with something trivial. >> bind9's "checking for static inline breakage... " check was broken and >> returning "yes" incorrectly because their check was not valid. > > ... but the build still worked fine even though it wasn't inlining things > that it maybe should have been, right? > Did you push your patch back upstream? I spent 5 minutes looking on http://www.isc.org for a way to actually send them the patch only to be presented with requests to fill out a sponsorship application before I could join their forums. As such, ISC doesn't have the patch. > In any event - I always appreciate getting a note and/or ticket if someone is > going to work on one of my non-openmaintainer ports (they aren't > openmaintainer for a reason, after all). Well, you didn't give me much time to send you a note. You replied to my comment seconds after I pushed it ;) > >>> It looks like now everyone who installs it needs autoconf and needs >>> autoreconf where before there were some patches just for dlz_mysql5 :-\ >> >> Yeah, well... them's the breaks. > > ... but the don't have to be. I would think that adding additional > dependencies like that would have at least been enough of a change that you'd > want to let me know about it before you made the change … Sorry. I didn't really see it as a big deal. So many ports depend on autoconf that I don't see it as an added dependency. As I mentioned, it's an obvious fix that I noticed, and I didn't want to bother you with it beforehand. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [101464] trunk/dports/_resources/port1.0/group/ compiler_blacklist_versions-1.0.tcl
On Jan 24, 2013, at 10:41 AM, Rainer Müller wrote: > It's /opt/X11/bin/xterm for me, but I guess /usr/X11R6 on your system is a > symlink to that anyway. I use the same versions on Mac OS X 10.8 Mountain > Lion. Yes: % ls -lAFd /usr/X11* lrwxr-xr-x 1 root wheel 8 Oct 26 09:33 /usr/X11@ -> /opt/X11 lrwxr-xr-x 1 root wheel 8 Oct 26 09:33 /usr/X11R6@ -> /opt/X11 And, yes, 10.8 latest. > From the xterm window: > $ env |grep -E 'XTERM|__CF' > XTERM_SHELL=/opt/local/bin/bash > __CF_USER_TEXT_ENCODING=0x1F5:0:0 > XTERM_LOCALE=en_US.UTF-8 > XTERM_VERSION=XTerm(281) > I don't know where XTERM_LOCALE comes from, but from the name it sounds like > that could be the culprit. Doing "export XTERM_LOCALE=en_US.UTF-8" in my shell does not help. Quite strange. Anyway, if smart quotes work for others then my terminal is special somehow and feel free to use them; I'll deal and it's not that big of one. - MLD ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [101464] trunk/dports/_resources/port1.0/group/ compiler_blacklist_versions-1.0.tcl
On 2013-01-24 16:29, Michael Dickens wrote:
> On Jan 24, 2013, at 9:46 AM, Rainer Müller wrote:
>> It's probably not a problem for most users with a recent enough terminal
>> emulator that supports UTF-8. Actually one would have to check by locale
>> environment or by other means whether support for UTF-8 is available... Not
>> sure if this is worth the effort. I tried with xterm within XQuartz and it
>> seems to work for me (by checking with 'port info graphite2', which includes
>> smart quotes). I am using LC_ALL="en_US.UTF-8". I experimented with some
>> different values, but found no way to break it.
>
> Interesting. I'm using the (I think) latest release of XQuartz from
> MacOSForge [from "About X11": "XQuartz 2.7.4 (xorg-server 1.13.0)"], and
> the (I think) xterm provided by it: "which xterm" returns
> "/usr/X11R6/bin/xterm", and "xterm -help" returns "XTerm(281)" if that
> makes any difference. I do not have Apple's X11.app installed.
It's /opt/X11/bin/xterm for me, but I guess /usr/X11R6 on your system is
a symlink to that anyway. I use the same versions on Mac OS X 10.8
Mountain Lion.
> I tried
> "port info graphite2" and it locks the terminal at the first smart
> quote. I tried
> {{{
> export LC_ALL="en_US.UTF-8"
> }}}
> and then the info command with the same result. All of the ~/.Xdefaults
> for xterm are color related, not encoding; so, those shouldn't make a
> difference. My shell environment is pretty normal; the only variables I
> see that might have an impact are:
> {{{
> __CF_USER_TEXT_ENCODING=0x1F6:0:0
> XTERM_LOCALE=C
> }}}
>From the xterm window:
$ env |grep -E 'XTERM|__CF'
XTERM_SHELL=/opt/local/bin/bash
__CF_USER_TEXT_ENCODING=0x1F5:0:0
XTERM_LOCALE=en_US.UTF-8
XTERM_VERSION=XTerm(281)
I don't know where XTERM_LOCALE comes from, but from the name it sounds
like that could be the culprit.
Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [101464] trunk/dports/_resources/port1.0/group/ compiler_blacklist_versions-1.0.tcl
On Jan 24, 2013, at 9:46 AM, Rainer Müller wrote:
> It's probably not a problem for most users with a recent enough terminal
> emulator that supports UTF-8. Actually one would have to check by locale
> environment or by other means whether support for UTF-8 is available... Not
> sure if this is worth the effort. I tried with xterm within XQuartz and it
> seems to work for me (by checking with 'port info graphite2', which includes
> smart quotes). I am using LC_ALL="en_US.UTF-8". I experimented with some
> different values, but found no way to break it.
Interesting. I'm using the (I think) latest release of XQuartz from
MacOSForge [from "About X11": "XQuartz 2.7.4 (xorg-server 1.13.0)"], and
the (I think) xterm provided by it: "which xterm" returns
"/usr/X11R6/bin/xterm", and "xterm -help" returns "XTerm(281)" if that
makes any difference. I do not have Apple's X11.app installed. I tried
"port info graphite2" and it locks the terminal at the first smart
quote. I tried
{{{
export LC_ALL="en_US.UTF-8"
}}}
and then the info command with the same result. All of the ~/.Xdefaults
for xterm are color related, not encoding; so, those shouldn't make a
difference. My shell environment is pretty normal; the only variables I
see that might have an impact are:
{{{
__CF_USER_TEXT_ENCODING=0x1F6:0:0
XTERM_LOCALE=C
}}}
Maybe my xterm is ``special''? - MLD
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [101989] trunk/dports/net/bind9
On Jan 23, 2013, at 10:55 PM, Jeremy Huddleston Sequoia wrote: > On Jan 23, 2013, at 7:39 PM, Daniel J. Luke wrote: >> On Jan 23, 2013, at 7:38 PM, jerem...@macports.org wrote: >>> >>> bind9: Fix inlining >> >> What ticket is this for? and/or what was broken that you fixed on this >> non-openmaintainer port? > > This is an obvious fix for a build failure. What build failure? Just the +dlz_mysql5 variant? (If so, it wasn't a minimal fix, since it affected more than that variant - if not, it wasn't something that prevented the build on my local boxes or the buildboxes, so I don't think it really qualifies under that policy). > The second is permitted for non-openmaintainer ports, and the former was > recently suggested as an extension of that allowance. It may have been suggested, but as far as I know, it wasn't actually added to the policy. > bind9's "checking for static inline breakage... " check was broken and > returning "yes" incorrectly because their check was not valid. ... but the build still worked fine even though it wasn't inlining things that it maybe should have been, right? Did you push your patch back upstream? In any event - I always appreciate getting a note and/or ticket if someone is going to work on one of my non-openmaintainer ports (they aren't openmaintainer for a reason, after all). >> It looks like now everyone who installs it needs autoconf and needs >> autoreconf where before there were some patches just for dlz_mysql5 :-\ > > Yeah, well... them's the breaks. ... but the don't have to be. I would think that adding additional dependencies like that would have at least been enough of a change that you'd want to let me know about it before you made the change ... -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [101464] trunk/dports/_resources/port1.0/group/ compiler_blacklist_versions-1.0.tcl
On 2013-01-24 15:14, Ryan Schmidt wrote: > Sorry to hear smart quotes don't work with your xterm; this is the > first I've heard of such a problem. I don't know why that would be. > They work fine in my OS X Terminal.app on Mountain Lion. > > I've been switching to smart quotes in many ports already, and I > meant that I was hoping we would switch to smart quotes everywhere, > not just in that one file. Portfiles are UTF-8 files; I didn't see > any reason not to use any valid UTF-8 character in them. Fun fact: These quotes are used differently depending on the language. “English” „German“ Note that the English left quote is the same as the German right quote. That is why I just cannot remember which of these symbols has to appear at the beginning or at the end. > Obviously I don't want to cause problems for users... Does anybody > else have problems with smart quotes, either with them displaying > wrong or with them locking up the terminal? Do other non-ASCII > characters cause this same problem? It's probably not a problem for most users with a recent enough terminal emulator that supports UTF-8. Actually one would have to check by locale environment or by other means whether support for UTF-8 is available... Not sure if this is worth the effort. I tried with xterm within XQuartz and it seems to work for me (by checking with 'port info graphite2', which includes smart quotes). I am using LC_ALL="en_US.UTF-8". I experimented with some different values, but found no way to break it. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Compiling ObjC++ versus ObjC
On Jan 23, 2013, at 7:10 PM, Jeremy Huddleston Sequoia wrote > Well, I encourage you to submit these change upstream, so developers *can* > rely on them =) I'll check out the Qt tickets. > No, you should fix it right (defaulting to $CXX). For comparison, this is > what autoconf does: > > http://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Objective-C_002b_002b-Compiler.html OK; will do. I doubt this will cause issues, given how the variables are created and used; but, we'll see. Thanks for your feedback! - MLD ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [101464] trunk/dports/_resources/port1.0/group/ compiler_blacklist_versions-1.0.tcl
On Jan 24, 2013, at 07:46, Michael Dickens wrote: > On Jan 24, 2013, at 8:33 AM, Ryan Schmidt wrote: >> On Jan 11, 2013, at 08:18, michae...@macports.org wrote: >>> compiler_blacklist_versions : change fancy ``s to basic "s, as is used >>> everywhere else. >>> >>> Modified Paths: >>> -- >>> trunk/dports/_resources/port1.0/group/compiler_blacklist_versions-1.0.tcl >> >> Is there a specific reason for this change? I'd actually prefer to switch >> everything to smart quotes over time. They're prettier. > > Yes. They lock my xterm from XQuartz.app, and those were the only fancy > ``s in that file; all the rest were normal "s. Given those facts, and > that I was working with this file a lot for a day, I went ahead and > checked in the change hoping that it would be useful to others. > > Pretty much any non-standard character locks up my xterm. I have not > tried configuring xterm to deal with this, as I'm pretty sure many other > used won't have either. Hence, without some better way of displaying > non-standard characters, no matter how pretty they are, it seems wisest > to avoid them instead of forcing the user into a specific setting or > terminal. > > That said, given that I'm done using the compiler_blacklist_versions > PortGroup (at least for now), it doesn't matter to me if you want to > move all of the basic "s (back) to fancy ``s. - MLD Sorry to hear smart quotes don't work with your xterm; this is the first I've heard of such a problem. I don't know why that would be. They work fine in my OS X Terminal.app on Mountain Lion. I've been switching to smart quotes in many ports already, and I meant that I was hoping we would switch to smart quotes everywhere, not just in that one file. Portfiles are UTF-8 files; I didn't see any reason not to use any valid UTF-8 character in them. Obviously I don't want to cause problems for users... Does anybody else have problems with smart quotes, either with them displaying wrong or with them locking up the terminal? Do other non-ASCII characters cause this same problem? ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [101464] trunk/dports/_resources/port1.0/group/ compiler_blacklist_versions-1.0.tcl
On Jan 24, 2013, at 8:33 AM, Ryan Schmidt wrote: > On Jan 11, 2013, at 08:18, michae...@macports.org wrote: > > compiler_blacklist_versions : change fancy ``s to basic "s, as is used > > everywhere else. > > > > Modified Paths: > > -- > > trunk/dports/_resources/port1.0/group/compiler_blacklist_versions-1.0.tcl > > Is there a specific reason for this change? I'd actually prefer to switch > everything to smart quotes over time. They're prettier. Yes. They lock my xterm from XQuartz.app, and those were the only fancy ``s in that file; all the rest were normal "s. Given those facts, and that I was working with this file a lot for a day, I went ahead and checked in the change hoping that it would be useful to others. Pretty much any non-standard character locks up my xterm. I have not tried configuring xterm to deal with this, as I'm pretty sure many other used won't have either. Hence, without some better way of displaying non-standard characters, no matter how pretty they are, it seems wisest to avoid them instead of forcing the user into a specific setting or terminal. That said, given that I'm done using the compiler_blacklist_versions PortGroup (at least for now), it doesn't matter to me if you want to move all of the basic "s (back) to fancy ``s. - MLD ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [101464] trunk/dports/_resources/port1.0/group/ compiler_blacklist_versions-1.0.tcl
On Jan 11, 2013, at 08:18, michae...@macports.org wrote: > Revision: 101464 > https://trac.macports.org/changeset/101464 > Author: michae...@macports.org > Date: 2013-01-11 06:18:33 -0800 (Fri, 11 Jan 2013) > Log Message: > --- > compiler_blacklist_versions : change fancy ``s to basic "s, as is used > everywhere else. > > Modified Paths: > -- >trunk/dports/_resources/port1.0/group/compiler_blacklist_versions-1.0.tcl Is there a specific reason for this change? I'd actually prefer to switch everything to smart quotes over time. They're prettier. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Skipping *nix hidden folders while indexing
On 2013-01-23 01:30, Andrea D'Amore wrote:
> I sometime disable a port in tree and reindex, the natural way to do
> it is to prepend a dot to the portdir name. Is there anything against
> the following?
>
> Index: src/macports1.0/macports.tcl
> ===
> --- src/macports1.0/macports.tcl(revision 101957)
> +++ src/macports1.0/macports.tcl(working copy)
> @@ -1689,6 +1689,7 @@
> foreach port [lsort -increasing -unique [readdir
> $pathToCategory]] {
> set pathToPort [file join $pathToCategory $port]
> if {[file isdirectory $pathToPort] &&
> +[string index [file tail $pathToPort] 0] != "." &&
>[file exists [file join $pathToPort "Portfile"]]} {
> # Call the function.
> $func [file join $category $port]
>
+0
Nothing against this. Note that we are already skipping paths beginning
with an underscore in the category directory (to support _resources).
The underscore was chosen as path names starting with a dot would not be
displayed in Finder and the directory should still be accessible this
way. While I use the shell for management of my port directory anyway,
would there be a preference by others to use an underscore instead (or
in addition) to the proposed dot?
port lint should be extended to warn if a port name/port directory
starts with a dot/underscore.
Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
