From pantos at pantokratoren.de Wed Apr 5 05:30:22 2017 From: pantos at pantokratoren.de (pantos at pantokratoren.de) Date: Wed, 05 Apr 2017 07:30:22 +0200 Subject: rtl_test -t results in failed to open rtlsdr device #0. Message-ID: Hello, a few days ago I tried to install rtl-sdr on my raspberry pi. I'm using a dvb-t usb stick with Realtek, RTL2838UHIDIR chipset. I build the software following the guide in the wiki. I used two additional switches: cmake ../ -DINSTALL_UDEV_RULES=ON -DDETACH_KERNEL_DRIVER=ON After installing the software I created a blacklist in cd /etc/modprobe.d: blacklist dvb_usb_rtl28xxu blacklist rtl2832 blacklist rtl2830 blacklist rtl2838 After rebooting the device I tried to test rtl-sdr with rtl_test -t and got this result: Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000001 Using device 0: Generic RTL2832U OEM usb_claim_interface error -6 Failed to open rtlsdr device #0. I don't know how to fix this error. I tried many suggestions found via google but it doesn't work. Can someone help me to fix this? Thanks for your help!! Joachim -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.mueller at ettus.com Wed Apr 5 12:35:44 2017 From: marcus.mueller at ettus.com (=?UTF-8?Q?Marcus_M=c3=bcller?=) Date: Wed, 5 Apr 2017 14:35:44 +0200 Subject: rtl_test -t results in failed to open rtlsdr device #0. In-Reply-To: References: Message-ID: Hi Joachim, "I tried many [...] but it doesn't work": so, what exactly you've tried would be kind of relevant :) I'll go out on a limb here based on statistics and say: you might have missed what http://osmocom.org/projects/sdr/wiki/rtl-sdr#rtlsdr-library-amp-capture-tool says: sudo make install-udev-rules Best regards, Marcus On 05.04.2017 07:30, pantos at pantokratoren.de wrote: > Hello, > > a few days ago I tried to install rtl-sdr on my raspberry pi. I'm > using a dvb-t usb stick with Realtek, RTL2838UHIDIR chipset. I build > the software following the guide in the wiki. I used two additional > switches: cmake ../ -DINSTALL_UDEV_RULES=ON -DDETACH_KERNEL_DRIVER=ON > > After installing the software I created a blacklist in cd /etc/modprobe.d: > > blacklist dvb_usb_rtl28xxu > blacklist rtl2832 > blacklist rtl2830 > blacklist rtl2838 > > After rebooting the device I tried to test rtl-sdr with rtl_test -t > and got this result: > > Found 1 device(s): > 0: Realtek, RTL2838UHIDIR, SN: 00000001 > > Using device 0: Generic RTL2832U OEM > usb_claim_interface error -6 > Failed to open rtlsdr device #0. > > I don't know how to fix this error. I tried many suggestions found via > google but it doesn't work. > > Can someone help me to fix this? > > Thanks for your help!! > > Joachim > From pantos at pantokratoren.de Wed Apr 5 20:11:22 2017 From: pantos at pantokratoren.de (pantos at pantokratoren.de) Date: Wed, 5 Apr 2017 22:11:22 +0200 Subject: rtl_test -t results in failed to open rtlsdr device #0. In-Reply-To: References: Message-ID: <886160f9-4733-4db8-02ee-a4997734c466@pantokratoren.de> Hi Marcus, thanks for your reply. To install the udev-rules I used sudo cp ./rtl-sdr/rtl-sdr.rules /etc/udev/rules.d/ The suggested way sudo make install-udev-rules doesn't worked for me (Error: make: *** No rule to make target 'install-udev-rules'. Schluss.). Or is this the wrong way? Sorry for this stupid question but I'm a little bit lost... Best regards Joachim Am 05.04.2017 um 14:35 schrieb Marcus M?ller: > Hi Joachim, > > "I tried many [...] but it doesn't work": so, what exactly you've tried > would be kind of relevant :) > > I'll go out on a limb here based on statistics and say: you might have > missed what > http://osmocom.org/projects/sdr/wiki/rtl-sdr#rtlsdr-library-amp-capture-tool > says: > > sudo make install-udev-rules > > Best regards, > Marcus > > On 05.04.2017 07:30, pantos at pantokratoren.de wrote: >> Hello, >> >> a few days ago I tried to install rtl-sdr on my raspberry pi. I'm >> using a dvb-t usb stick with Realtek, RTL2838UHIDIR chipset. I build >> the software following the guide in the wiki. I used two additional >> switches: cmake ../ -DINSTALL_UDEV_RULES=ON -DDETACH_KERNEL_DRIVER=ON >> >> After installing the software I created a blacklist in cd /etc/modprobe.d: >> >> blacklist dvb_usb_rtl28xxu >> blacklist rtl2832 >> blacklist rtl2830 >> blacklist rtl2838 >> >> After rebooting the device I tried to test rtl-sdr with rtl_test -t >> and got this result: >> >> Found 1 device(s): >> 0: Realtek, RTL2838UHIDIR, SN: 00000001 >> >> Using device 0: Generic RTL2832U OEM >> usb_claim_interface error -6 >> Failed to open rtlsdr device #0. >> >> I don't know how to fix this error. I tried many suggestions found via >> google but it doesn't work. >> >> Can someone help me to fix this? >> >> Thanks for your help!! >> >> Joachim >> From marcus.mueller at ettus.com Wed Apr 5 21:55:27 2017 From: marcus.mueller at ettus.com (=?UTF-8?Q?Marcus_M=c3=bcller?=) Date: Wed, 5 Apr 2017 23:55:27 +0200 Subject: rtl_test -t results in failed to open rtlsdr device #0. In-Reply-To: <886160f9-4733-4db8-02ee-a4997734c466@pantokratoren.de> References: <886160f9-4733-4db8-02ee-a4997734c466@pantokratoren.de> Message-ID: <77367100-efdb-758b-1850-56397e820329@ettus.com> Hi Joachim, absolutely no stupid questions involved! So, ok, assuming you rebooted or ran "sudo udevadm control --reload" and re-plugged the device, we have to rule out: * the dvb-t kernel module still being loaded: plug in stick, run "lsmod|grep rtl", look for suspicious lines * the stick not having standard USB ids: plug in stick. run "lsusb". find line describing stick VID:PID. do these match any line in rtl-sdr.rules? * some other kernel shenanigans. Run "dmesg -w" to watch dmesg, plug in stick, see whether suspicious stuff happens to the kernel :) Best regards, Marcus On 05.04.2017 22:11, pantos at pantokratoren.de wrote: > Hi Marcus, > > thanks for your reply. To install the udev-rules I used > > sudo cp ./rtl-sdr/rtl-sdr.rules /etc/udev/rules.d/ > > The suggested way > > sudo make install-udev-rules > > doesn't worked for me (Error: make: *** No rule to make target 'install-udev-rules'. Schluss.). > > Or is this the wrong way? > > Sorry for this stupid question but I'm a little bit lost... > > Best regards > > Joachim > > > Am 05.04.2017 um 14:35 schrieb Marcus M?ller: >> Hi Joachim, >> >> "I tried many [...] but it doesn't work": so, what exactly you've tried >> would be kind of relevant :) >> >> I'll go out on a limb here based on statistics and say: you might have >> missed what >> http://osmocom.org/projects/sdr/wiki/rtl-sdr#rtlsdr-library-amp-capture-tool >> says: >> >> sudo make install-udev-rules >> >> Best regards, >> Marcus >> >> On 05.04.2017 07:30, pantos at pantokratoren.de wrote: >>> Hello, >>> >>> a few days ago I tried to install rtl-sdr on my raspberry pi. I'm >>> using a dvb-t usb stick with Realtek, RTL2838UHIDIR chipset. I build >>> the software following the guide in the wiki. I used two additional >>> switches: cmake ../ -DINSTALL_UDEV_RULES=ON -DDETACH_KERNEL_DRIVER=ON >>> >>> After installing the software I created a blacklist in cd /etc/modprobe.d: >>> >>> blacklist dvb_usb_rtl28xxu >>> blacklist rtl2832 >>> blacklist rtl2830 >>> blacklist rtl2838 >>> >>> After rebooting the device I tried to test rtl-sdr with rtl_test -t >>> and got this result: >>> >>> Found 1 device(s): >>> 0: Realtek, RTL2838UHIDIR, SN: 00000001 >>> >>> Using device 0: Generic RTL2832U OEM >>> usb_claim_interface error -6 >>> Failed to open rtlsdr device #0. >>> >>> I don't know how to fix this error. I tried many suggestions found via >>> google but it doesn't work. >>> >>> Can someone help me to fix this? >>> >>> Thanks for your help!! >>> >>> Joachim >>> From chibill110 at gmail.com Fri Apr 7 17:50:45 2017 From: chibill110 at gmail.com (Bill Gaylord) Date: Fri, 7 Apr 2017 12:50:45 -0500 Subject: No 64-bit librtlsdr for windows. Message-ID: Hello. So I have ran into a small problem. I used a python library called pyrtlsdr which uses ctypes to interact with librtlsdr. But when I upgraded my python form 32 bit to 64 bit the library no longer works because the librtlsdr.dll is 32 bit not 64. So has anyone had luck compiling a 64 bit version of librtlsdr? Or knows how to? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pantos at pantokratoren.de Fri Apr 7 18:57:09 2017 From: pantos at pantokratoren.de (pantos at pantokratoren.de) Date: Fri, 7 Apr 2017 20:57:09 +0200 Subject: rtl_test -t results in failed to open rtlsdr device #0. In-Reply-To: <77367100-efdb-758b-1850-56397e820329@ettus.com> References: <886160f9-4733-4db8-02ee-a4997734c466@pantokratoren.de> <77367100-efdb-758b-1850-56397e820329@ettus.com> Message-ID: <7a4bec76-9862-9406-de92-16cc7b7181ab@pantokratoren.de> Hi Marcus, thanks for your extensive help!! I tried out your suggestions. I rebooted the raspberry pi many times ;-) > * the dvb-t kernel module still being loaded: plug in stick, run "lsmod|grep rtl", look for suspicious lines With "lsmod|grep rtl" I get no results. > * the stick not having standard USB ids: plug in stick. run "lsusb". find line describing stick VID:PID. do these match any line in rtl-sdr.rules? The result is: Bus 001 Device 005: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T I think this match my rtl-sdr.rules line with "blacklist dvb_usb_rtl28xxu" and "blacklist rtl2838"? > * some other kernel shenanigans. Run "dmesg -w" to watch dmesg, plug in stick, see whether suspicious stuff happens to the kernel :) [253111.992530] usb 1-1.4: new high-speed USB device number 5 using dwc_otg [253112.104864] usb 1-1.4: New USB device found, idVendor=0bda, idProduct=2838 [253112.104901] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [253112.104919] usb 1-1.4: Product: RTL2838UHIDIR [253112.104934] usb 1-1.4: Manufacturer: Realtek [253112.104949] usb 1-1.4: SerialNumber: 00000001 Seems to be normal? Do you see anything suspicious? Best regards, Joachim Am 05.04.2017 um 23:55 schrieb Marcus M?ller: > Hi Joachim, > > absolutely no stupid questions involved! > > So, ok, assuming you rebooted or ran "sudo udevadm control --reload" and > re-plugged the device, we have to rule out: > > * the dvb-t kernel module still being loaded: plug in stick, run > "lsmod|grep rtl", look for suspicious lines > * the stick not having standard USB ids: plug in stick. run "lsusb". > find line describing stick VID:PID. do these match any line in > rtl-sdr.rules? > * some other kernel shenanigans. Run "dmesg -w" to watch dmesg, plug in > stick, see whether suspicious stuff happens to the kernel :) > > Best regards, > > Marcus > > > On 05.04.2017 22:11, pantos at pantokratoren.de wrote: >> Hi Marcus, >> >> thanks for your reply. To install the udev-rules I used >> >> sudo cp ./rtl-sdr/rtl-sdr.rules /etc/udev/rules.d/ >> >> The suggested way >> >> sudo make install-udev-rules >> >> doesn't worked for me (Error: make: *** No rule to make target 'install-udev-rules'. Schluss.). >> >> Or is this the wrong way? >> >> Sorry for this stupid question but I'm a little bit lost... >> >> Best regards >> >> Joachim >> >> >> Am 05.04.2017 um 14:35 schrieb Marcus M?ller: >>> Hi Joachim, >>> >>> "I tried many [...] but it doesn't work": so, what exactly you've tried >>> would be kind of relevant :) >>> >>> I'll go out on a limb here based on statistics and say: you might have >>> missed what >>> http://osmocom.org/projects/sdr/wiki/rtl-sdr#rtlsdr-library-amp-capture-tool >>> says: >>> >>> sudo make install-udev-rules >>> >>> Best regards, >>> Marcus >>> >>> On 05.04.2017 07:30, pantos at pantokratoren.de wrote: >>>> Hello, >>>> >>>> a few days ago I tried to install rtl-sdr on my raspberry pi. I'm >>>> using a dvb-t usb stick with Realtek, RTL2838UHIDIR chipset. I build >>>> the software following the guide in the wiki. I used two additional >>>> switches: cmake ../ -DINSTALL_UDEV_RULES=ON -DDETACH_KERNEL_DRIVER=ON >>>> >>>> After installing the software I created a blacklist in cd /etc/modprobe.d: >>>> >>>> blacklist dvb_usb_rtl28xxu >>>> blacklist rtl2832 >>>> blacklist rtl2830 >>>> blacklist rtl2838 >>>> >>>> After rebooting the device I tried to test rtl-sdr with rtl_test -t >>>> and got this result: >>>> >>>> Found 1 device(s): >>>> 0: Realtek, RTL2838UHIDIR, SN: 00000001 >>>> >>>> Using device 0: Generic RTL2832U OEM >>>> usb_claim_interface error -6 >>>> Failed to open rtlsdr device #0. >>>> >>>> I don't know how to fix this error. I tried many suggestions found via >>>> google but it doesn't work. >>>> >>>> Can someone help me to fix this? >>>> >>>> Thanks for your help!! >>>> >>>> Joachim >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From cjm at crimtec.com Thu Apr 13 22:24:02 2017 From: cjm at crimtec.com (Chris Miller) Date: Thu, 13 Apr 2017 18:24:02 -0400 Subject: R820T I2C Message-ID: <0235350D-B484-4C83-92FA-4BC98076E6B4@crimtec.com> Hi, To teach myself Swift, I?m writing my own version of librtlsdr (in Swift on MacOS). I?m confused about the I2C interface between the RTL2832U and the R820T. It seems the first 16 registers of the R820T can be read but not any after that. I get a pipe stall when trying to read more than 16 bytes. Is this true or am I missing something? Is this why the shadow registers are used to maintain the state of the R820T?s registers? Thanks Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkelly at xevo.com Fri Apr 21 17:44:11 2017 From: mkelly at xevo.com (Martin Kelly) Date: Fri, 21 Apr 2017 10:44:11 -0700 Subject: [PATCH] remove -I/usr/include in pkg-config Message-ID: <1492796651-10649-1-git-send-email-mkelly@xevo.com> This shouldn't be necessary as it's part of the default compiler include paths anyway. Morever, it can cause GCC 6 C++ build failures in downstream packages when combined with QMake (such as qtmultimedia-rtlfm-radio-plugin). Fix these issues by removing it. Signed-off-by: Martin Kelly --- librtlsdr.pc.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/librtlsdr.pc.in b/librtlsdr.pc.in index 5e55049..84b6d0c 100644 --- a/librtlsdr.pc.in +++ b/librtlsdr.pc.in @@ -6,6 +6,6 @@ includedir=@includedir@ Name: RTL-SDR Library Description: C Utility Library Version: @VERSION@ -Cflags: -I${includedir}/ @RTLSDR_PC_CFLAGS@ +Cflags: @RTLSDR_PC_CFLAGS@ Libs: -L${libdir} -lrtlsdr -lusb-1.0 Libs.private: @RTLSDR_PC_LIBS@ -- 2.1.4 From 246tnt at gmail.com Fri Apr 21 20:33:30 2017 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 21 Apr 2017 22:33:30 +0200 Subject: [PATCH] remove -I/usr/include in pkg-config In-Reply-To: <1492796651-10649-1-git-send-email-mkelly@xevo.com> References: <1492796651-10649-1-git-send-email-mkelly@xevo.com> Message-ID: On Fri, Apr 21, 2017 at 7:44 PM, Martin Kelly wrote: > This shouldn't be necessary as it's part of the default compiler include > paths anyway. Huh ... no. It's only part of the default compiler include if you installed in /usr ... but if you installed in a custom prefix, this will be required and that's the whole point of the .pc file. Cheers, Sylvain From mkelly at xevo.com Fri Apr 21 20:56:36 2017 From: mkelly at xevo.com (Martin Kelly) Date: Fri, 21 Apr 2017 13:56:36 -0700 Subject: [PATCH] remove -I/usr/include in pkg-config In-Reply-To: References: <1492796651-10649-1-git-send-email-mkelly@xevo.com> Message-ID: <11754275-43b3-6741-ce1f-f91c0f37bcb8@xevo.com> On 04/21/2017 01:33 PM, Sylvain Munaut wrote: > On Fri, Apr 21, 2017 at 7:44 PM, Martin Kelly wrote: >> This shouldn't be necessary as it's part of the default compiler include >> paths anyway. > > Huh ... no. > > It's only part of the default compiler include if you installed in > /usr ... but if you installed in a custom prefix, this will be > required and that's the whole point of the .pc file. > Let me provide a bit more context. I created this patch because a package in Openembedded (qtmultimedia-rtlfm-radio-plugin) relies on the .pc file for rtl-sdr, which injects -I /usr/include. That package uses QMake, when then translates the include into -isystem /usr/include. This breaks GCC 6's #include_next directive, as documented by GCC and Qt: GCC bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129 Qt bug report: https://bugreports.qt.io/browse/QTBUG-53367 In both cases, the maintainers state that the right solution is to not do -I /usr/include. AFAICT, this means there are two options: (a) Don't export -I /usr/include in the .pc file. (b) Manually remove -I /usr/include for anyone who compiles with GCC 6 and needs to use rtl-sdr. Solution (a) seems cleaner to me. If you have another way that avoids breaking packages that include rtl-sdr and use GCC 6, I'm happy to hear it. In my case, when I ask GCC for the default include path, I'm seeing /usr/include listed. In the case of Openembedded, the cross-compile toolchain already takes care of prefix issues by using --sysroot. GCC default include paths: martin at columbia:~$ echo | gcc -E -Wp,-v - ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-linux-gnu/4.9/include /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/4.9/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. # 1 "" # 1 "" # 1 "" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 1 "" 2 # 1 "" From 246tnt at gmail.com Fri Apr 21 22:42:27 2017 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 22 Apr 2017 00:42:27 +0200 Subject: [PATCH] remove -I/usr/include in pkg-config In-Reply-To: <11754275-43b3-6741-ce1f-f91c0f37bcb8@xevo.com> References: <1492796651-10649-1-git-send-email-mkelly@xevo.com> <11754275-43b3-6741-ce1f-f91c0f37bcb8@xevo.com> Message-ID: > In both cases, the maintainers state that the right solution is to not do -I > /usr/include. AFAICT, this means there are two options: Not really no ... They say to not use the -isystem /usr/include My opinion there is that qmake is broken doing the translation from -Ixxx to -isystem xxx blindly when both don't have _exactly_ the same semantic. QMake should check the system include list when doing the translation and omit the system ones to compensate for the difference of behavior of -I vs -isystem. > (a) Don't export -I /usr/include in the .pc file. > > (b) Manually remove -I /usr/include for anyone who compiles with GCC 6 and > needs to use rtl-sdr. > > Solution (a) seems cleaner to me. If you have another way that avoids > breaking packages that include rtl-sdr and use GCC 6, I'm happy to hear it. Well (a) is fine ... but you can only remove /usr/include ... not ${includedir} So you need to test is includedir is indeed /usr/include and then you can omit it but if not, then you need to leave it. Cheers, Sylvain From mkelly at xevo.com Fri Apr 21 23:39:32 2017 From: mkelly at xevo.com (Martin Kelly) Date: Fri, 21 Apr 2017 16:39:32 -0700 Subject: [PATCH] remove -I/usr/include in pkg-config In-Reply-To: References: <1492796651-10649-1-git-send-email-mkelly@xevo.com> <11754275-43b3-6741-ce1f-f91c0f37bcb8@xevo.com> Message-ID: <5f96ee5b-7a97-5917-331e-cc28398cb3cb@xevo.com> On 04/21/2017 03:42 PM, Sylvain Munaut wrote: >> In both cases, the maintainers state that the right solution is to not do -I >> /usr/include. AFAICT, this means there are two options: > > Not really no ... > > They say to not use the -isystem /usr/include > > My opinion there is that qmake is broken doing the translation from > -Ixxx to -isystem xxx blindly when both don't have _exactly_ the same > semantic. QMake should check the system include list when doing the > translation and omit the system ones to compensate for the difference > of behavior of -I vs -isystem. > I see your point and agree that QMake's behavior is undesirable. I also agree that removing includedir will break compiling with --prefix without --sysroot; from a quick survey of a bunch of .pc files, they all include either -I${includedir} or -I${includedir}/project. The second category will not hit these issues while the first will. Bugs have been filed on QMake regarding this in the past: https://bugreports.qt.io/browse/QTBUG-53375 https://bugreports.qt.io/browse/QTBUG-53367 A patch was even drafted to fix it: https://codereview.qt-project.org/#/c/159215 The patch was abandoned with this reasoning: "The idea is that -isystem also suppresses warnings from files found in those paths. We'd like to keep that functionality. The problem is that -isystem /usr/include, specifically, reorders that path." The workaround in qtBittorrent was to explicitly remove the include/libs that QMake had added: https://github.com/qbittorrent/qBittorrent/commit/d9d49b6d0bb71ccc086968f2626b98a662fb6f3a Certainly not ideal, but it may be the only solution. > >> (a) Don't export -I /usr/include in the .pc file. >> >> (b) Manually remove -I /usr/include for anyone who compiles with GCC 6 and >> needs to use rtl-sdr. >> >> Solution (a) seems cleaner to me. If you have another way that avoids >> breaking packages that include rtl-sdr and use GCC 6, I'm happy to hear it. > > Well (a) is fine ... but you can only remove /usr/include ... not ${includedir} > > So you need to test is includedir is indeed /usr/include and then you > can omit it but if not, then you need to leave it. > This could work, but it still would break some machine that uses somewhere else for system compiler path. Perhaps doing what qtbittorrent did and just removing what QMake adds is the best solution, absent QMake fixing it. From mkelly at xevo.com Sat Apr 22 00:54:51 2017 From: mkelly at xevo.com (Martin Kelly) Date: Fri, 21 Apr 2017 17:54:51 -0700 Subject: [PATCH] remove -I/usr/include in pkg-config In-Reply-To: <5f96ee5b-7a97-5917-331e-cc28398cb3cb@xevo.com> References: <1492796651-10649-1-git-send-email-mkelly@xevo.com> <11754275-43b3-6741-ce1f-f91c0f37bcb8@xevo.com> <5f96ee5b-7a97-5917-331e-cc28398cb3cb@xevo.com> Message-ID: <366fd6ec-d7b7-e285-279e-526aa19386f9@xevo.com> On 04/21/2017 04:39 PM, Martin Kelly wrote: > On 04/21/2017 03:42 PM, Sylvain Munaut wrote: >> >> Well (a) is fine ... but you can only remove /usr/include ... not >> ${includedir} >> >> So you need to test is includedir is indeed /usr/include and then you >> can omit it but if not, then you need to leave it. >> > > This could work, but it still would break some machine that uses > somewhere else for system compiler path. Perhaps doing what qtbittorrent > did and just removing what QMake adds is the best solution, absent QMake > fixing it. OK, I have fixed it in the manner that qtbittorrent did (manually removing -isystem /usr/include flags from what QMake provides). It's not pretty, but if QMake's behaviors remains as it is, I'm not sure there's much else to do. Feel free to drop this patch. From jentilel07 at gmail.com Sun Apr 9 00:09:09 2017 From: jentilel07 at gmail.com (Luke Jentile) Date: Sun, 09 Apr 2017 00:09:09 -0000 Subject: Astrum TV 100 USB TV device dongle. Does this support SDR? I use it to tune TV, seems it doesn't have radio or I don't know how to find it setup. Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: