http://community.qnx.com/sf/discussion/do/listTopics/projects.toolchain/discussion.core_development_tools Posts for General http://community.qnx.com/sf/go/post122271 You can put those commands in the testscript.py targetIP=xxx.xxx.xxx.xxx binpath='D:/Project/develop/sample' gdb.execute(f"target qnx {targetIP}:8000") gdb.execute(f"file {binpath}") In gdb console, use `source` command to execute the script. (gdb) > source /path/to/testscript.py To execute the script from outside gdb CLI: # ntoaarch64-gdb --init-eval-command="source /path/to/testscript.py" Bonus: You can run an interactive python shell in the gdb session to test your commands first: (gdb) > python-interactive >>> gdb.execute("info inferiors") >>> # For automation, it might be useful to store the gdb command result to a variable: >>> pidlist = gdb.execute("info pidlist", to_string=True) Refence: - https://sourceware.org/gdb/onlinedocs/gdb/Basic-Python.html#Basic-Python Fri, 19 May 2023 16:23:03 GMT http://community.qnx.com/sf/go/post122271 Peter Nguyen 2023-05-19T16:23:03Z http://community.qnx.com/sf/go/post122239 Momentics will spawn a pdebug process on the target, via qconn, for you. For command line GDB you need to manually launch an instance of pdebug on your target. Fri, 28 Apr 2023 16:03:11 GMT http://community.qnx.com/sf/go/post122239 Jim Sleeth 2023-04-28T16:03:11Z http://community.qnx.com/sf/go/post122124 OS: QNX 11.1 Python: 3.10 Host OS: Windows SDP: qnx710 We are using QualCOMM Snapdragon A1B Sample hardware which has QNX OS and supports gdb. We can run through momentics IDE. I'm trying to debug my application which will be running on QNX. When I execute the below python program, it doesn't execute os.system('file {}'.format(binpath)). It just stopped at gdb prompt. ##Test Program import os import subprocess ip_to_check = ('***.***.*.*') targetIP_Port = ('***.***.*.*:****') qnxPath = ('C:/qnx710/host/win64/x86_64/usr/bin') binpath = ('D:/Project/develop/sample') #FILE = ('gdbInit.txt') os.system('cls') returnStatus = os.system('ping -n 4 {}'.format(ip_to_check)) print('\n') print('#'*60) if returnStatus == 1: print('Please check the target connection, restart and try again...') print('#'*60) else: cwd=os.getcwd() print("Current Working Directory: {0}".format(cwd)) print('\n') print('#'*60) print('Changing Directory to qnx path') os.chdir(qnxPath) cwd=os.getcwd() print("Current Working Directory: {0}".format(cwd)) print('\n') print('#'*60) os.system('aarch64-unknown-nto-qnx7.1.0-gdb.exe') os.system('file {}'.format(binpath)) If I manually execute in command prompt, the symbols are read. C:/qnx710/host/win64/x86_64/usr/bin/aarch64-unknown-nto-qnx7.1.0-gdb.exe D:/Project/develop/sample Has anyone tried to automate remote debugging the application using gdb on QNX OS. Can you please point out what is wrong in the above script? Wed, 01 Feb 2023 04:21:42 GMT http://community.qnx.com/sf/go/post122124 Preethi Selvaraju 2023-02-01T04:21:42Z http://community.qnx.com/sf/go/post121942 I have been able to compile and create an executable for gdb-9.2 for qnx 7.1 running on x86_64 architecture and whenever it runs it does not segfault but it also does not run properly. It exits after not recognizing x86_64 qnx as a supported gdb architecture. Does anyone have any insight on what may need to be done in order to add support for a new gdb architecture specific for qnx? It looks like there are others trying to do a similar thing based on some other posts as well: https://community.qnx.com/sf/discussion/do/listPosts/projects.toolchain/discussion.core_development_tools.topc28211 Mon, 26 Sep 2022 17:31:37 GMT http://community.qnx.com/sf/go/post121942 Tyler Bernhardt(deleted) 2022-09-26T17:31:37Z http://community.qnx.com/sf/go/post121941 As stated above, it's not officially supported by QNX. However, the source code is available. My team member has recently compiled it on QNX 7.1. We haven't gotten it to successfully run just yet. We fixed a reported error ("working directory: not a directory"), but it looks like the next step is creating some initialization files to get gdb to recognize x86_64 qnx (our target) as a supported architecture. OP: have you tried compiling yourself? Mon, 26 Sep 2022 14:21:57 GMT http://community.qnx.com/sf/go/post121941 Jim P(deleted) 2022-09-26T14:21:57Z http://community.qnx.com/sf/go/post121905 may also want to use dumper, so you can do postmortem debugging. http://www.qnx.com/developers/docs/7.1/#com.qnx.doc.neutrino.utilities/topic/d/dumper.html Fri, 26 Aug 2022 17:18:10 GMT http://community.qnx.com/sf/go/post121905 John Kearney 2022-08-26T17:18:10Z http://community.qnx.com/sf/go/post121903 For SDP7.1 only remote debugging is supported. To do this you run an application called pdebug on your target and you run gdb on your Windows host. http://www.qnx.com/developers/docs/7.1/com.qnx.doc.neutrino.utilities/topic/p/pdebug.html http://www.qnx.com/developers/docs/7.1/#com.qnx.doc.neutrino.utilities/topic/g/gdb.html Fri, 26 Aug 2022 11:18:21 GMT http://community.qnx.com/sf/go/post121903 Jim Sleeth 2022-08-26T11:18:21Z http://community.qnx.com/sf/go/post121902 Hi Team, My host OS is Windows and QNX OS is on QualComm Snapdragon Ride platform hardware. We are using QNX 7.1.0 SDP and SDK is 11.1. We are unable to run our application through QNX Momentics IDE[We are discussing with the technical team]. Our application crashes when we run on QNX OS. Can we run gdb directly on QNX OS without Momentics IDE and host OS like how we use valgrind tool on QNX OS? https://www.qnx.com/developers/docs/7.0.0/#com.qnx.doc.hypervisor.user/topic/debug/gdb.html The above page states we need to connect to QNX OS through host OS remotely. Whether QNX Software Centre has GDB tool like it has valgrind? So that we can copy gdb binaries to QNX OS and run directly? Please someone share idea on how to do this. Thu, 25 Aug 2022 04:00:56 GMT http://community.qnx.com/sf/go/post121902 Preethi Selvaraju 2022-08-25T04:00:56Z http://community.qnx.com/sf/go/post121620 Hi Jim, thanks for the answer and details about libc. Do you think there is a chance of fixing the linking issues by adapting the linker parameters, or will there be deeper issues like ABI incompatibilities (assuming Rust code only; I'm sure we would get them when trying to link against C++ code). I was afraid that there was no progress with Rust. Are there plans to support it any time soon? Using Rust would help us to stay competitive when implementing complex applications. Kind regards, Florian Mon, 11 Oct 2021 14:37:38 GMT http://community.qnx.com/sf/go/post121620 Florian Bartels 2021-10-11T14:37:38Z http://community.qnx.com/sf/go/post121619 Hi Florian First, I know of no successful Rust on QNX/NTO. However; your first try won't work as there are too many differences between glibc and the NTO libc. Yes Linux does, depending on your distribution, provide a lot of POSIX API(s), but for instance the POSIX threads are in a separate library pthread library on Linux, but contained within the NTO libc. This is where many of your missing symbols may have come from, the differences between library contents. Jim Fri, 08 Oct 2021 20:10:36 GMT http://community.qnx.com/sf/go/post121619 Jim Sleeth 2021-10-08T20:10:36Z http://community.qnx.com/sf/go/post121615 Hi, I'm interested to know if anybody tried to compile a Rust application for QNX? I wasn't able to find any information about this. (Cross) Compiling for Linux but linking using qcc for QNX fails due to a lot of missing symbols (I hoped this would work as both Linux and QNX use POSIX APIs). Thanks and kind regards Wed, 06 Oct 2021 18:39:45 GMT http://community.qnx.com/sf/go/post121615 Florian Bartels 2021-10-06T18:39:45Z http://community.qnx.com/sf/go/post121128 Good day, everybody. I try to use gcc 4.8.3 compiler and binutils 2.25 with QNX650 installation. So, I have copied "host" and "target" directories from archives of gcc and binutils into my installation. Then, I try to compile "helloworld" C program. It was succesfull. But, when I try to compile CPP program, I have get an error: "QCC -V 4.8.3,gcc_ntox86_gpp hello.cpp .../target/qnx6/x86/lib/gcc/4.8.3/libstdc++.so: undefined reference to `dl_iterate_phdr' cc: ...host/win32/x86/usr/bin/i486-pc-nto-qnx6.6.0-ld caught signal 1" Does everybody have any ideas, how to solve this reference? ==========There is hello.cpp:================= #include <iostream> int main(int c, char* av[]){ std::cout << "Hello world" << std::endl; } ========================================== With best regards. Fri, 27 Nov 2020 20:49:50 GMT http://community.qnx.com/sf/go/post121128 Pavel Kopylov(deleted) 2020-11-27T20:49:50Z http://community.qnx.com/sf/go/post120155 Is it possible to install GCC4.8.1 for QNX6.4.1 development tools? My targets are PPC arch and I am hoping to be able to take advantage of C++11 in my development. Thu, 16 Jan 2020 18:23:55 GMT http://community.qnx.com/sf/go/post120155 Danny Yen(deleted) 2020-01-16T18:23:55Z http://community.qnx.com/sf/go/post120086 Sorry forgot to mention it is for aarch64le architectue. Tue, 26 Nov 2019 14:47:21 GMT http://community.qnx.com/sf/go/post120086 Roberto Alejandro Flores Estrada 2019-11-26T14:47:21Z http://community.qnx.com/sf/go/post120085 Hello I'm having the same problem, my version is libstdc++.so.6.0.21, is there a link to download the sym file? Thanks in advance. Tue, 26 Nov 2019 14:46:13 GMT http://community.qnx.com/sf/go/post120085 Roberto Alejandro Flores Estrada 2019-11-26T14:46:13Z http://community.qnx.com/sf/go/post120002 My friend is doing a academic project with QNX hypervisor 2.0. We have trouble in finding the right hardware for development. AFAIK hypervisor needs processor based on ARM V8A architecture. Raspberry pi 3 comes with Broadcom SoC which features ARM Cortex A53 processor which is of the above mentioned architecture. Could you help us to find the BSP for this hardware? Or suggest alternate hardware (Costs less than 5000INR/100$) which can support hypervisor 2.0 with a BSP available. Thank you. Fri, 27 Sep 2019 11:24:47 GMT http://community.qnx.com/sf/go/post120002 Dharani kumar Srinivasan(deleted) 2019-09-27T11:24:47Z http://community.qnx.com/sf/go/post119979 Hello, Is there any support for the -fsanitize-thread flag for QNX 7.0? I tried to compile with the flag this afternoon, but it looks like libtsan might be missing. Is there a way to build the thread sanitizer library if it is missing or not officially supported? Thanks, Aaron Tue, 24 Sep 2019 22:00:05 GMT http://community.qnx.com/sf/go/post119979 Aaron Husz 2019-09-24T22:00:05Z http://community.qnx.com/sf/go/post119754 Hi, Our product is running on QNX and CPU is PPC440ep. The CAN bus controller is MCP2515 chip which is on SPI communication. I am going to write a driver to support the CAN protocol. I am wondering where should I get start it? Is there any device driver guide I can go through? QNX is quite different than linux in terms of device driver. Thanks in advance. Tue, 11 Jun 2019 20:17:30 GMT http://community.qnx.com/sf/go/post119754 Chris Liang(deleted) 2019-06-11T20:17:30Z http://community.qnx.com/sf/go/post119753 > Also I noticed that target folder contains only includes and no libraries. It seems that libraries have been installed > into "qnx660/host/linux/x86/usr/arm-unknown-nto-qnx6.6.0eabi" instead of "qnx660/target/qnx6/usr/lib" instead of "qnx660/target/qnx6/armle-v7/lib" Mon, 10 Jun 2019 22:39:57 GMT http://community.qnx.com/sf/go/post119753 fn ln(deleted) 2019-06-10T22:39:57Z http://community.qnx.com/sf/go/post119752 I have just compiled gcc 5.4 (linux-x86-o-ntoarmeabi configuration) and installed it (into /opt/qnx660) Please refer to attached installation tree I noticed that there are no configuration files for qcc (as I see from http://community.qnx.com/sf/frs/do/downloadFile/projects.toolchain/frs.gcc.gcc_4_9/frs122422?dl=1 they should be in "qnx660/host/linux/x86/etc") Also I noticed that target folder contains only includes and no libraries. It seems that libraries have been installed into "qnx660/host/linux/x86/usr/arm-unknown-nto-qnx6.6.0eabi" instead of "qnx660/target/qnx6/usr/lib". It seems that some post installation configuration is required. So how to make the new compiler usable with qcc, where should I get the qcc config files? Mon, 10 Jun 2019 21:08:16 GMT http://community.qnx.com/sf/go/post119752 fn ln(deleted) 2019-06-10T21:08:16Z http://community.qnx.com/sf/go/post119744 Hello , My PCI program is crashing with below stack information, Any idea about it? I am not finding any information regarding these calls. Please help. #0 0x00000001008ddcd4 in hw_io_rd () from /home/tester/qnx700/target/qnx7/x86_64/lib/pci_hw-Intel_x86.so.2.0 #1 0x00000001008df300 in hw_rd () from /home/tester/qnx700/target/qnx7/x86_64/lib/pci_hw-Intel_x86.so.2.0 #2 0x00000001008d9cc9 in cfg_rd () from /home/tester/qnx700/target/qnx7/x86_64/lib/pci_hw-Intel_x86.so.2.0 #3 0x00000001002bf109 in pci_device_read_vid () from /home/tester/qnx700/target/qnx7/x86_64/lib/libpci.so.2.0 #4 0x00000001008df107 in hw_rd () from /home/tester/qnx700/target/qnx7/x86_64/lib/pci_hw-Intel_x86.so.2.0 #5 0x00000001008d9cc9 in cfg_rd () from /home/tester/qnx700/target/qnx7/x86_64/lib/pci_hw-Intel_x86.so.2.0 #6 0x00000001002bb2e1 in hwmod_load () from /home/tester/qnx700/target/qnx7/x86_64/lib/libpci.so.2.0 #7 0x00000001002be2ec in pci_device_read_ccode () from /home/tester/qnx700/target/qnx7/x86_64/lib/libpci.so.2.0 #8 0x0000000008048fc4 in main () Fri, 07 Jun 2019 12:47:11 GMT http://community.qnx.com/sf/go/post119744 Anand Shastry 2019-06-07T12:47:11Z http://community.qnx.com/sf/go/post119734 *Can you run the new compiler with qcc? Thu, 06 Jun 2019 20:27:43 GMT http://community.qnx.com/sf/go/post119734 fn ln(deleted) 2019-06-06T20:27:43Z http://community.qnx.com/sf/go/post119733 Hi Kevin Stallard! Have you succeed with creating config files for qcc? Can you run the compiler with new qcc? Thu, 06 Jun 2019 20:26:29 GMT http://community.qnx.com/sf/go/post119733 fn ln(deleted) 2019-06-06T20:26:29Z http://community.qnx.com/sf/go/post119722 Sorry I forgot about those informations: I'm running it on Windows 10, I think I'm using QNX 7.0.0 and qcc -V returns the following: 5.4.0,gcc_ntoaarch64le 5.4.0,gcc_ntoaarch64le_cxx 5.4.0,gcc_ntoaarch64le_gpp 5.4.0,gcc_ntoarmv7le 5.4.0,gcc_ntoarmv7le_cxx 5.4.0,gcc_ntoarmv7le_gpp 5.4.0,gcc_ntox86 (default) 5.4.0,gcc_ntox86_64 5.4.0,gcc_ntox86_64_cxx 5.4.0,gcc_ntox86_64_gpp 5.4.0,gcc_ntox86_cxx 5.4.0,gcc_ntox86_gpp Also, adding -Wc does not change the output: qcc -Wc,-DTYPE="unsigned int" main.c cc1: fatal error: "-DTYPE=unsigned int": Invalid argument compilation terminated. Mon, 03 Jun 2019 08:42:56 GMT http://community.qnx.com/sf/go/post119722 Tom Rouillard(deleted) 2019-06-03T08:42:56Z http://community.qnx.com/sf/go/post119721 What version of qcc. This works for me. qcc -DTYPE="unsigned int" test.c as a W/A you could try qcc -Wc,-DTYPE="unsigned int" test.c ________________________________________ From: Tom Rouillard [community-noreply@qnx.com] Sent: Wednesday, May 29, 2019 09:35 To: general-toolchain Subject: Qcc and spaces in arguments Hello, I'm trying to manually invoke qcc with some -D options which has some spaces in it: qcc -DTYPE="unsigned int" main.c This works fine using gcc, but fails with the following message with qcc: cc1: fatal error: "-DTYPE=unsigned int": Invalid argument This is the same kind of error that appears when trying to use spaces in paths. Am I missing something or is there a workaround? Cheers, Tom _______________________________________________ General http://community.qnx.com/sf/go/post119715 To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com Fri, 31 May 2019 19:48:26 GMT http://community.qnx.com/sf/go/post119721 John Kearney 2019-05-31T19:48:26Z http://community.qnx.com/sf/go/post119715 Hello, I'm trying to manually invoke qcc with some -D options which has some spaces in it: qcc -DTYPE="unsigned int" main.c This works fine using gcc, but fails with the following message with qcc: cc1: fatal error: "-DTYPE=unsigned int": Invalid argument This is the same kind of error that appears when trying to use spaces in paths. Am I missing something or is there a workaround? Cheers, Tom Wed, 29 May 2019 07:35:06 GMT http://community.qnx.com/sf/go/post119715 Tom Rouillard(deleted) 2019-05-29T07:35:06Z http://community.qnx.com/sf/go/post119586 hey this seems quite interesting. any progress so far? I'd love to contribute. Sat, 16 Mar 2019 17:48:12 GMT http://community.qnx.com/sf/go/post119586 bernardo araujo rodrigues(deleted) 2019-03-16T17:48:12Z http://community.qnx.com/sf/go/post119538 I should add, that I haven't tested this yet, I am currently validating that it installed and I can run the compiler with qcc. I think this may still be an issue. Once I get everything working, I'll write up any details that are necessary to make it work. At this point I suspect I need to create some gcc spec files (duplicate the 4.7.3 versions perhaps). I also don't see where the latest gcc libraries (libstdc++ for example) were installed. Just diving into what got built. Sun, 24 Feb 2019 07:27:32 GMT http://community.qnx.com/sf/go/post119538 Kevin Stallard(deleted) 2019-02-24T07:27:32Z http://community.qnx.com/sf/go/post119537 I have a solution to this in my previous post for this problem and a myriad of others that I was having. Turns out there are headerfiles missing from the libstdc++-v3/include/c folder. Thanks Kevin Sun, 24 Feb 2019 06:55:52 GMT http://community.qnx.com/sf/go/post119537 Kevin Stallard(deleted) 2019-02-24T06:55:52Z http://community.qnx.com/sf/go/post119536 Okay, got it all to build. Attached is my build_hooks file modified to build for qnx6.6 It turns out my main problem was that the libstdc++-v3/include/c directory was missing some files. They were present in the libstdc++-v3/include/c_global directory. I used the gcc 5.2 sources to see that the missing files didn't appear to have significant differences between 5.2's c and c_global directory, so I merely copied them from 8.2's c_global to 8.2's c directory and it magically built. Hope this helps someone who ventures down this road. Sun, 24 Feb 2019 06:54:07 GMT http://community.qnx.com/sf/go/post119536 Kevin Stallard(deleted) 2019-02-24T06:54:07Z http://community.qnx.com/sf/go/post119535 Sure is quiet around here these days.... Fri, 22 Feb 2019 10:12:53 GMT http://community.qnx.com/sf/go/post119535 Kevin Stallard(deleted) 2019-02-22T10:12:53Z http://community.qnx.com/sf/go/post119525 This seems to apply for both the 660_release and the gcc_8_2 builds. It appears gcc is being built correctly and the build process steps into building libstdc++-v3 libraries. What appears to be happening is when cmath is being included, it is trying to include math.h. Well, as you know there are numerous versions of math.h sprinkled about in the gcc_8_2 build directory, the /opt/qnx660/target/qnx6/user/include directory and the /usr/include directory of the host OS (linux in this case). What I am trying to understand is which math.h should be included when this library is being built? I suspect this also may apply to other header files found in the /opt/qnx660/target/qnx6/usr/include directory. The build instructions as posted on this site appear to be incomplete. I did modify the build_hooks file to ensure that it was using qnx660, but it seems there may be other things that need updating to get the proper math.h to be included with the build. Any help, suggestions or any other direction is greatly appreciated. Thank you! Kevin Fri, 15 Feb 2019 19:32:30 GMT http://community.qnx.com/sf/go/post119525 Kevin Stallard(deleted) 2019-02-15T19:32:30Z http://community.qnx.com/sf/go/post119524 Clearly I am doing something wrong, but I am not sure what it is. I tried building the 660_release and I am running into the same header file inclusion issues. It seems that xgcc when building the libraries is also including the headers from the /usr/include directory of the qnx660 target, and that this is messing things up. The question I need answered is: When building libstdc++-v3 using xgcc, should xgcc be including headers from the qnx660 installation or from some other source? Thanks Kevin Fri, 15 Feb 2019 18:44:24 GMT http://community.qnx.com/sf/go/post119524 Kevin Stallard(deleted) 2019-02-15T18:44:24Z http://community.qnx.com/sf/go/post119514 c_model in configure.host is set to 'c' instead of the default 'c_global'. This is preventing include paths for c_compatibility (which I think would include the correct math.h). I know there is probably a really good reason to have it set to 'c' for QNX.... Wed, 13 Feb 2019 20:28:54 GMT http://community.qnx.com/sf/go/post119514 Kevin Stallard(deleted) 2019-02-13T20:28:54Z http://community.qnx.com/sf/go/post119513 I think I have this issue sorted, bin utils needed an update, now using 2.30. However, there is one other issue I seem to be having. The include paths for building the gcc libraries is not including c_compatibility. This is preventing inclusions of header files such as math.h. Any feed back on this is appreciated. Thanks Kevin Wed, 13 Feb 2019 19:30:41 GMT http://community.qnx.com/sf/go/post119513 Kevin Stallard(deleted) 2019-02-13T19:30:41Z http://community.qnx.com/sf/go/post119506 Things seem to generally build well until I get to the point of building libgcc using xgcc. It tries to build unwind-dw2.c using position independent code and the assembler chokes on the resulting assembly file. /tmp/cciOo4Io.s: Assembler messages: /tmp/cciOo4Io.s:67: Error: invalid operands (.text and .text.unlikely sections) for `-' /tmp/cciOo4Io.s:68: Error: invalid operands (.text and .text.unlikely sections) for `-' /tmp/cciOo4Io.s:69: Error: invalid operands (.text and .text.unlikely sections) for `-' /tmp/cciOo4Io.s:70: Error: invalid operands (.text and .text.unlikely sections) for `-' /tmp/cciOo4Io.s:1566: Error: invalid operands (.text and .text.unlikely sections) for `-' /tmp/cciOo4Io.s:1567: Error: invalid operands (.text and .text.unlikely sections) for `-' /tmp/cciOo4Io.s:1568: Error: invalid operands (.text and .text.unlikely sections) for `-' /tmp/cciOo4Io.s:1569: Error: invalid operands (.text and .text.unlikely sections) for `-' /tmp/cciOo4Io.s:1570: Error: invalid operands (.text and .text.unlikely sections) for `-' /tmp/cciOo4Io.s:1571: Error: invalid operands (.text and .text.unlikely sections) for `-' /tmp/cciOo4Io.s:1572: Error: invalid operands (.text and .text.unlikely sections) for `-' /tmp/cciOo4Io.s:1573: Error: invalid operands (.text and .text.unlikely sections) for `-' /tmp/cciOo4Io.s:1574: Error: invalid operands (.text and .text.unlikely sections) for `-' /tmp/cciOo4Io.s:1575: Error: invalid operands (.text and .text.unlikely sections) for `-' /tmp/cciOo4Io.s:1576: Error: invalid operands (.text and .text.unlikely sections) for `-' /tmp/cciOo4Io.s:1577: Error: invalid operands (.text and .text.unlikely sections) for `-' /tmp/cciOo4Io.s:1578: Error: invalid operands (.text and .text.unlikely sections) for `-' /tmp/cciOo4Io.s:1579: Error: invalid operands (.text and .text.unlikely sections) for `-' /tmp/cciOo4Io.s:1580: Error: invalid operands (.text and .text.unlikely sections) for `-' /tmp/cciOo4Io.s:1581: Error: invalid operands (.text and .text.unlikely sections) for `-' /tmp/cciOo4Io.s:1582: Error: invalid operands (.text and .text.unlikely sections) for `-' /tmp/cciOo4Io.s:1583: Error: invalid operands (.text and .text.unlikely sections) for `-' /tmp/cciOo4Io.s:1584: Error: invalid operands (.text and .text.unlikely sections) for `-' /tmp/cciOo4Io.s:1585: Error: invalid operands (.text and .text.unlikely sections) for `-' /tmp/cciOo4Io.s:1586: Error: invalid operands (.text and .text.unlikely sections) for `-' /tmp/cciOo4Io.s:1587: Error: invalid operands (.text and .text.unlikely sections) for `-' Some of the lines in the resulting assembly that this errors out on are: .long _GLOBAL_OFFSET_TABLE_+[.-.L7] .long _GLOBAL_OFFSET_TABLE_+[.-.L18] .long _GLOBAL_OFFSET_TABLE_+[.-.L12] .long _GLOBAL_OFFSET_TABLE_+[.-.L7] .long _GLOBAL_OFFSET_TABLE_+[.-.L5] .long _GLOBAL_OFFSET_TABLE_+[.-.L4] .long _GLOBAL_OFFSET_TABLE_+[.-.L4] .long _GLOBAL_OFFSET_TABLE_+[.-.L4] .long _GLOBAL_OFFSET_TABLE_+[.-.L4] .long _GLOBAL_OFFSET_TABLE_+[.-.L19] .long _GLOBAL_OFFSET_TABLE_+[.-.L8] .long _GLOBAL_OFFSET_TABLE_+[.-.L7] .long _GLOBAL_OFFSET_TABLE_+[.-.L5] Ideas? Thanks Kevin Wed, 13 Feb 2019 07:15:32 GMT http://community.qnx.com/sf/go/post119506 Kevin Stallard(deleted) 2019-02-13T07:15:32Z http://community.qnx.com/sf/go/post119375 Hi What is the POSIX version of QNX SDP 7.0. When I try to compile some of the open source projects like Flutter, Boring SSL etc using QNX Tool chain some of the POSIX API's are not visible to the compiler though the header files are included. For ex: File operations like open,read, Some of the thread Interfaces like pthread_rwlock_t are not visible to the compiler, when I open the pthread.h from QNX SDK the structure is defined under POSIX version Macro, EXT_POSIX_200112 and other interfaces are defined under different POSIX version macros. Observed similar kind of declarations in signal.h as well. If I try to enable the macro the compiler ends up in error message saying Posix threads need 1003.1b 1993 or later. I would like to know what is the POSIX version supported by QNX 7.0 and How to access such API's declared under old POSIX version MACROS. Regards, Vijay Thu, 27 Dec 2018 10:24:00 GMT http://community.qnx.com/sf/go/post119375 Vijay Chinimilli 2018-12-27T10:24:00Z http://community.qnx.com/sf/go/post119371 Not officially, some work was done to support it, but we don't provide a toolchain for it or support it. so you will find __clang in some of our public headers. e.g. ${QNX_TARGET}/usr/include/_packpop.h:27: #if defined(__PRAGMA_PACK_PUSH_POP__) || defined(__clang__) ________________________________________ From: Vijay Chinimilli [community-noreply@qnx.com] Sent: Wednesday, December 19, 2018 13:42 To: general-toolchain Subject: Clang support inn QNX Hello, Is there any support of clang in QNX? _______________________________________________ General http://community.qnx.com/sf/go/post119370 To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com Wed, 19 Dec 2018 12:57:57 GMT http://community.qnx.com/sf/go/post119371 John Kearney 2018-12-19T12:57:57Z http://community.qnx.com/sf/go/post119370 Hello, Is there any support of clang in QNX? Wed, 19 Dec 2018 12:42:47 GMT http://community.qnx.com/sf/go/post119370 Vijay Chinimilli 2018-12-19T12:42:47Z http://community.qnx.com/sf/go/post119120 Why did you do that? 4) Renamed /opt/qnx650sp1-gcc483/host/linux/x86/etc/qcc/gcc/4.4.2 to /opt/qnx650sp1-gcc483/host/linux/x86/etc/qcc/gcc/4.8.3 ? There are configuration file in /etc folder that point to default versions of compilers and stuff, if you rename the file it will will brake these files. IDE uses these to find the right compiler. Also if get new gcc it should be in the same host folder at the other one or you have to edit QNX_HOST var for IDE and command line Mon, 17 Sep 2018 17:53:52 GMT http://community.qnx.com/sf/go/post119120 Elena Laskavaia 2018-09-17T17:53:52Z http://community.qnx.com/sf/go/post119098 Hi Bob, thank you for response! I've downloaded this archive linux-gcc-4.8.3-qnx65x.tar.gz http://community.qnx.com/sf/frs/do/downloadFile/projects.toolchain/frs.gcc.gcc_4_8/frs152089?dl=1 and unpacked it: # tar -xf linux-gcc-4.8.3-qnx65x.tar.gz -C /opt/qnx650-gcc483/ I get the same error. Fri, 14 Sep 2018 05:41:43 GMT http://community.qnx.com/sf/go/post119098 Vasilij Yanikeev(deleted) 2018-09-14T05:41:43Z http://community.qnx.com/sf/go/post119097 Hi Bob, thank you for response! I've downloaded this archive linux-gcc-4.8.3-qnx65x.tar.gz http://community.qnx.com/sf/frs/do/downloadFile/projects.toolchain/frs.gcc.gcc_4_8/frs152089?dl=1 and unpacked it: # tar -xf linux-gcc-4.8.3-qnx65x.tar.gz -C /opt/qnx650-gcc483/ I get the same error. Fri, 14 Sep 2018 05:41:42 GMT http://community.qnx.com/sf/go/post119097 Vasilij Yanikeev(deleted) 2018-09-14T05:41:42Z http://community.qnx.com/sf/go/post119096 Hi Bob, thank you for response! I've downloaded this archive linux-gcc-4.8.3-qnx65x.tar.gz http://community.qnx.com/sf/frs/do/downloadFile/projects.toolchain/frs.gcc.gcc_4_8/frs152089?dl=1 and unpacked it: # tar -xf linux-gcc-4.8.3-qnx65x.tar.gz -C /opt/qnx650-gcc483/ I get the same error. Fri, 14 Sep 2018 05:41:41 GMT http://community.qnx.com/sf/go/post119096 Vasilij Yanikeev(deleted) 2018-09-14T05:41:41Z http://community.qnx.com/sf/go/post119095 Hi Vasilij, It appears you have downloaded the tools for running on "self-hosted" NTO systems. Please try the linux-gcc-4.8.3-qnx65x.tar.gz archive which contains host\linux\x86\ Cheers, Bob Thu, 13 Sep 2018 15:49:54 GMT http://community.qnx.com/sf/go/post119095 Bob Powell 2018-09-13T15:49:54Z http://community.qnx.com/sf/go/post119094 Hello! I am trying to install GCC 4.8.3 to my QNX6.5 SDP on Linux. I did the follows: 1) Copied already installed version for backup: # cp -r /opt/qnx650 /opt/qnx650sp1 2) unpaked archive with GCC 4.8.3 (downloaded from here (http://community.qnx.com/sf/frs/do/viewRelease/projects.toolchain/frs.gcc.gcc_4_8) to /opt/qnx650: # tar -xfnto-gcc-4.8.3-qnx65x.tar.gz -C /opt/qnx650 3) unpaked binutils (downloaded from here http://community.qnx.com/sf/frs/do/listReleases/projects.toolchain/frs.binutils) : # tar -xfnto-binutils-2.25.tar.gz -C /opt/qnx650 4) Renamed /opt/qnx650sp1-gcc483/host/linux/x86/etc/qcc/gcc/4.4.2 to /opt/qnx650sp1-gcc483/host/linux/x86/etc/qcc/gcc/4.8.3 5) Launched Momentix IDE 7.0 and created new QNX C++ project: File->New->QNX Project->QNX Executable->C++ CPU x86 When I try to built such project I always get an error below: qcc -lang-c++ -Vgcc_ntox86 -c -Wp,-MMD,build/x86-debug/src/test.d,-MT,build/x86-debug/src/test.o -o build/x86-debug/src/test.o -Wall -fmessage-length=0 -g -O0 -fno-builtin src/test.cpp cc: unknown target 'gcc_ntox86+debug' cc: targets available in /opt/qnx650/host/linux/x86/etc/qcc/gcc: 4.8.3,gcc_ntomipsle_acpp 4.8.3,gcc_ntoarmle_ecpp 4.8.3,gcc_ntoarmv7le_acpp-ne 4.8.3,gcc_ntoarmle_ecpp-ne 4.8.3,gcc_ntoarmv7le_acpp 4.8.3,gcc_ntoppcbespe_ecpp-ne 4.8.3,gcc_ntoppcbespe_acpp 4.8.3,gcc_ntoppcbe_cpp-ne 4.8.3,gcc_ntomipsle 4.8.3,gcc_ntoarmle_acpp 4.8.3,gcc_ntoppcbespe 4.8.3,gcc_ntox86_cpp 4.8.3,gcc_ntox86_ecpp-ne 4.8.3,gcc_ntoarmv7le 4.8.3,gcc_ntoppcbe_acpp-ne 4.8.3,gcc_ntomipsbe_acpp 4.8.3,gcc_ntoppcbe 4.8.3,gcc_ntoppcbe_cpp 4.8.3,gcc_ntoshle_ecpp-ne 4.8.3,gcc_ntoshle_ecpp 4.8.3,gcc_ntoarmle_cpp 4.8.3,gcc_ntomipsle_cpp-ne 4.8.3,gcc_ntomipsle_gpp 4.8.3,gcc_ntoppcbe_acpp 4.8.3,gcc_ntoshle_cpp-ne 4.8.3,gcc_ntomipsbe_cpp 4.8.3,gcc_ntomipsbe_cpp-ne 4.8.3,gcc_ntoppcbespe_ecpp 4.8.3,gcc_ntomipsle_cpp 4.8.3,gcc_ntomipsbe_ecpp 4.8.3,gcc_ntox86_gpp 4.8.3,gcc_ntoarmv7le_cpp 4.8.3,gcc_ntoppcbespe_acpp-ne 4.8.3,gcc_ntox86_ecpp 4.8.3,gcc_ntoshle 4.8.3,gcc_ntomipsle_acpp-ne 4.8.3,gcc_ntomipsle_ecpp 4.8.3,gcc_ntox86_acpp-ne 4.8.3,gcc_ntomipsle_ecpp-ne 4.8.3,gcc_ntoshle_cpp 4.8.3,gcc_ntoppcbe_ecpp-ne 4.8.3,gcc_ntoarmle 4.8.3,gcc_ntoppcbespe_gpp 4.8.3,gcc_ntoarmv7le_gpp 4.8.3,gcc_ntoarmv7le_ecpp-ne 4.8.3,gcc_ntox86_acpp 4.8.3,gcc_ntomipsbe_ecpp-ne 4.8.3,gcc_ntoarmle_gpp 4.8.3,gcc_ntomipsbe_gpp 4.8.3,gcc_ntoarmv7le_cpp-ne 4.8.3,gcc_ntoppcbe_ecpp 4.8.3,gcc_ntoarmv7le_ecpp 4.8.3,gcc_ntoshle_acpp-ne 4.8.3,gcc_ntoppcbespe_cpp 4.8.3,gcc_ntoshle_gpp 4.8.3,gcc_ntoppcbe_gpp 4.8.3,gcc_ntoarmle_acpp-ne 4.8.3,gcc_ntoarmle_cpp-ne 4.8.3,gcc_ntoshle_acpp 4.8.3,gcc_ntomipsbe_acpp-ne 4.8.3,gcc_ntoppcbespe_cpp-ne 4.8.3,gcc_ntox86_cpp-ne 4.8.3,gcc_ntox86 4.8.3,gcc_ntomipsbe make: *** [build/x86-debug/src/test.o] Error 1 What am I doing wrong? Thu, 13 Sep 2018 11:00:39 GMT http://community.qnx.com/sf/go/post119094 Vasilij Yanikeev(deleted) 2018-09-13T11:00:39Z http://community.qnx.com/sf/go/post119093 Hello! I am trying to install GCC 4.8.3 to my QNX6.5 SDP on Linux. I did the follows: 1) Copied already installed version for backup: # cp -r /opt/qnx650 /opt/qnx650sp1 2) unpaked archive with GCC 4.8.3 (downloaded from here (http://community.qnx.com/sf/frs/do/viewRelease/projects.toolchain/frs.gcc.gcc_4_8) to /opt/qnx650: # tar -xfnto-gcc-4.8.3-qnx65x.tar.gz -C /opt/qnx650 3) unpaked binutils (downloaded from here http://community.qnx.com/sf/frs/do/listReleases/projects.toolchain/frs.binutils) : # tar -xfnto-binutils-2.25.tar.gz -C /opt/qnx650 4) Renamed /opt/qnx650sp1-gcc483/host/linux/x86/etc/qcc/gcc/4.4.2 to /opt/qnx650sp1-gcc483/host/linux/x86/etc/qcc/gcc/4.8.3 5) Launched Momentix IDE 7.0 and created new QNX C++ project: File->New->QNX Project->QNX Executable->C++ CPU x86 When I try to built such project I always get an error below: qcc -lang-c++ -Vgcc_ntox86 -c -Wp,-MMD,build/x86-debug/src/test.d,-MT,build/x86-debug/src/test.o -o build/x86-debug/src/test.o -Wall -fmessage-length=0 -g -O0 -fno-builtin src/test.cpp cc: unknown target 'gcc_ntox86+debug' cc: targets available in /opt/qnx650/host/linux/x86/etc/qcc/gcc: 4.8.3,gcc_ntomipsle_acpp 4.8.3,gcc_ntoarmle_ecpp 4.8.3,gcc_ntoarmv7le_acpp-ne 4.8.3,gcc_ntoarmle_ecpp-ne 4.8.3,gcc_ntoarmv7le_acpp 4.8.3,gcc_ntoppcbespe_ecpp-ne 4.8.3,gcc_ntoppcbespe_acpp 4.8.3,gcc_ntoppcbe_cpp-ne 4.8.3,gcc_ntomipsle 4.8.3,gcc_ntoarmle_acpp 4.8.3,gcc_ntoppcbespe 4.8.3,gcc_ntox86_cpp 4.8.3,gcc_ntox86_ecpp-ne 4.8.3,gcc_ntoarmv7le 4.8.3,gcc_ntoppcbe_acpp-ne 4.8.3,gcc_ntomipsbe_acpp 4.8.3,gcc_ntoppcbe 4.8.3,gcc_ntoppcbe_cpp 4.8.3,gcc_ntoshle_ecpp-ne 4.8.3,gcc_ntoshle_ecpp 4.8.3,gcc_ntoarmle_cpp 4.8.3,gcc_ntomipsle_cpp-ne 4.8.3,gcc_ntomipsle_gpp 4.8.3,gcc_ntoppcbe_acpp 4.8.3,gcc_ntoshle_cpp-ne 4.8.3,gcc_ntomipsbe_cpp 4.8.3,gcc_ntomipsbe_cpp-ne 4.8.3,gcc_ntoppcbespe_ecpp 4.8.3,gcc_ntomipsle_cpp 4.8.3,gcc_ntomipsbe_ecpp 4.8.3,gcc_ntox86_gpp 4.8.3,gcc_ntoarmv7le_cpp 4.8.3,gcc_ntoppcbespe_acpp-ne 4.8.3,gcc_ntox86_ecpp 4.8.3,gcc_ntoshle 4.8.3,gcc_ntomipsle_acpp-ne 4.8.3,gcc_ntomipsle_ecpp 4.8.3,gcc_ntox86_acpp-ne 4.8.3,gcc_ntomipsle_ecpp-ne 4.8.3,gcc_ntoshle_cpp 4.8.3,gcc_ntoppcbe_ecpp-ne 4.8.3,gcc_ntoarmle 4.8.3,gcc_ntoppcbespe_gpp 4.8.3,gcc_ntoarmv7le_gpp 4.8.3,gcc_ntoarmv7le_ecpp-ne 4.8.3,gcc_ntox86_acpp 4.8.3,gcc_ntomipsbe_ecpp-ne 4.8.3,gcc_ntoarmle_gpp 4.8.3,gcc_ntomipsbe_gpp 4.8.3,gcc_ntoarmv7le_cpp-ne 4.8.3,gcc_ntoppcbe_ecpp 4.8.3,gcc_ntoarmv7le_ecpp 4.8.3,gcc_ntoshle_acpp-ne 4.8.3,gcc_ntoppcbespe_cpp 4.8.3,gcc_ntoshle_gpp 4.8.3,gcc_ntoppcbe_gpp 4.8.3,gcc_ntoarmle_acpp-ne 4.8.3,gcc_ntoarmle_cpp-ne 4.8.3,gcc_ntoshle_acpp 4.8.3,gcc_ntomipsbe_acpp-ne 4.8.3,gcc_ntoppcbespe_cpp-ne 4.8.3,gcc_ntox86_cpp-ne 4.8.3,gcc_ntox86 4.8.3,gcc_ntomipsbe make: *** [build/x86-debug/src/test.o] Error 1 What am I doing wrong? Thu, 13 Sep 2018 11:00:38 GMT http://community.qnx.com/sf/go/post119093 Vasilij Yanikeev(deleted) 2018-09-13T11:00:38Z http://community.qnx.com/sf/go/post119092 Hello! I am trying to install GCC 4.8.3 to my QNX6.5 SDP on Linux. I did the follows: 1) Copied already installed version for backup: # cp -r /opt/qnx650 /opt/qnx650sp1 2) unpaked archive with GCC 4.8.3 (downloaded from here (http://community.qnx.com/sf/frs/do/viewRelease/projects.toolchain/frs.gcc.gcc_4_8) to /opt/qnx650: # tar -xfnto-gcc-4.8.3-qnx65x.tar.gz -C /opt/qnx650 3) unpaked binutils (downloaded from here http://community.qnx.com/sf/frs/do/listReleases/projects.toolchain/frs.binutils) : # tar -xfnto-binutils-2.25.tar.gz -C /opt/qnx650 4) Renamed /opt/qnx650sp1-gcc483/host/linux/x86/etc/qcc/gcc/4.4.2 to /opt/qnx650sp1-gcc483/host/linux/x86/etc/qcc/gcc/4.8.3 5) Launched Momentix IDE 7.0 and created new QNX C++ project: File->New->QNX Project->QNX Executable->C++ CPU x86 When I try to built such project I always get an error below: qcc -lang-c++ -Vgcc_ntox86 -c -Wp,-MMD,build/x86-debug/src/test.d,-MT,build/x86-debug/src/test.o -o build/x86-debug/src/test.o -Wall -fmessage-length=0 -g -O0 -fno-builtin src/test.cpp cc: unknown target 'gcc_ntox86+debug' cc: targets available in /opt/qnx650/host/linux/x86/etc/qcc/gcc: 4.8.3,gcc_ntomipsle_acpp 4.8.3,gcc_ntoarmle_ecpp 4.8.3,gcc_ntoarmv7le_acpp-ne 4.8.3,gcc_ntoarmle_ecpp-ne 4.8.3,gcc_ntoarmv7le_acpp 4.8.3,gcc_ntoppcbespe_ecpp-ne 4.8.3,gcc_ntoppcbespe_acpp 4.8.3,gcc_ntoppcbe_cpp-ne 4.8.3,gcc_ntomipsle 4.8.3,gcc_ntoarmle_acpp 4.8.3,gcc_ntoppcbespe 4.8.3,gcc_ntox86_cpp 4.8.3,gcc_ntox86_ecpp-ne 4.8.3,gcc_ntoarmv7le 4.8.3,gcc_ntoppcbe_acpp-ne 4.8.3,gcc_ntomipsbe_acpp 4.8.3,gcc_ntoppcbe 4.8.3,gcc_ntoppcbe_cpp 4.8.3,gcc_ntoshle_ecpp-ne 4.8.3,gcc_ntoshle_ecpp 4.8.3,gcc_ntoarmle_cpp 4.8.3,gcc_ntomipsle_cpp-ne 4.8.3,gcc_ntomipsle_gpp 4.8.3,gcc_ntoppcbe_acpp 4.8.3,gcc_ntoshle_cpp-ne 4.8.3,gcc_ntomipsbe_cpp 4.8.3,gcc_ntomipsbe_cpp-ne 4.8.3,gcc_ntoppcbespe_ecpp 4.8.3,gcc_ntomipsle_cpp 4.8.3,gcc_ntomipsbe_ecpp 4.8.3,gcc_ntox86_gpp 4.8.3,gcc_ntoarmv7le_cpp 4.8.3,gcc_ntoppcbespe_acpp-ne 4.8.3,gcc_ntox86_ecpp 4.8.3,gcc_ntoshle 4.8.3,gcc_ntomipsle_acpp-ne 4.8.3,gcc_ntomipsle_ecpp 4.8.3,gcc_ntox86_acpp-ne 4.8.3,gcc_ntomipsle_ecpp-ne 4.8.3,gcc_ntoshle_cpp 4.8.3,gcc_ntoppcbe_ecpp-ne 4.8.3,gcc_ntoarmle 4.8.3,gcc_ntoppcbespe_gpp 4.8.3,gcc_ntoarmv7le_gpp 4.8.3,gcc_ntoarmv7le_ecpp-ne 4.8.3,gcc_ntox86_acpp 4.8.3,gcc_ntomipsbe_ecpp-ne 4.8.3,gcc_ntoarmle_gpp 4.8.3,gcc_ntomipsbe_gpp 4.8.3,gcc_ntoarmv7le_cpp-ne 4.8.3,gcc_ntoppcbe_ecpp 4.8.3,gcc_ntoarmv7le_ecpp 4.8.3,gcc_ntoshle_acpp-ne 4.8.3,gcc_ntoppcbespe_cpp 4.8.3,gcc_ntoshle_gpp 4.8.3,gcc_ntoppcbe_gpp 4.8.3,gcc_ntoarmle_acpp-ne 4.8.3,gcc_ntoarmle_cpp-ne 4.8.3,gcc_ntoshle_acpp 4.8.3,gcc_ntomipsbe_acpp-ne 4.8.3,gcc_ntoppcbespe_cpp-ne 4.8.3,gcc_ntox86_cpp-ne 4.8.3,gcc_ntox86 4.8.3,gcc_ntomipsbe make: *** [build/x86-debug/src/test.o] Error 1 What am I doing wrong? Thu, 13 Sep 2018 11:00:36 GMT http://community.qnx.com/sf/go/post119092 Vasilij Yanikeev(deleted) 2018-09-13T11:00:36Z http://community.qnx.com/sf/go/post119043 Is there another instance of tracelogger running? If so, you can try slaying it. Another possibility is that an application called TraceEvent(_NTO_TRACE_START) before you tried to start tracelogger. Here's something that we recently added to the documentation: If an application has called TraceEvent(_NTO_TRACE_START), and you then try to start tracelogger, tracelogger might fail with a “resource busy” message. To help avoid this: - Start tracelogger before your application issues a _NTO_TRACE_START or _NTO_TRACE_STARTNOSTATE command. - Don't leave tracing on indefinitely; be sure to issue a _NTO_TRACE_STOP after each _NTO_TRACE_START or _NTO_TRACE_STARTNOSTATE command. Wed, 08 Aug 2018 17:32:00 GMT http://community.qnx.com/sf/go/post119043 Steve Reid 2018-08-08T17:32:00Z http://community.qnx.com/sf/go/post119042 Hello all, Is there nobody who can tell why the message # tracelogger: tracelog_acquire: Resource busy # is coming when trying to start the trace logger.using the command # tracelogger -d1 -n 10 -f /root/data/all_classes.kev # I suspect that a previous attempt to start the tracelogger failed but the access to the file (specified with -f) was not properly terminated. Is there anyone who can confirm the above and / or suggest a way to solve this without having to restart the whole system? Is there a way to terminate the tracelog_acquire session? Regards OZ Wed, 08 Aug 2018 14:42:58 GMT http://community.qnx.com/sf/go/post119042 Ovidiu Zaharia 2018-08-08T14:42:58Z http://community.qnx.com/sf/go/post118843 binscan link should be working if your maintenance contract is setup correctly. qscan is an optional package through the QNX Software Center on SDP7. Wed, 23 May 2018 16:35:30 GMT http://community.qnx.com/sf/go/post118843 Jim Sleeth 2018-05-23T16:35:30Z http://community.qnx.com/sf/go/post118842 For some reason I cannot go to the link you posted, it says "The page you requested cannot be found." I tried qscan too and it's not recognized as an executable. I tried to look it up online and there isn't any documentation. Could you please provide some more information on these? Tue, 22 May 2018 22:02:08 GMT http://community.qnx.com/sf/go/post118842 Eric Fossum(deleted) 2018-05-22T22:02:08Z http://community.qnx.com/sf/go/post118837 did you try http://community.qnx.com/sf/wiki/do/viewPage/projects.customer_ast_services/wiki/ToolsPage For SDP7 there is also qscan. Sat, 19 May 2018 21:59:39 GMT http://community.qnx.com/sf/go/post118837 Jim Sleeth 2018-05-19T21:59:39Z http://community.qnx.com/sf/go/post118820 We are trying to upgrade our build tools from GCC 4.8.3 to 4.9.3 and are seeing some weird issues. I have tried to extract the new 4.9.3 files to our build path (host and target folders), and set C:\qnx660\host\win32\x86\etc\qcc\gcc\default to say the DIR=4.9.3 but when compiling our application we are seeing we need to set an include path to pick up the new GCC version. We are seeing we have to add these two include paths: - C:/qnx660/target/qnx6/usr/include/c++/4.9.3 - C:/qnx660/target/qnx6/usr/include/c++/4.9.3/arm-unknown-nto-qnx6.6.0eabi We did not have to specify these with 4.8.3 Is there something we are doing wrong to not pick up the new GCC version when compiling? Wed, 16 May 2018 20:35:21 GMT http://community.qnx.com/sf/go/post118820 Kevin Smith(deleted) 2018-05-16T20:35:21Z http://community.qnx.com/sf/go/post118815 I have an automated CI system and I'm hoping to add some version output to the build. I can run some commands before kicking off the make, or it could print the tools used at compile time. Ideally it would print all versions of all tools and plug-ins... Any ideas? Tue, 15 May 2018 18:10:42 GMT http://community.qnx.com/sf/go/post118815 Eric Fossum(deleted) 2018-05-15T18:10:42Z http://community.qnx.com/sf/go/post118786 Thanks! It looks fairly easy. I would need this for clang (llvm actually) 5.0. I suppose the effort is similar to this one? Tue, 24 Apr 2018 06:44:19 GMT http://community.qnx.com/sf/go/post118786 Ivo Petkovic(deleted) 2018-04-24T06:44:19Z http://community.qnx.com/sf/go/post118749 Attached are the diff from todays clang trunk (7.0) What I have not been able to build yet is libcxx I used this cmake command to setup the project ( using Ninja ) cmake -G"Ninja" \ -DLLVM_TARGETS_TO_BUILD=X86 \ -DCMAKE_BUILD_TYPE=Release \ -DLLVM_DEFAULT_TARGET_TRIPLE=i386-pc-qnx650-gnu \ -DCOMPILER_RT_INCLUDE_TESTS=OFF \ -DLLVM_ENABLE_ASSERTIONS=OFF \ -DLLVM_ENABLE_LTO=ON \ -DLLVM_ENABLE_ZLIB=ON \ -DLLVM_BUILD_TEST=OFF \ -DLLVM_INCLUDE_TESTS=OFF \ -DLLVM_USE_LINKER=gold \ -DLLVM_ENABLE_WARNINGS=OFF \ ../trunk Mon, 09 Apr 2018 13:31:25 GMT http://community.qnx.com/sf/go/post118749 Mario Charest 2018-04-09T13:31:25Z http://community.qnx.com/sf/go/post118748 Hi Mario, Could you share the patches for clang? Mon, 09 Apr 2018 07:39:20 GMT http://community.qnx.com/sf/go/post118748 Ivo Petkovic(deleted) 2018-04-09T07:39:20Z http://community.qnx.com/sf/go/post118420 I found the problem. The build I was doing for QNX 6.5 and 7.0 took place in different directories, but the path of the library file for the QNX 7.0 build was still pointing to the 6.5 tree. So I was trying to link the application that was compiled for QNX 7.0 against the library (a .a file) compiled for QNX 6.5 and this is the error message that popped out. So now we know :) Mon, 22 Jan 2018 13:56:22 GMT http://community.qnx.com/sf/go/post118420 Chris Buck(deleted) 2018-01-22T13:56:22Z http://community.qnx.com/sf/go/post118405 I am porting a resource manager from QNX 6.5 to 7.0 and it is split into two projects: the main application code and a statically-linked library. When compiling for 6.5 everything works without any problems, but when I try to compile the exact same projects for QNX 7 I get the following linker error (actually, many instances of the same error): c:\qnx700\\host\win64\x86_64\usr\bin\arm-unknown-nto-qnx7.0.0eabi-ld: error: nameofexecutable uses VFP register arguments, nameoflibraryfile.a(filename.o) does not c:\qnx700\\host\win64\x86_64\usr\bin\arm-unknown-nto-qnx7.0.0eabi-ld: failed to merge target specific data of file nameoflibraryfile.a(filename.o) If I take all of the source files from the library project and add them to the executable project everything works fine. I did some research on the error and see that "VFP register arguments" relate to floating-point arguments and how they are passed, but neither my application nor my library have any floating-point arithmetic whatsoever (no floats, no doubles). Has anyone seen anything like this using the QNX 7 C compiler? I am cross-compiling to an ARM CPU target. Thanks! Thu, 18 Jan 2018 22:27:16 GMT http://community.qnx.com/sf/go/post118405 Chris Buck(deleted) 2018-01-18T22:27:16Z http://community.qnx.com/sf/go/post118247 Hi, In Win 7 X64 machine, i am seeing the QNX compilation to fail due to the below error. Can i rebase the msys dll, so that the below error goes away? Please let me know the steps. C:\QNX650\host\win32\x86\usr\bin\ksh.exe: *** fork: can't reserve memory for stack 0xA0000 - 0x2A0000, Win32 error 0 31075038 [main] ksh 8152 sync_with_child: child 23508(0x224) died before initialization with status code 0x1 31075609 [main] ksh 8152 sync_with_child: *** child state waiting for longjmp C:/QNX650/host/win32/x86/usr/bin/qnx_cp[81]: cannot fork - try again Regards, Manas Wed, 29 Nov 2017 08:50:01 GMT http://community.qnx.com/sf/go/post118247 manas sahoo 2017-11-29T08:50:01Z http://community.qnx.com/sf/go/post118198 The std::uncaught_exception() function seems to always return 0 when using the Dinkumware library on QNX 6.6.0. Attaching a code example from http://en.cppreference.com/w/cpp/error/uncaught_exception. When compiled with the default Dinkumware library: qcc -o uncaught_exception_test2.o "..\\uncaught_exception_test2.cpp" -V4.7.3,gcc_ntoarmv7le -w1 -c -O0 -g qcc -o uncaught_exception_test2 uncaught_exception_test2.o -V4.7.3,gcc_ntoarmv7le -w1 -lang-c++ -g The results are wrong: Exception thrown ~Foo() called normally Exception caught: test exception ~Foo() called normally The problem exists on both x86 and armv7. When compiled with GNU libstdc++: qcc -o uncaught_exception_test2.o "..\\uncaught_exception_test2.cpp" -V4.7.3,gcc_ntoarmv7le_gpp -w1 -c -O0 -g qcc -o uncaught_exception_test2 uncaught_exception_test2.o -V4.7.3,gcc_ntoarmv7le_gpp -w1 -lang-c++ -g The results are correct: Exception thrown ~Foo() called during stack unwinding Exception caught: test exception ~Foo() called normally Mon, 13 Nov 2017 19:30:31 GMT http://community.qnx.com/sf/go/post118198 Niklas Angare 2017-11-13T19:30:31Z http://community.qnx.com/sf/go/post118192 Manage too add to llvm/clang5 support for QNX650. I don't know what I,m doing, but it managed to compile ( still using QNX linker though) our softwares and passing all of the tests !!! Which surprised me. I was hopping for faster build time than gcc 4.8.3 but so far they are very similar. If anyone is interested to play with it I could post patches I guess. It's surprisingly, well to me at least, how little changes it took. Should be very simple to get it to work for QNX660 / QNX700. Only clang/clang++ is working, no libcxx no linker, sanitizer, etc, that seems more complicated. ntox86-gdb has no problem debugging clang generated exe. Sat, 11 Nov 2017 00:28:39 GMT http://community.qnx.com/sf/go/post118192 Mario Charest 2017-11-11T00:28:39Z http://community.qnx.com/sf/go/post118163 Just figured out that it was qcc complaining. So I second the request, is there an updated qcc that will support these options (lto_cc, lto_support, lto_opt)? Thanks Tue, 31 Oct 2017 04:20:47 GMT http://community.qnx.com/sf/go/post118163 Kevin Stallard(deleted) 2017-10-31T04:20:47Z http://community.qnx.com/sf/go/post118162 I second this request, moving to 4.9.3 is spitting out cc: ignoring unknown option 'lto_cc' (as well as others)? Thanks Kevin Tue, 31 Oct 2017 03:44:35 GMT http://community.qnx.com/sf/go/post118162 Kevin Stallard(deleted) 2017-10-31T03:44:35Z http://community.qnx.com/sf/go/post118151 Hello, Is there a way to make and etfs filesystem noexec? I am starting the driver with fs-etfs-gpmi -r0 -Difs=0,ipl=0 -m /nand & form an ifs script. How can I make the whole fylesystem noexec? Thu, 26 Oct 2017 13:32:38 GMT http://community.qnx.com/sf/go/post118151 Dimitar Slavchev 2017-10-26T13:32:38Z http://community.qnx.com/sf/go/post118147 Hello, I am working with QNX Momentics on Windows and using QNX SDP 7.0.0 and GCC 5.4.0. I am facing the same problem with the new GCC available here. Can you please help me in solving this error ? Following is the error: C:\tools\sdp\qnx700\host\win64\x86_64\usr\bin\i586-pc-nto-qnx7.0.0-ld: hcu: hidden symbol `_Unwind_Resume' in C:/tools/sdp/qnx700/host/win64/x86_64/usr/lib/gcc/i586-pc-nto-qnx7.0.0/5.4.0/pic/libgcc.a(unwind-dw2.o) is referenced by DSO C:\tools\sdp\qnx700\host\win64\x86_64\usr\bin\i586-pc-nto-qnx7.0.0-ld: final link failed: Bad value cc: C:/tools/sdp/qnx700/host/win64/x86_64/usr/bin/i586-pc-nto-qnx7.0.0-ld caught signal 1 Thanks, Raju Wed, 25 Oct 2017 14:39:10 GMT http://community.qnx.com/sf/go/post118147 Raju A(deleted) 2017-10-25T14:39:10Z http://community.qnx.com/sf/go/post118089 Sorry kind of late to reply but this is gdb patch for stack issues (if using with IDE) http://community.qnx.com/sf/frs/do/viewRelease/projects.toolchain/frs.gdb.gdb_7_6_r942_sdp6_6_0 Fri, 29 Sep 2017 17:10:01 GMT http://community.qnx.com/sf/go/post118089 Elena Laskavaia 2017-09-29T17:10:01Z http://community.qnx.com/sf/go/post118022 > Attached is a Linux x86_64 hosted bfd and gold ld for 6.5.0SP1. Let me know if > you have any problems. > Hi, Any hope of getting the lto 64 bit plugin, that goes along with gold ld ? > Regards, > > Ryan Mansfield Fri, 08 Sep 2017 04:12:41 GMT http://community.qnx.com/sf/go/post118022 Mario Charest 2017-09-08T04:12:41Z http://community.qnx.com/sf/go/post118018 Hi, I am working at Bombardier Aerospace. I am looking for Marion Charest a QNX developer who helped us with developing a QNX based system between 2000 to 2001. We have lost contact with him since then. I would like to get in touch with him for a potentil new development. I appreciate if anybody can help by passing the news to him. Thanks Farshid Shadpey farshid.shadpey@aero.bombardier.com Wed, 06 Sep 2017 20:52:00 GMT http://community.qnx.com/sf/go/post118018 Farshid Shadpey(deleted) 2017-09-06T20:52:00Z http://community.qnx.com/sf/go/post118017 Hello, for my project, I need to run at least gcc version 6.2. In the QNX 7.0 there is gcc version 5.4. Is there a way how to get a higher version? Thank you Wed, 06 Sep 2017 11:19:51 GMT http://community.qnx.com/sf/go/post118017 Martin Knotek(deleted) 2017-09-06T11:19:51Z http://community.qnx.com/sf/go/post117947 Hello I am using the 4.9.3 GCC compiler on QNX 6.6.0. I am getting the following out on every C++ file that I compile: cc: ignoring unknown option 'lto_support' cc: ignoring unknown option 'lto_opt' cc: ignoring unknown option 'lto_cc' cc: ignoring unknown option 'lto_support' cc: ignoring unknown option 'lto_opt' cc: ignoring unknown option 'lto_cc' Is there a way to disable this? Thanks, Rodney Tue, 08 Aug 2017 14:55:21 GMT http://community.qnx.com/sf/go/post117947 Rodney Dowdall(deleted) 2017-08-08T14:55:21Z http://community.qnx.com/sf/go/post117797 Hi, I am trying to debug an application that uses a thread pool. As long as the application is single threaded, debugging is great. Also, just noticed that if I use the flag POOL_FLAG_USE_SELF instead of POOL_FLAG_EXIT_SELF I also get good results. The stack doesn't show up when a break point is hit, but at least I can single step. Eventually the stack trace as well as the threads that are running show up as well, but not at the start. So it has something to do with ripping the initial startup thread away from the debugger. It clearly has issues with that kind of behavior on my part. BTW: I am using gdb version: GNU gdb (GDB) 7.6.1 qnx (rev. 863) The target is a QNX 6.5 sp1 Arm v7 Anyway, we are moving forward again, but wanted to toss this in the mix... Thanks Kevin Mon, 19 Jun 2017 23:46:50 GMT http://community.qnx.com/sf/go/post117797 Kevin Stallard(deleted) 2017-06-19T23:46:50Z http://community.qnx.com/sf/go/post117737 You'll need to specify the version of the library. The libstdc++.so.6 file is just a symbolic link that points to the actual versioned library, for example libstdc++.so.6.0.19. -----Original Message----- From: Claudia Choi [mailto:community-noreply@qnx.com] Sent: Wednesday, May 10, 2017 4:33 PM To: general-toolchain Subject: Looking for debug symbols of libstdc++.so.6 I am looking for debug symbols for libstdc++.so.6 for ARMLE-V7 target. Anyone knows where I can download them? _______________________________________________ General http://community.qnx.com/sf/go/post117725 To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com Tue, 16 May 2017 17:12:53 GMT http://community.qnx.com/sf/go/post117737 Max Feil 2017-05-16T17:12:53Z http://community.qnx.com/sf/go/post117725 I am looking for debug symbols for libstdc++.so.6 for ARMLE-V7 target. Anyone knows where I can download them? Wed, 10 May 2017 20:32:40 GMT http://community.qnx.com/sf/go/post117725 Claudia Choi 2017-05-10T20:32:40Z http://community.qnx.com/sf/go/post117282 Hi,I'm trying to run my application after enabled the mudflap tools. When I launch the binary from IDE, I got below error.  ldd:FATAL: Could not use _dl_alloc. We are either out of memory or application overrides this symbol and returns NULL. In that case, executable must have DT_BIND_NOW or environment variable LD_BIND_NOW must be set  I tried to enable the LD_BIND_NOW to non zero(1) environment variable and re-launch the application, now I ended up with below error.   ldd:FATAL: unable to create dlerror() key (Not enough memory) My application was using open source library ssl and crypto. Due to this error, I'm not able to run my application using mudflap tool.  Platform: x86Neutrino OS: 6.5IDE: 4.7.0  However, I am able to launch the other applications successfully using mudflap. But the successful application is not using any using any ssl and crypto library.  Thanks,Murugaiyan Thu, 15 Dec 2016 09:51:52 GMT http://community.qnx.com/sf/go/post117282 Murugaiyan Perumal(deleted) 2016-12-15T09:51:52Z http://community.qnx.com/sf/go/post117092 All the symlinks are created as part of the packaging step. You could create these manually, but it seems like easy work for a shell script. Mon, 07 Nov 2016 18:46:38 GMT http://community.qnx.com/sf/go/post117092 Michael Daniels(deleted) 2016-11-07T18:46:38Z http://community.qnx.com/sf/go/post117032 I've successfully compiled 4.9.3 version of gcc for ntox86 target and linux_x86-64 host and it works fine. But what I couldn't understand so far is how to get ntox86-* files which are just symlinks(?) for i486-pc-nto-qnx6.5.0-*. Should I run some post build (or install) script or these symlinks always created manually? Without these files I feel my build result incomplete :)) Sun, 30 Oct 2016 07:33:01 GMT http://community.qnx.com/sf/go/post117032 Alexey Smirnov(deleted) 2016-10-30T07:33:01Z http://community.qnx.com/sf/go/post116967 It seems that qcc needs to be updated with the GCC 4.9.3 package since it does not recognize some new options cc: ignoring unknown option 'lto_support' cc: ignoring unknown option 'lto_opt' cc: ignoring unknown option 'lto_cc' Wed, 12 Oct 2016 21:14:57 GMT http://community.qnx.com/sf/go/post116967 Oleh Derevenko 2016-10-12T21:14:57Z http://community.qnx.com/sf/go/post116943 Hi, I am creating a image for the qnx 6 file system. mkqnx6fsimg does not support the script attribute unlike the buildfile for mkifs, so what alternative do I have? Thanks, Sanna Wed, 05 Oct 2016 17:32:09 GMT http://community.qnx.com/sf/go/post116943 Sanna Haraginadoni(deleted) 2016-10-05T17:32:09Z http://community.qnx.com/sf/go/post116932 So I found a generic x86 BSP. How would I use this with the QNX VMware runtime Image ISO? Would it give it more features? I think I would have build upon that BSP (apps and other programs and such) right? Fri, 30 Sep 2016 16:08:59 GMT http://community.qnx.com/sf/go/post116932 Matthew Johnston(deleted) 2016-09-30T16:08:59Z http://community.qnx.com/sf/go/post116924 It actually did ;-) The program ran on the target, its output piped to Momentics. To see it on the VM command line interface you need to start the application manually from there and then attach the debugger to it. You can start the application with on -h so that it starts in help mode, that way when you attach the debugger to it, no code has run. Maybe its possible to start an app from Momentic and redirects its input/output to a console (/dev/con1) but never done that myself. QNX 6.6.0 is a strange beast. It's like trying to do cooking but instead of starting from nice ingredients and recipes, you are given seeds to first grow stuff you need, embryonic stuff to "grow" meat and then a book on chemical reaction to figure out all to mix it all. The outcome can be very personalized, original and tasty, but it's not easy to get there. I'm sorry I don't have any pointer to give you, maybe look at the Car stuff, but not sure it's available in the basic kit. My perception is that QNX 6.6.0 was rushed out to please a certain market (notice that I did not say markets ) at the cost of making it harder for other. Life is full of compromise ;-) -----Message d'origine----- De : Matthew Johnston [mailto:community-noreply@qnx.com] Envoyé : 30 septembre 2016 08:34 À : general-toolchain <general-toolchain@community.qnx.com> Objet : New Guy here Hey, I just joined Foundry 27 and I'm trying out the QNX evaluation kit. I'm totally confused as to what to do next. I'm looking to emulate something along the lines of a car infotainment system or just get apps/bluetooth/internet browser running on my target QNX 6.6 Neutrino VM. So far I followed the tutorial on creating a Hello world C/C++ project and linking it to my target. The output of my debug session just said Hello World on my momentics IDE. I was hoping it would open a pipe into the VM target and print it out on the VM command line interface. It didn't. How would I get a more funciton RTOS running on the VM? It is way too bare bones now. Can't really do anything with it. _______________________________________________ General http://community.qnx.com/sf/go/post116923 To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com Fri, 30 Sep 2016 12:59:58 GMT http://community.qnx.com/sf/go/post116924 Mario Charest 2016-09-30T12:59:58Z http://community.qnx.com/sf/go/post116923 Hey, I just joined Foundry 27 and I'm trying out the QNX evaluation kit. I'm totally confused as to what to do next. I'm looking to emulate something along the lines of a car infotainment system or just get apps/bluetooth/internet browser running on my target QNX 6.6 Neutrino VM. So far I followed the tutorial on creating a Hello world C/C++ project and linking it to my target. The output of my debug session just said Hello World on my momentics IDE. I was hoping it would open a pipe into the VM target and print it out on the VM command line interface. It didn't. How would I get a more funciton RTOS running on the VM? It is way too bare bones now. Can't really do anything with it. Fri, 30 Sep 2016 12:33:30 GMT http://community.qnx.com/sf/go/post116923 Matthew Johnston(deleted) 2016-09-30T12:33:30Z http://community.qnx.com/sf/go/post116878 > On Sep 24, 2016, at 10:55 AM, Lei Xing <leixing2@gmail.com> wrote: > > Hi Everyone, > I am a new comer to the qnx community. I encounter one issue and hope to get help from the community. > When I build the Intel TBB in the qnx, I get the error that no platform function has been defined or declared, for example __TBB_Yield and so on. > I know the Intel TBB does not support QNX, but does anyone have a patch so that I can build it successfully? Could you send it to me? > > > Thank you !! > > Best > Lei Sat, 24 Sep 2016 18:17:04 GMT http://community.qnx.com/sf/go/post116878 lei xing(deleted) 2016-09-24T18:17:04Z http://community.qnx.com/sf/go/post116876 Dear Michael, Thank you for your response. Finally the problem is stack overrides. Am I right? Please see below and confirm. It is re-entrant. But array is local to function so it will be in stack segment. QNX has stack limit for thread in process. Example: 9534 array of int, I.e 9k * 4 of stack size. So could be stack overrides. Instead allocate stack as 32bytes and sufficient for p1 and p2. In some cases, it is worth the effort to optimize the stack, particularly when the application has some frequent picks of stack activity (meaning that a huge stack segment would be constantly mapped to physical memory). We can watch the Memory Information view for stack allocation and inspect code that uses the stack heavily. This usually occurs in two cases: recursive calls (which should be avoided in embedded systems), and heavy usage of local variables (keeping arrays on the stack Thanks, Ramu On Sep 24, 2016 6:11 PM, "Michael Daniels" <community-noreply@qnx.com> wrote: > The function is creating a 38KB object on the stack. Presumably you are > calling the function with less than 38KB of free space left on the stack. > > > > _______________________________________________ > > General > http://community.qnx.com/sf/go/post116875 > To cancel your subscription to this discussion, please e-mail > general-toolchain-unsubscribe@community.qnx.com > Sat, 24 Sep 2016 13:19:39 GMT http://community.qnx.com/sf/go/post116876 Ramanna M(deleted) 2016-09-24T13:19:39Z http://community.qnx.com/sf/go/post116875 The function is creating a 38KB object on the stack. Presumably you are calling the function with less than 38KB of free space left on the stack. Sat, 24 Sep 2016 12:41:36 GMT http://community.qnx.com/sf/go/post116875 Michael Daniels(deleted) 2016-09-24T12:41:36Z http://community.qnx.com/sf/go/post116874 If system has function foo below (in some lib) , what will be a problem under QNX when some program calls this function, I am getting stack overflow error..what is issue in this code.. Int foo(int a1, int a2) { int buf[9768]; int error = 0; // buf[365] = a1; buf[7194] = a2; // ...doing something…. // return error; } Please help me to understand in QNX context . Thanks in advance. Sat, 24 Sep 2016 07:59:35 GMT http://community.qnx.com/sf/go/post116874 Ramanna M(deleted) 2016-09-24T07:59:35Z http://community.qnx.com/sf/go/post116812 Hi experts, Basically I need to take a screenshot from the QNX board. When I refer the program given on qnx site at : http://www.qnx.com/developers/docs/660/index.jsp?topic=/com.qnx.doc.screen/topic/manual/cscreen_screenshot_disp_sample.html I am able to get the screenshot, but in this program screen_create_context uses SCREEN_DISPLAY_MANAGER_CONTEXT., which obviously needs a root permission. Whereas in my actual program I won't be a root user,but still i need to take a screenshot. For this i referred program at: http://www.qnx.com/developers/docs/660/index.jsp?topic=%2Fcom.qnx.doc.screen%2Ftopic%2Fmanual%2Fcscreen_screenshot_win_sample.html Here it uses context as screen_create_context(&screen_ctx, SCREEN_APPLICATION_CONTEXT); but the screenshot is blank, with just a black image that I am not supposed to get. Please let me know if there is an alternate way to do it !!!!! Thanks in advance, Rupali Mon, 19 Sep 2016 10:06:21 GMT http://community.qnx.com/sf/go/post116812 Rupali Kotgire(deleted) 2016-09-19T10:06:21Z http://community.qnx.com/sf/go/post116664 Our system headers have the C++ overloads in them, so GCC is setup to expect that's where they will come from and won't provide any of it's own. 6.5.0 system headers do not contain any C++11 support, so they will not have these overloads. 6.6.0 will though. You can provide your own, like you did for the string stuff. Something like this might work (untested): #include <math.h> template<typename T> double exp(T val) { return std::exp((double)val); } Wed, 17 Aug 2016 11:39:07 GMT http://community.qnx.com/sf/go/post116664 Michael Daniels(deleted) 2016-08-17T11:39:07Z http://community.qnx.com/sf/go/post116663 Hi, I use SDP 6.5.0 with GCC 4.8.3 and Binutils 2.24. And I am trying to compile Botan - C++ cryptographic library. In other topic Mario Charest helped me to resolve the C++ to_string() issue (http://community.qnx.com/sf/discussion/do/listPosts/projects.toolchain/discussion.core_development_tools.topc26761?_pagenum=4). Now I got another problem. The compiler cannot find an integral overload of log, exp that are the part of C++11 features. See 4th overload for http://en.cppreference.com/w/cpp/numeric/math/log http://en.cppreference.com/w/cpp/numeric/math/exp Did someone find a solution? Wed, 17 Aug 2016 10:42:54 GMT http://community.qnx.com/sf/go/post116663 Denis Kimcherenko(deleted) 2016-08-17T10:42:54Z http://community.qnx.com/sf/go/post116661 See the solution in http://community.qnx.com/sf/discussion/do/listPosts/projects.toolchain/discussion.core_development_tools.topc26761?_pagenum=4 Wed, 17 Aug 2016 07:52:36 GMT http://community.qnx.com/sf/go/post116661 Denis Kimcherenko(deleted) 2016-08-17T07:52:36Z http://community.qnx.com/sf/go/post116660 Thanks. it works. Just for other users, I put the attached header into <QNX_SDK_HOME>/target/qnx6/usr/include/c++/4.8.3/custom Wed, 17 Aug 2016 07:51:00 GMT http://community.qnx.com/sf/go/post116660 Denis Kimcherenko(deleted) 2016-08-17T07:51:00Z http://community.qnx.com/sf/go/post116658 What we ended up doing is our own header file <custom/string.h> that contains what is needed to support to_string and all related functions. It works because everything is inlined, so no need to rebuild a library. We just need to add #include <custom/string.h> when needed. I have attached the file in case it helps. Tue, 16 Aug 2016 17:12:24 GMT http://community.qnx.com/sf/go/post116658 Mario Charest 2016-08-16T17:12:24Z http://community.qnx.com/sf/go/post116657 Thanks Michael for the answer. > This can be fixed by patching the system headers to expose the c99 functions > regardless of the c++ standard specified and rebuilding gcc. As I understood, it is a single proper way. But does any instructions exist how to do it? > Then there is the hacky solution which is to just force _GLIBCXX_USE_C99 to be > defined and hope for the best. You are absolutely right. I tried this way but got the following errors: /opt/qnx650/target/qnx6/usr/include/c++/4.8.3/bits/basic_string.h:2844:31: error: 'strtoull' is not a member of 'std' /opt/qnx650/target/qnx6/usr/include/c++/4.8.3/bits/basic_string.h:2953:31: error: 'wcstof' is not a member of 'std' /opt/qnx650/target/qnx6/usr/include/c++/4.8.3/bits/basic_string.h:2961:31: error: 'wcstold' is not a member of 'std' Tue, 16 Aug 2016 16:10:36 GMT http://community.qnx.com/sf/go/post116657 Denis Kimcherenko(deleted) 2016-08-16T16:10:36Z http://community.qnx.com/sf/go/post116656 As Mario had mentioned in the other thread, this is caused by _GLIBCXX_USE_C99 not being defined. The configure script for libstdc++-v3 will check for c99 functions with -std=c++98 set, but our system headers won't expose the c99 functions in this case. This can be fixed by patching the system headers to expose the c99 functions regardless of the c++ standard specified and rebuilding gcc. It might also be possible to edit the configure script to use -std=c++0x and rebuild gcc, but I cannot guarantee that won't cause problems in the headers outside c++0x/c++11. Then there is the hacky solution which is to just force _GLIBCXX_USE_C99 to be defined and hope for the best. I wouldn't really recommend this and cannot guarantee this will not cause other problems, but to each their own. Tue, 16 Aug 2016 15:52:50 GMT http://community.qnx.com/sf/go/post116656 Michael Daniels(deleted) 2016-08-16T15:52:50Z http://community.qnx.com/sf/go/post116653 Hi, I am trying to build the Botan library (botan.randombit.net). It requires C++11 compliant compiler, thus I upgraded my QNX 650 to use GCC 4.8.3. To build the library I do the following: ./configure.py \ --os=qnx \ --cpu=x86 \ --cc=gcc \ --cc-bin=ntox86-g++-4.8.3 make install But got an error: build/include/botan/exceptn.h: In constructor 'Botan::Invalid_Key_Length::Invalid_Key_Length(const string&, std::size_t)': build/include/botan/exceptn.h:89:24: error: 'to_string' is not a member of 'std' Thus my question is how to enable the to_string() feature? Mon, 15 Aug 2016 11:07:33 GMT http://community.qnx.com/sf/go/post116653 Denis Kimcherenko(deleted) 2016-08-15T11:07:33Z http://community.qnx.com/sf/go/post116652 Hi guys, Did someone find a solution how to use to_string ? Mon, 15 Aug 2016 10:51:53 GMT http://community.qnx.com/sf/go/post116652 Denis Kimcherenko(deleted) 2016-08-15T10:51:53Z http://community.qnx.com/sf/go/post116629 > I am pretty sure that error will happen if the just built GCC doesn't work. > Nah its too early for that, seems like it's zlib for GCC. At anyrate I went around the problem by specifying --with-system-zlib and installing zlib with sudo install ... and the build completed without any hic-up. > My first guess would be needing updated binutils available, but if that's not > it the config logs might give you a better idea as to what the error actually. For QNX650 I'm using the latest 2.24 ( 2.25 are for 6.6.0 only it seems ). As for the host it's Ubuntu 14 but with gcc 5 installed. That being said all is good now I've got the binaires I wanted and I can experiment with it, want to see if I can get better compile time with 64bit binaries and fine tune optimisation option. Any gain will help ;-) Wed, 03 Aug 2016 13:32:14 GMT http://community.qnx.com/sf/go/post116629 Mario Charest 2016-08-03T13:32:14Z http://community.qnx.com/sf/go/post116628 I am pretty sure that error will happen if the just built GCC doesn't work. My first guess would be needing updated binutils available, but if that's not it the config logs might give you a better idea as to what the error actually. Tue, 02 Aug 2016 21:53:31 GMT http://community.qnx.com/sf/go/post116628 Michael Daniels(deleted) 2016-08-02T21:53:31Z http://community.qnx.com/sf/go/post116627 > For the most part, yes, there are some minor things you might run into, but > should be pretty obvious once you hit them. > > 1) You may need to change the SDP version, as you found out already. - Done > 2) You may need to update 'basedir' for linux hosted cross compilers as it > won't install into QNX_HOST like the other hosts. Will do,. > 3) You may need updated versions of GCC's prerequisites. GCC source includes a > script to grab them (./contrib/download_prerequisites), or we have recent > versions in the source tree. Forgot to mention it but I did that already. First time I run it, it stops at: mkdir 32 configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. The second time it failes with : make "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CFLAGS=-O2" "CXXFLAGS=-g -O2" "CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-g -O2" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS=-static-libstdc++ -static-libgcc -Wl,-s " "LIBCFLAGS=-O2" "LIBCFLAGS_FOR_TARGET=-g -O2" "MAKE=make" "MAKEINFO=/home2/neon-vendor/qnxgcc/gcc_4_8_branch/missing makeinfo --split-size=5000000 --split-size=5000000 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/bash" "EXPECT=expect" "RUNTEST=runtest" "RUNTESTFLAGS=" "exec_prefix=/opt/qnx650/host/linux/x86/usr" "infodir=/opt/qnx650/host/linux/x86/usr/share/info" "libdir=/opt/qnx650/host/linux/x86/usr/lib" "prefix=/opt/qnx650/host/linux/x86/usr" "tooldir=/opt/qnx650/host/linux/x86/usr/i486-pc-nto-qnx6.5.0" "AR=ar" "AS=as" "CC=gcc" "CXX=g++" "LD=ld" "LIBCFLAGS=-O2" "NM=nm" "PICFLAG=" "RANLIB=ranlib" "DESTDIR=" DO=all multi-do # make make[4]: Entering directory `/home2/neon-vendor/qnxgcc/gcc_4_8_branch/linux-x86-o-ntox86/zlib' if [ -z "32 x32" ]; then \ true; \ else \ rootpre=`${PWDCMD-pwd}`/; export rootpre; \ srcrootpre=`cd ../../zlib; ${PWDCMD-pwd}`/; export srcrootpre; \ lib=`echo "${rootpre}" | sed -e 's,^.*/\([^/][^/]*\)/$,\1,'`; \ compiler="gcc"; \ for i in `${compiler} --print-multi-lib 2>/dev/null`; do \ dir=`echo $i | sed -e 's/;.*$//'`; \ if [ "${dir}" = "." ]; then \ true; \ else \ if [ -d ../${dir}/${lib} ]; then \ flags=`echo $i | sed -e 's/^[^;]*;//' -e 's/@/ -/g'`; \ if (cd ../${dir}/${lib}; make \ CFLAGS="-O2 ${flags}" \ CCASFLAGS=" ${flags}" \ FCFLAGS=" ${flags}" \ FFLAGS=" ${flags}" \ ADAFLAGS=" ${flags}" \ prefix="/opt/qnx650/host/linux/x86/usr" \ exec_prefix="/opt/qnx650/host/linux/x86/usr" \ GCJFLAGS=" ${flags}" \ GOCFLAGS=" ${flags}" \ CXXFLAGS="-g -O2 ${flags}" \ LIBCFLAGS="-O2 ${flags}" \ LIBCXXFLAGS="-g -O2 -fno-implicit-templates ${flags}" \ LDFLAGS="-static-libstdc++ -static-libgcc -Wl,-s ${flags}" \ MULTIFLAGS="${flags}" \ DESTDIR="" \ INSTALL="/usr/bin/install -c" \ INSTALL_DATA="/usr/bin/install -c -m 644" \ INSTALL_PROGRAM="/usr/bin/install -c" \ INSTALL_SCRIPT="/usr/bin/install -c" \ all); then \ true; \ else \ exit 1; \ fi; \ else true; \ fi; \ fi; \ done; \ fi make[5]: Entering directory `/home2/neon-vendor/qnxgcc/gcc_4_8_branch/linux-x86-o-ntox86/32/zlib' make[5]: *** No rule to make target `all'. Stop. make[5]: Leaving directory `/home2/neon-vendor/qnxgcc/gcc_4_8_branch/linux-x86-o-ntox86/32/zlib' make[4]: *** [multi-do] Error 1 make[4]: Leaving directory `/home2/neon-vendor/qnxgcc/gcc_4_8_branch/linux-x86-o-ntox86/zlib' make[3]: *** [all-multi] Error 2 make[3]: Leaving directory `/home2/neon-vendor/qnxgcc/gcc_4_8_branch/linux-x86-o-ntox86/zlib' make[2]: *** [all-zlib] Error 2 make[2]: Leaving directory `/home2/neon-vendor/qnxgcc/gcc_4_8_branch/linux-x86-o-ntox86' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home2/neon-vendor/qnxgcc/gcc_4_8_branch/linux-x86-o-ntox86' make: *** [all] Error 2 Tue, 02 Aug 2016 21:22:52 GMT http://community.qnx.com/sf/go/post116627 Mario Charest 2016-08-02T21:22:52Z http://community.qnx.com/sf/go/post116626 For the most part, yes, there are some minor things you might run into, but should be pretty obvious once you hit them. 1) You may need to change the SDP version, as you found out already. 2) You may need to update 'basedir' for linux hosted cross compilers as it won't install into QNX_HOST like the other hosts. 3) You may need updated versions of GCC's prerequisites. GCC source includes a script to grab them (./contrib/download_prerequisites), or we have recent versions in the source tree. Tue, 02 Aug 2016 21:12:17 GMT http://community.qnx.com/sf/go/post116626 Michael Daniels(deleted) 2016-08-02T21:12:17Z http://community.qnx.com/sf/go/post116625 Are the instruction for building gcc found on the wiki still valid (http://community.qnx.com/sf/wiki/do/viewPage/projects.toolchain/wiki/Resources_GCC) I had to edit build_hooks to replace reference to 8.0.0 for 6.5.0 but I'm still having strange issues. Wanted to check if it should work as per the instruction before diving into this. - Mario Tue, 02 Aug 2016 20:24:53 GMT http://community.qnx.com/sf/go/post116625 Mario Charest 2016-08-02T20:24:53Z http://community.qnx.com/sf/go/post116514 Oh my bad I was looking at the creation date instead of last modified. Thanks. -----Message d'origine----- De : Michael Daniels [mailto:community-noreply@qnx.com] Envoyé : 4 juillet 2016 11:39 À : general-toolchain <general-toolchain@community.qnx.com> Objet : Re: hidden symbol `_Unwind_Resume' error with GCC 4.9.3 and QNX SDP 6.6.0 Yup, updated the packages in the File Releases section: http://community.qnx.com/sf/frs/do/viewRelease/projects.toolchain/frs.gcc.gcc_4_8 http://community.qnx.com/sf/frs/do/viewRelease/projects.toolchain/frs.gcc.gcc_4_9 _______________________________________________ General http://community.qnx.com/sf/go/post116513 To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com Mon, 04 Jul 2016 15:40:52 GMT http://community.qnx.com/sf/go/post116514 Mario Charest 2016-07-04T15:40:52Z http://community.qnx.com/sf/go/post116513 Yup, updated the packages in the File Releases section: http://community.qnx.com/sf/frs/do/viewRelease/projects.toolchain/frs.gcc.gcc_4_8 http://community.qnx.com/sf/frs/do/viewRelease/projects.toolchain/frs.gcc.gcc_4_9 Mon, 04 Jul 2016 15:39:02 GMT http://community.qnx.com/sf/go/post116513 Michael Daniels(deleted) 2016-07-04T15:39:02Z http://community.qnx.com/sf/go/post116512 > For what it's worth, the 4.8 and 4.9 packages have been updated. Updated as in available somewhere for download ? Mon, 04 Jul 2016 13:29:46 GMT http://community.qnx.com/sf/go/post116512 Mario Charest 2016-07-04T13:29:46Z http://community.qnx.com/sf/go/post116511 For what it's worth, the 4.8 and 4.9 packages have been updated. Mon, 04 Jul 2016 11:38:27 GMT http://community.qnx.com/sf/go/post116511 Michael Daniels(deleted) 2016-07-04T11:38:27Z http://community.qnx.com/sf/go/post116488 The docs outline what library support is available/missing: https://gcc.gnu.org/onlinedocs/gcc-4.8.5/libstdc++/manual/manual/status.html#status.iso.2011 And there is also a status page for the compiler support: https://gcc.gnu.org/projects/cxx-status.html#cxx11 I will try to get updated 4.9 packages up soon, but unfortunately I cannot make any promises. Mon, 27 Jun 2016 13:53:16 GMT http://community.qnx.com/sf/go/post116488 Michael Daniels(deleted) 2016-06-27T13:53:16Z http://community.qnx.com/sf/go/post116487 Ok I find out one difference on c++11 support between GCC 4.9 and 4.8 is <regex>. Mon, 27 Jun 2016 13:43:34 GMT http://community.qnx.com/sf/go/post116487 e zhong(deleted) 2016-06-27T13:43:34Z http://community.qnx.com/sf/go/post116486 Thank you Michael. Yes gcc4.8.3 works for me. As I know gcc4.8.3 is not different to gcc4.9.3 regarding c++11 support. Is that correct? Eric Sun, 26 Jun 2016 03:05:50 GMT http://community.qnx.com/sf/go/post116486 e zhong(deleted) 2016-06-26T03:05:50Z http://community.qnx.com/sf/go/post116483 This was fixed recently and is available in the 4.8.3 packages. The 4.9.3 packages have not yet been updated. Fri, 24 Jun 2016 20:22:38 GMT http://community.qnx.com/sf/go/post116483 Michael Daniels(deleted) 2016-06-24T20:22:38Z http://community.qnx.com/sf/go/post116482 HI Everyone, I am trying to upgrade gcc in QNX 6.6.0 from 4.7.3 to 4.9.3. I downloaded the GCC and Binutils packages from http://community.qnx.com/sf/frs/do/viewSummary/projects.toolchain/frs I deployed the packages by copying files into qnx6.6.0's 'host' and 'target' folders, and setting compiler version 4.9.3 in C:\qnx660\host\win32\x86\etc\qcc\gcc\default. Then when I tried to rebuild my application in Qt Creator I got an error as below - C:\qnx660\host\win32\x86\usr\bin\i486-pc-nto-qnx6.6.0-ld: ../../bin/x86/Release/sxm17_app: hidden symbol `_Unwind_Resume' in C:/qnx660/host/win32/x86/usr/lib/gcc/i486-pc-nto-qnx6.6.0/4.9.3/libgcc.a(unwind-dw2.o) is referenced by DSO C:\qnx660\host\win32\x86\usr\bin\i486-pc-nto-qnx6.6.0-ld: final link failed: Bad value cc: C:/qnx660/host/win32/x86/usr/bin/i486-pc-nto-qnx6.6.0-ld caught signal 1 make[1]: *** [../../bin/x86/Release/sxm17_app] Error 1 Any idea what problem it might be and how to fix? In my experiment I did see that if I replace the new libgcc.a with the old 4.7.3 version then the error goes away. But is it a good workaround or unsafe? Thanks! Eric Fri, 24 Jun 2016 20:14:00 GMT http://community.qnx.com/sf/go/post116482 e zhong(deleted) 2016-06-24T20:14:00Z http://community.qnx.com/sf/go/post116354 Hi, Some relevant links: https://github.com/boostorg/build/issues/85 https://github.com/blackberry/Boost/issues/11 I ended up using a slightly simpler solution - simply adding a space after $(HAVE_SONAME) seemed to resolve it for me. -Will diff --git a/src/tools/qcc.jam b/src/tools/qcc.jam index 8edd995..d07ec74 100644 --- a/src/tools/qcc.jam +++ b/src/tools/qcc.jam @@ -235,5 +235,5 @@ rule link.dll ( targets * : sources * : properties * ) # actions link.dll bind LIBRARIES { - "$(CONFIG_COMMAND)" -L"$(LINKPATH)" -Wl,-R$(SPACE)-Wl,"$(RPATH)" -o "$(<)" $(HAVE_SONAME)-Wl,-h$(SPACE)-Wl,$(<[1]:D=) -shared "$(>)" "$(LIBRARIES)" -l$(FINDLIBS-ST) -l$(FINDLIBS-SA) $(OPTIONS) + "$(CONFIG_COMMAND)" -L"$(LINKPATH)" -Wl,-R$(SPACE)-Wl,"$(RPATH)" -o "$(<)" $(HAVE_SONAME) -Wl,-h$(SPACE)-Wl,$(<[1]:D=) -shared "$(>)" "$(LIBRARIES)" -l$(FINDLIBS-ST) -l$(FINDLIBS-SA) $(OPTIONS) } On 2016-05-26 7:40 AM, Alexander Fagrell wrote: > I actually found the issue but I don't have a good solution (just a very awkward solution): > > Doing an objdump on the unit-test-framework resulted in: > > Dynamic Section: > NEEDED bin.v2\libs\timer\build\qcc\release\target-os-qnx\threadapi-pthread\threading-multi\libboost_timer-qcc-mt-1_60.so.1.60.0 > NEEDED bin.v2\libs\system\build\qcc\release\target-os-qnx\threadapi-pthread\threading-multi\libboost_system-qcc-mt-1_60.so.1.60.0 > NEEDED libm.so.2 > NEEDED libc.so.3 > > As you can see there is a ridiculous path to link to both the timer and the system library. I've manually edited the library's binary-file and removed the path (this is the awkward part...) to: > > Dynamic Section: > NEEDED libboost_timer-qcc-mt-1_60.so.1.60.0 > NEEDED libboost_system-qcc-mt-1_60.so.1.60.0 > NEEDED libm.so.2 > NEEDED libc.so.3 > > Which works. Is it possible to force Boost to not include the entire path into the library? Is this a boost issue or a qcc toolchain issue? I really don't want to edit each library's binary file manually... > > > > > _______________________________________________ > > General > http://community.qnx.com/sf/go/post116343 > To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com > Fri, 27 May 2016 18:20:02 GMT http://community.qnx.com/sf/go/post116354 Will Miles 2016-05-27T18:20:02Z http://community.qnx.com/sf/go/post116353 Two possibilities come to mind, the libraries so name is set incorrectly, or the soname is not set at all and the lib was passed to the linker with the full path you are seeing. You can use something like this to check what the soname is: ntox86-readelf -d libboost_system-qcc-mt-1_60.so.1.60.0 | grep SONAME Your build logs should show how things were passed to the linker, and whatever build system boost uses will hopefully tell you why the options were used. Fri, 27 May 2016 15:19:46 GMT http://community.qnx.com/sf/go/post116353 Michael Daniels(deleted) 2016-05-27T15:19:46Z http://community.qnx.com/sf/go/post116346 Hi Alexander, Typically, that entire values can be solved by adding the following option to the linker "-Wl,-rpath,$ORIGIN,-rpath,$ORIGIN/../lib". If you use CMake: set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,-rpath,$ORIGIN,-rpath,$ORIGIN/../lib") Hope this helps. Thu, 26 May 2016 20:15:45 GMT http://community.qnx.com/sf/go/post116346 Anton Indrawan(deleted) 2016-05-26T20:15:45Z http://community.qnx.com/sf/go/post116343 I actually found the issue but I don't have a good solution (just a very awkward solution): Doing an objdump on the unit-test-framework resulted in: Dynamic Section: NEEDED bin.v2\libs\timer\build\qcc\release\target-os-qnx\threadapi-pthread\threading-multi\libboost_timer-qcc-mt-1_60.so.1.60.0 NEEDED bin.v2\libs\system\build\qcc\release\target-os-qnx\threadapi-pthread\threading-multi\libboost_system-qcc-mt-1_60.so.1.60.0 NEEDED libm.so.2 NEEDED libc.so.3 As you can see there is a ridiculous path to link to both the timer and the system library. I've manually edited the library's binary-file and removed the path (this is the awkward part...) to: Dynamic Section: NEEDED libboost_timer-qcc-mt-1_60.so.1.60.0 NEEDED libboost_system-qcc-mt-1_60.so.1.60.0 NEEDED libm.so.2 NEEDED libc.so.3 Which works. Is it possible to force Boost to not include the entire path into the library? Is this a boost issue or a qcc toolchain issue? I really don't want to edit each library's binary file manually... Thu, 26 May 2016 11:40:18 GMT http://community.qnx.com/sf/go/post116343 Alexander Fagrell(deleted) 2016-05-26T11:40:18Z http://community.qnx.com/sf/go/post116337 Well that's not ideal. Try running the unittests or ldd with the environment variable LD_DEBUG=libs. This will print some additional information on libraries as they get loaded, and should at least print the name before hitting the failure. Wed, 25 May 2016 16:12:38 GMT http://community.qnx.com/sf/go/post116337 Michael Daniels(deleted) 2016-05-25T16:12:38Z http://community.qnx.com/sf/go/post116332 Thanks! I can now "successfully" build the boost libraries. The reason I put the successfully in quotations is because some of the libraries doesn't seems to function as expected. When dynamically linking to for example the unit_test_framework, its fine to build, but when I run the app I get a "Library cannot be found". Checking for dependency on for example /libboost_unit_test_framework.so (using ldd) results in: libboost_unit_test_framework.so => /home/alex/qnx/660/bin/boost/libboost_unit_test_framework-qcc-mt-1_60.so.1.60.0 (0xb8200000) ldd: Library cannot be found It doesn't event say which library that couldn't be found... ? I've cross-compiled boost using qcc 4.7.3. Any thoughts? Thanks Wed, 25 May 2016 13:56:05 GMT http://community.qnx.com/sf/go/post116332 Alexander Fagrell(deleted) 2016-05-25T13:56:05Z http://community.qnx.com/sf/go/post116307 When -std=c++11 is used it will enable __STRICT_ANSI__ causing us to disable extensions, like POSIX, in the headers. nanosleep() is not part of C++11, so it will not be available when using this option. You can use -std=gnu++11, or fiddle with the feature macros like _POSIX_C_SOURCE to enable the POSIX extensions and get nanosleep() as expected. Thu, 19 May 2016 16:17:39 GMT http://community.qnx.com/sf/go/post116307 Michael Daniels(deleted) 2016-05-19T16:17:39Z http://community.qnx.com/sf/go/post116305 Did you solve this? I've encountered the same problem. It seems like the toolset is linking to the Dinkum's time.h header: http://www.qnx.com/developers/docs/660/topic/com.qnx.doc.dinkum/topic/cpp11/time.html instead of the C Library's time.h: http://www.qnx.com/developers/docs/660/topic/com.qnx.doc.neutrino.lib_ref/topic/n/nanosleep.html Is it possible to link correctly without updating #include <time.h> using an absolute path instead. Thu, 19 May 2016 16:01:15 GMT http://community.qnx.com/sf/go/post116305 Alexander Fagrell(deleted) 2016-05-19T16:01:15Z http://community.qnx.com/sf/go/post116179 Sorry, i've tested win32 gdb/prereq again, and they work fine, so there's no need to update. Wed, 27 Apr 2016 12:31:40 GMT http://community.qnx.com/sf/go/post116179 Igor Rondarev 2016-04-27T12:31:40Z http://community.qnx.com/sf/go/post116135 What's missing from the win32 package? Sat, 23 Apr 2016 20:41:42 GMT http://community.qnx.com/sf/go/post116135 Michael Daniels(deleted) 2016-04-23T20:41:42Z http://community.qnx.com/sf/go/post116124 Thank you! Wed, 20 Apr 2016 14:35:56 GMT http://community.qnx.com/sf/go/post116124 Mario Charest 2016-04-20T14:35:56Z http://community.qnx.com/sf/go/post116123 Updated packages for 4.8 have been uploaded. Wed, 20 Apr 2016 14:33:29 GMT http://community.qnx.com/sf/go/post116123 Michael Daniels(deleted) 2016-04-20T14:33:29Z http://community.qnx.com/sf/go/post115898 libcpp.so.4 is provided for compatibility with existing binaries from SDP 6.5.0. If you want to build against it, you will need to use SDP 6.5.0. Thu, 03 Mar 2016 14:29:10 GMT http://community.qnx.com/sf/go/post115898 Michael Daniels(deleted) 2016-03-03T14:29:10Z http://community.qnx.com/sf/go/post115896 I am using qnx-sdp-6.6-201402230339.bin SDP and we want to use dinkum library which will include the libcpp.so. and the libcpp.so has link to libcpp.so.5 (/target/qnx6/armle-v7/lib/gcc/4.7.3/libcpp.so -> ../../libcpp.so.5) which is c++11 library. In our project we do not want c++11 compatibility at all. As QNX 6.6 SDP is providing backward compatibility, how we can use the lincpp.so.4 instead of libcpp.so.5? Thu, 03 Mar 2016 06:40:14 GMT http://community.qnx.com/sf/go/post115896 swapnil Belote(deleted) 2016-03-03T06:40:14Z http://community.qnx.com/sf/go/post115888 Michael, thank you, it works indeed. Could you please provide win32 build too? Tue, 01 Mar 2016 09:51:44 GMT http://community.qnx.com/sf/go/post115888 Igor Rondarev 2016-03-01T09:51:44Z http://community.qnx.com/sf/go/post115873 > I'll take a look when I get some time. Doctor, any hope? Fri, 26 Feb 2016 17:00:30 GMT http://community.qnx.com/sf/go/post115873 Mario Charest 2016-02-26T17:00:30Z http://community.qnx.com/sf/go/post115841 I believe this was fixed when we merged 5.3 into trunk, along with many other bug fixes. I suggest using that branch. Mon, 22 Feb 2016 21:06:35 GMT http://community.qnx.com/sf/go/post115841 Michael Daniels(deleted) 2016-02-22T21:06:35Z http://community.qnx.com/sf/go/post115832 Hi, The following program does not compile (linux host, qnx target) when using the gcc 5.1 branch: #include <immintrin.h> template <typename T> T func(const T &a, const T &b) { return a + b; } template <> int func<int>(const int &a, const int &b) { return a-b; } template <> __m128 func<__m128>(const __m128 &a, const __m128 &b) { return _mm_add_ps(a,b); } The specialization on __m128 fails with an error about __vector type attributes. I've traced this to the backported patches from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50800 (revision 987) http://community.qnx.com/viewvc/tools/gcc/trunk/gcc/cp/tree.c?view=markup&revision=987&root=core-dev-tools&system=exsy1011 Reverting those changes fixes the build problem. There are probably related patches that need to be added for the above code to work; but I could not easily determine what changes were needed (something to do with stripping certain kinds of attributes). Mon, 22 Feb 2016 16:10:43 GMT http://community.qnx.com/sf/go/post115832 Alex Khripin 2016-02-22T16:10:43Z http://community.qnx.com/sf/go/post115691 Now works just fine, thanks! Mon, 08 Feb 2016 06:29:35 GMT http://community.qnx.com/sf/go/post115691 Alexey Smirnov(deleted) 2016-02-08T06:29:35Z http://community.qnx.com/sf/go/post115690 I was under the mistaken impression that it would pick up whichever python it found in $PATH. Since that's not the case you would have to play around with symlinks to get the directories pointing to the system python. However it's probably easy to just put up a full python build. Give the one attached a try and let me know if you still have problems. Sat, 06 Feb 2016 17:52:27 GMT http://community.qnx.com/sf/go/post115690 Michael Daniels(deleted) 2016-02-06T17:52:27Z http://community.qnx.com/sf/go/post115681 > Thanks for the report. We are currently working on more complete packaging of > Python which should take care of problems like this. > > If you need to work around this in the mean time, you should be able to > install and use the python 2.x release from your Linux distribution instead of > this one. I have the same issue. But how can I use python 2.x release from xubuntu 15.10 x64 (my host) instead of shipped with an gdb-prereq-linux.tgz archive? Fri, 05 Feb 2016 12:52:10 GMT http://community.qnx.com/sf/go/post115681 Alexey Smirnov(deleted) 2016-02-05T12:52:10Z http://community.qnx.com/sf/go/post115673 Yup. It seems I didn't realize how old the thread was. Wed, 03 Feb 2016 23:30:33 GMT http://community.qnx.com/sf/go/post115673 Michael Daniels(deleted) 2016-02-03T23:30:33Z http://community.qnx.com/sf/go/post115672 > Try this. It's a local build of gdb-7.6 from the svn repo for a 64bit linux > host. I'm I right in assuming that's in regard to Rodney's post (From july), and NOT about the mkefs issue Wed, 03 Feb 2016 23:28:14 GMT http://community.qnx.com/sf/go/post115672 Mario Charest 2016-02-03T23:28:14Z http://community.qnx.com/sf/go/post115671 Try this. It's a local build of gdb-7.6 from the svn repo for a 64bit linux host. Wed, 03 Feb 2016 23:16:24 GMT http://community.qnx.com/sf/go/post115671 Michael Daniels(deleted) 2016-02-03T23:16:24Z http://community.qnx.com/sf/go/post115670 From the sounds of it, it's the 32bit tools that are getting tripped up on the resulting file. Something about the file must need the extra virtual address space to play with. Unfortunately we don't have 64bit host packages up on foundry. Wed, 03 Feb 2016 22:30:16 GMT http://community.qnx.com/sf/go/post115670 Michael Daniels(deleted) 2016-02-03T22:30:16Z http://community.qnx.com/sf/go/post115669 Thanks for the report. We are currently working on more complete packaging of Python which should take care of problems like this. If you need to work around this in the mean time, you should be able to install and use the python 2.x release from your Linux distribution instead of this one. Wed, 03 Feb 2016 21:51:47 GMT http://community.qnx.com/sf/go/post115669 Michael Daniels(deleted) 2016-02-03T21:51:47Z http://community.qnx.com/sf/go/post115637 Last week I played with the gold linker, kind of making it the default by overwritting stuff (sound of mad scientist rubbing his/jher hand), One of the target of my diabolical plan was ntox86-ld ! Seems to work fine for a week but today I was building images and some of them ended up being 130M instead of 2Meg. Sound of ballon deflating. Offset Size Entry Ramoff Target=Host 400000 440 0 --- ./x86/boot/sys/bios.boot 400440 100 ---- --- Startup-header 400540 14960 404e38 --- /tmp/fileKgYDol ########## It's this guy that was WAY to big. (here it's ok ) 414a60 5c ---- --- Image-header 414abc e04 ---- --- Image-directory 4158c0 0 ---- --- proc/boot/unlink_list=/tmp/f Sat, 30 Jan 2016 02:10:12 GMT http://community.qnx.com/sf/go/post115637 Mario Charest 2016-01-30T02:10:12Z http://community.qnx.com/sf/go/post115606 Hello! Seems than current python 2.7 build cannot work with gdb 7.x and Qt Creator IDE (Linux, at least with 3.2.0 and 3.5.1 versions of IDE). Steps to reproduce: - try to debug any Qt application using "Debug" button. Result: Debug feature does not work, "Window-> Views-> Debugger Log" contains at least these error lines: ------------------------- cut --------------------------- >&"Traceback (most recent call last):\n" >&" File \"<string>\", line 1, in <module>\n" >&" File \"/opt/qtcreator-3.2.0/share/qtcreator/debugger/gdbbridge.py\", line 14, in <module>\n" >&" import struct\n" >&" File \"/opt/650/host/linux/x86/usr/python27.svn/lib/python2.7/struct.py\", line 1, in <module>\n" >&" from _struct import *\n" >&"ImportError: No module named _struct\n" ------------------------- cut --------------------------- (full log is attached) help('modules') command also fails: ------------------------- cut --------------------------- Python 2.7.2 (default, Feb 22 2012, 13:21:29) [GCC 4.1.0] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> help('modules') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/opt/650/host/linux/x86/usr/python27/lib/python2.7/site.py", line 466, in __call__ import pydoc File "/opt/650/host/linux/x86/usr/python27/lib/python2.7/pydoc.py", line 55, in <module> import sys, imp, os, re, types, inspect, __builtin__, pkgutil File "/opt/650/host/linux/x86/usr/python27/lib/python2.7/inspect.py", line 41, in <module> from operator import attrgetter ImportError: No module named operator >>> ------------------------- cut --------------------------- Is any additional information needed? Regards, Igor Mon, 25 Jan 2016 15:44:26 GMT http://community.qnx.com/sf/go/post115606 Igor Rondarev 2016-01-25T15:44:26Z http://community.qnx.com/sf/go/post115589 I'll take a look when I get some time. Fri, 22 Jan 2016 13:06:41 GMT http://community.qnx.com/sf/go/post115589 Michael Daniels(deleted) 2016-01-22T13:06:41Z http://community.qnx.com/sf/go/post115587 > It was built for 660 and for libstdc++.so.6.0.17 (comes with gcc 4.7). > > I'll have a look at the other issue to see if it's related. > > Regards, > > Ryan Mansfield With Ryan gone, is there any hope of getting an updated 4.8.3 for QNX650 with this fix? Or is this a case of "told you not to use 6.5.0 and beta stuff". Fri, 22 Jan 2016 03:46:35 GMT http://community.qnx.com/sf/go/post115587 Mario Charest 2016-01-22T03:46:35Z http://community.qnx.com/sf/go/post115586 Ryan doesn't seem to be working for QNX anymore. Currently using 2.24. And yes C++11 works, mostly, as 4.8.3 is not fully compliant. -----Message d'origine----- De : John Hagen [mailto:community-noreply@qnx.com] Envoyé : 21 janvier 2016 18:37 À : general-toolchain <general-toolchain@community.qnx.com> Objet : Re: QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target > Can't you just use 4.8.3 and the bin utils for 6.5.0 ? > > Thanks, > Anton @Mario/@Ryan, What is the exact tag/release of bin utils that is required/recommended to use the 4.8.3 compiler targeting QNX 6.5? And would this then support C++11 library? Thanks, John _______________________________________________ General http://community.qnx.com/sf/go/post115585 To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com Thu, 21 Jan 2016 23:38:41 GMT http://community.qnx.com/sf/go/post115586 Mario Charest 2016-01-21T23:38:41Z http://community.qnx.com/sf/go/post115585 > Can't you just use 4.8.3 and the bin utils for 6.5.0 ? > > Thanks, > Anton @Mario/@Ryan, What is the exact tag/release of bin utils that is required/recommended to use the 4.8.3 compiler targeting QNX 6.5? And would this then support C++11 library? Thanks, John Thu, 21 Jan 2016 23:36:42 GMT http://community.qnx.com/sf/go/post115585 John Hagen(deleted) 2016-01-21T23:36:42Z http://community.qnx.com/sf/go/post115372 So this looks like it is a bug with the 4.9.3 compiler. If I run the 4.8.3 compiler, then I can compile a test application just fine. Tue, 22 Dec 2015 01:15:24 GMT http://community.qnx.com/sf/go/post115372 Rodney Dowdall(deleted) 2015-12-22T01:15:24Z http://community.qnx.com/sf/go/post115371 Hello Ah I see. So how do I invoke gcc directly? I tried running arm-unknown-nto-qnx6.6.0eabi-gcc on a simple test.c file, but the collect2 failed because it didn't recognize the -plugin option. Thanks, Rodney Tue, 22 Dec 2015 00:10:15 GMT http://community.qnx.com/sf/go/post115371 Rodney Dowdall(deleted) 2015-12-22T00:10:15Z http://community.qnx.com/sf/go/post115370 It will pass it to the compiler (cc1) directly, not through the compiler driver (gcc) that has the logic to handle the option. In order to support this, qcc would need to have some code added to handle the option in a similar fashion. ________________________________________ From: Rodney Dowdall [community-noreply@qnx.com] Sent: Monday, December 21, 2015 6:41 PM To: general-toolchain Subject: Re: RE: Specifying the -gsplit-dwarf option Hello Thanks for the response Michael. Would the -Wc,-gsplit-dwarf option not pass it to the gcc compiler? Thanks, Rodney _______________________________________________ General http://community.qnx.com/sf/go/post115369 To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com Mon, 21 Dec 2015 23:50:16 GMT http://community.qnx.com/sf/go/post115370 Michael Daniels(deleted) 2015-12-21T23:50:16Z http://community.qnx.com/sf/go/post115369 Hello Thanks for the response Michael. Would the -Wc,-gsplit-dwarf option not pass it to the gcc compiler? Thanks, Rodney Mon, 21 Dec 2015 23:41:38 GMT http://community.qnx.com/sf/go/post115369 Rodney Dowdall(deleted) 2015-12-21T23:41:38Z http://community.qnx.com/sf/go/post115368 This option is handled by the compiler driver, so using gcc directly will work but qcc doesn't currently handle it so it will essentially end up being silently ignored. ________________________________________ From: Rodney Dowdall [community-noreply@qnx.com] Sent: Monday, December 21, 2015 2:37 PM To: general-toolchain Subject: Specifying the -gsplit-dwarf option Hello Does the 4.9.3 compiler support the -gsplit-dwarf option? I am using the gold linker, and I have specified this option using both the -Wc,-gsplit-dwarf and just -gsplit-dwarf, but I do not seem to get a dwo file generated. Thanks, Rodney _______________________________________________ General http://community.qnx.com/sf/go/post115366 To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com Mon, 21 Dec 2015 23:03:12 GMT http://community.qnx.com/sf/go/post115368 Michael Daniels(deleted) 2015-12-21T23:03:12Z http://community.qnx.com/sf/go/post115366 Hello Does the 4.9.3 compiler support the -gsplit-dwarf option? I am using the gold linker, and I have specified this option using both the -Wc,-gsplit-dwarf and just -gsplit-dwarf, but I do not seem to get a dwo file generated. Thanks, Rodney Mon, 21 Dec 2015 19:37:20 GMT http://community.qnx.com/sf/go/post115366 Rodney Dowdall(deleted) 2015-12-21T19:37:20Z http://community.qnx.com/sf/go/post115294 Hello I figured it out. I had installed the 4.8.3 compiler after the 4.9.3 compiler. This caused the stdc++ library to be linked to the older library. Untarring the 4.9.3 compiler again solved the problem. Thanks, Rodney Sat, 12 Dec 2015 23:34:35 GMT http://community.qnx.com/sf/go/post115294 Rodney Dowdall(deleted) 2015-12-12T23:34:35Z http://community.qnx.com/sf/go/post115293 Hello I am trying to compile a c++ application with the 4.9.3 compiler. Eveything compiles, but the link phase produces the following errors: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)' Is there a command line option that needs to be specified in order to link in this symbol? Thanks, Rodney Sat, 12 Dec 2015 19:01:31 GMT http://community.qnx.com/sf/go/post115293 Rodney Dowdall(deleted) 2015-12-12T19:01:31Z http://community.qnx.com/sf/go/post114584 I am trying to build simple C++ executable with just released GCC 4.9.3. #include <stdexcept> int main() { throw std::runtime_error("foo"); return 0; } $ ntoarmv7-gcc -o comp.o -c main.cpp $ ntoarmv7-gcc comp.o -o comp -lstdc++ Getting next linker error: ~/opt/qnx650-gcc-4.9.3/host/linux/x86/usr/bin/arm-unknown-nto-qnx6.6.0eabi-ld: comp: hidden symbol `__aeabi_ldiv0' in ~/opt/qnx650-gcc-4.9.3/host/linux/x86/usr/lib/gcc/arm-unknown-nto-qnx6.6.0eabi/4.9.3/libgcc.a(_dvmd_nto.o) is referenced by DSO ~/opt/qnx650-gcc-4.9.3/host/linux/x86/usr/bin/arm-unknown-nto-qnx6.6.0eabi-ld: final link failed: Bad value collect2: error: ld returned 1 exit status Am I missing something? Building with GCC 4.8.1 does not produce same error. Fri, 02 Oct 2015 17:47:03 GMT http://community.qnx.com/sf/go/post114584 Daniel Levin(deleted) 2015-10-02T17:47:03Z http://community.qnx.com/sf/go/post114545 I would like a definite answer to this. I have 6.5.0 and am using the 4.8.3 compiler instead of 4.8.1. Any chance we can use std::thread, atomic, unique_ptr etc.? Tue, 29 Sep 2015 20:23:07 GMT http://community.qnx.com/sf/go/post114545 Sriram Sundararajan(deleted) 2015-09-29T20:23:07Z http://community.qnx.com/sf/go/post114538 Thank you for the fix. Will this be included in a new "File release" of this project? Tue, 29 Sep 2015 07:54:12 GMT http://community.qnx.com/sf/go/post114538 Matthias Gehre(deleted) 2015-09-29T07:54:12Z http://community.qnx.com/sf/go/post114516 It was built for 660 and for libstdc++.so.6.0.17 (comes with gcc 4.7). I'll have a look at the other issue to see if it's related. Regards, Ryan Mansfield Thu, 24 Sep 2015 18:09:09 GMT http://community.qnx.com/sf/go/post114516 Ryan Mansfield(deleted) 2015-09-24T18:09:09Z http://community.qnx.com/sf/go/post114515 Is the file ok to use with GCC 4.8.3 on 650? Or is it 660 only? -----Message d'origine----- De : Ryan Mansfield [mailto:community-noreply@qnx.com] Envoyé : 24 septembre 2015 13:57 À : general-toolchain@community.qnx.com Objet : Re: std::mutex::lock fails when on same stack address as another mutex before Hi Matthias, Thank you for your report and analysis. I've open issue #1328672 to track the resolution. Attached is a libstdc++.so.6.0.17 built with the defines added to os_defines.h. After your test case no longer throws the exception. Regards, Ryan Mansfield _______________________________________________ General http://community.qnx.com/sf/go/post114512 To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com Thu, 24 Sep 2015 18:04:10 GMT http://community.qnx.com/sf/go/post114515 Mario Charest 2015-09-24T18:04:10Z http://community.qnx.com/sf/go/post114514 Ryan, Related: Check out case 00139008 and bug report (JIRA ID 812757) - Cheers Thu, 24 Sep 2015 18:02:12 GMT http://community.qnx.com/sf/go/post114514 Mario Charest 2015-09-24T18:02:12Z http://community.qnx.com/sf/go/post114512 Hi Matthias, Thank you for your report and analysis. I've open issue #1328672 to track the resolution. Attached is a libstdc++.so.6.0.17 built with the defines added to os_defines.h. After your test case no longer throws the exception. Regards, Ryan Mansfield Thu, 24 Sep 2015 17:56:47 GMT http://community.qnx.com/sf/go/post114512 Ryan Mansfield(deleted) 2015-09-24T17:56:47Z http://community.qnx.com/sf/go/post114509 The workaround is not working in all cases, because some code in libstdc++.so needs to be recompiled with those flags. Test case: i486-pc-nto-qnx6.6.0-g++ future_loop.cpp -std=gnu++11 -o future_loop -static-libstdc++ -D_GTHREAD_USE_MUTEX_INIT_FUNC -D_GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC -D_GTHREAD_USE_COND_INIT_FUNC -ggdb3 -O0 Crashes with terminate called after throwing an instance of 'std::system_error' what(): Resource busy With _GTHREAD_USE_MUTEX_INIT_FUNC, std::mutex destructor changes. Because the destructor of std::future (more specifically: std::__future_base::_State_base::~_State_base) is compiled into libstdc++, it still calls the old destructor of std::mutex. Can you please rebuild the gcc package with those changes, or give me instructions on how to do so? Thu, 24 Sep 2015 10:54:04 GMT http://community.qnx.com/sf/go/post114509 Matthias Gehre(deleted) 2015-09-24T10:54:04Z http://community.qnx.com/sf/go/post114507 The same problem also affects rwlock and condition variables, which need -D_GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC -D_GTHREAD_USE_COND_INIT_FUNC. Thu, 24 Sep 2015 08:26:49 GMT http://community.qnx.com/sf/go/post114507 Matthias Gehre(deleted) 2015-09-24T08:26:49Z http://community.qnx.com/sf/go/post114497 Hello, I ported our C++11 application to QNX, but occasionally I get failures when trying to lock a std::mutex which resides on the stack. I'm currently testing this on SDP 6.6, but I also need to support SDP 6.5. This is why we are using libstdc++ instead of libcpp. I reduced the problem to the three minimal testcases (see attached). The problem seems to be that std::mutex initializes its pthread_mutex by PTHREAD_MUTEX_INITIALIZER. This mutex can be on the stack, but PTHREAD_MUTEX_INITIALIZER is only allowed for static (non-stack) variables See QNX_Neutrino_RTOS_C_Library_Reference.pdf (for SDP 6.6.0), p. 2317: "You can initialize a _statically_ allocated mutex with the default attributes by assigning to it the macro PTHREAD_MUTEX_INITIALIZER or PTHREAD_RMUTEX_INITIALIZER (for recursive mutexes)." Most modern OS have dropped the "statically" from the restrictons, thus libstdc++ uses PTHREAD_RMUTEX_INITIALIZER by default. The workaround is to add -D_GTHREAD_USE_MUTEX_INIT_FUNC to the compile arguments. This should go into os_defines.h for a real fix (that's how libstdc++ does it on mingw) Test cases: (run on the QNX 6.6.0 vmware image) Stock SDP 6.6.0: qcc tst_func.cpp -o tst_func -V4.7.3,gcc_ntox86_gpp -std=gnu++11 qcc tst_loop.cpp -o tst_loop -V4.7.3,gcc_ntox86_gpp -std=gnu++11 Both print "std::mutex::lock caused std::system_error at i = 1 with code generic:22 meaning Invalid argument" GCC 4.8.3 from linux-gcc-4.8.3-qnx660.tar.gz from this foundry27 project qcc tst_func.cpp -o tst_func -V4.8.3,gcc_ntox86_gpp -std=gnu++11 qcc tst_loop.cpp -o tst_loop -V4.8.3,gcc_ntox86_gpp -std=gnu++11 Both print "std::mutex::lock caused std::system_error at i = 1 with code generic:22 meaning Invalid argument" qcc tst_SyncMutexLock_r.cpp -o tst_SyncMutexLock_r Both print "Second SyncMutexLock_r failed Second SyncMutexUnlock_r failed" Best wishes, Matthias Gehre Wed, 23 Sep 2015 13:49:27 GMT http://community.qnx.com/sf/go/post114497 Matthias Gehre(deleted) 2015-09-23T13:49:27Z http://community.qnx.com/sf/go/post114253 The compiler itself is only available for x86 hosts (Neutrino, Linux or Windows) for 6.5.0. Tue, 11 Aug 2015 19:39:02 GMT http://community.qnx.com/sf/go/post114253 Dave Nickerson 2015-08-11T19:39:02Z http://community.qnx.com/sf/go/post114243 Hi there, I'm looking for gcc compiler that works on Neutrino 6.5.0, arm based. Can anyone point me where to find them ? Many thanks! Randy. Mon, 10 Aug 2015 07:04:25 GMT http://community.qnx.com/sf/go/post114243 Zhiying Xiang(deleted) 2015-08-10T07:04:25Z http://community.qnx.com/sf/go/post114156 Hello Ryan Just to follow up, the -fuse-ld=gold did work, and the gold linker was able to link the shared object. Now that I have it linked though, there isn't much that I can do with it. Most of the tools link ntox86-strip and ntx86-objdump report the file as being truncated. I had to use the strip utility from linux to strip the library down so that I could run it on the target. Once I got it running on the target, I tried to connect with it with gdb, but it has a problem with the shared object as well and says that the file is truncated. I tried the following sequence thinking that loading the sym file wouldn't have the size limit on it: objcopy --only-keep-debug mylib.so mylib.so.sym strip --strip-all -R .ident -R .comment mylib.so ntox86-objcopy --only-keep-debug mylib.so mylib.so.sym but gdb can't load the sym file either. I'm compiling my library with the following options to lower the size: -V4.8.3,gcc_ntox86_gpp -lang-c++ -fuse-ld=gold -g -Os -fno-rtti -Wformat -Wformat-security -Werror=format-security -Wl,--no-keep-memory -fmessage-length=0 -Wl,--warn-shared-textrel -Wa,--compress-debug-sections Just wondering if there is anything else I can do to work around the issue. Thu, 23 Jul 2015 14:05:14 GMT http://community.qnx.com/sf/go/post114156 Rodney Dowdall(deleted) 2015-07-23T14:05:14Z http://community.qnx.com/sf/go/post114139 -fuse-ld=gold wasn't supported in gcc 4.4. If you're using the 4.8 packages on foundry, it should support -fuse-ld=gold. You should be able to check by doing -v and seeing which underlying linker is being invoked. Regards, Ryan Mansfield Thu, 16 Jul 2015 18:14:01 GMT http://community.qnx.com/sf/go/post114139 Ryan Mansfield(deleted) 2015-07-16T18:14:01Z http://community.qnx.com/sf/go/post114136 Hello Ryan The 64 bit linker worked. I am not sure if the GOLD Linker worked. I wasn't sure how to tell qcc how to use the gold linker. I tried just linking i486-pc-nto-qnx6.5.0-ld to ntox86-ld.gold and rerunning my link command, but it still gave me the exhausted memory error. So either, it doesn't work, or I didn't set it up properly. I just copied the i486-pc-nto-qnx6.5.0-ld over top of the link to get it go with the 64 bit one. Does the -fuse-ld=gold work with gcc? Thanks, Rodney Thu, 16 Jul 2015 18:02:29 GMT http://community.qnx.com/sf/go/post114136 Rodney Dowdall(deleted) 2015-07-16T18:02:29Z http://community.qnx.com/sf/go/post114130 Thanks Ryan. I'll give these a try and let you know how it goes. Wed, 15 Jul 2015 13:59:43 GMT http://community.qnx.com/sf/go/post114130 Rodney Dowdall(deleted) 2015-07-15T13:59:43Z http://community.qnx.com/sf/go/post114129 Attached is a Linux x86_64 hosted bfd and gold ld for 6.5.0SP1. Let me know if you have any problems. Regards, Ryan Mansfield Wed, 15 Jul 2015 13:57:22 GMT http://community.qnx.com/sf/go/post114129 Ryan Mansfield(deleted) 2015-07-15T13:57:22Z http://community.qnx.com/sf/go/post114128 If won't get around the limitations of the 32bit vaddrs, but gold does seem to use less memory than the BFD linker. We've hit cases linking large C++ projects (e.g. webkit or chromium), where gold used much less and bfd was exhausting the memory on the system. Regards, Ryan Mansfield On 15-07-15 09:19 AM, Rodney Dowdall wrote: > Hey Ryan > > So if I build it, would it get around the 4 GB link limit that the default linker has? > > Thanks, > Rodney > > > > > > _______________________________________________ > > General > http://community.qnx.com/sf/go/post114127 > To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com > Wed, 15 Jul 2015 13:25:56 GMT http://community.qnx.com/sf/go/post114128 Ryan Mansfield(deleted) 2015-07-15T13:25:56Z http://community.qnx.com/sf/go/post114127 Hey Ryan So if I build it, would it get around the 4 GB link limit that the default linker has? Thanks, Rodney Wed, 15 Jul 2015 13:19:24 GMT http://community.qnx.com/sf/go/post114127 Rodney Dowdall(deleted) 2015-07-15T13:19:24Z http://community.qnx.com/sf/go/post114126 Yes, it should work on 6.5.0SP1 Regards, Ryan Mansfield Wed, 15 Jul 2015 13:16:10 GMT http://community.qnx.com/sf/go/post114126 Ryan Mansfield(deleted) 2015-07-15T13:16:10Z http://community.qnx.com/sf/go/post114125 Hello I noticed the gold linker is checked in to the binutils source tree. Is this something that could be compiled for QNX 6.5.0 SP1? Thanks, Rodney Wed, 15 Jul 2015 12:58:17 GMT http://community.qnx.com/sf/go/post114125 Rodney Dowdall(deleted) 2015-07-15T12:58:17Z http://community.qnx.com/sf/go/post114033 .. good lord. I thought of everything but not that. Thanks a lot (also for this super quick reply), it's working now! I tested everything and somehow I suspected something like this but I really thought I did install the 32bit libs already. Check's in the mail! ;) Thanks again. Fri, 26 Jun 2015 19:28:20 GMT http://community.qnx.com/sf/go/post114033 Jane McIllen(deleted) 2015-06-26T19:28:20Z http://community.qnx.com/sf/go/post114031 If you're running it on a 64bit system, the toolchain is built against 2bit libs? You might have to install the libstdc++ i386 lib e.g. sudo apt-get install lib32stdc++6 on ubuntu (or equivalent with other distros/package managers) Regards, Ryan Mansfield On 15-06-26 03:03 PM, Jane McIllen wrote: > I'm trying to use the current qcc compiler (4.8.3) for QNX650 on Linux. So far it's just extracting and copy/pasting. > > But when I try to build my libraries I get the error msg: > > i486-pc-nto-qnx6.5.0-g++: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory > > When I ldd on i486-pc-nto-qnx6.5.0-g++ then I get indeed > > ldd /../qnx650/host/linux/x86/usr/bin/i486-pc-nto-qnx6.5.0-g++-4.8.3 > linux-gate.so.1 => (0xf7784000) > libstdc++.so.6 => not found > libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7721000) > libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf7703000) > libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7555000) > /lib/ld-linux.so.2 (0xf7785000) > > Apperently all the other libraries can be found. > > What am I doing wrong and how can I resolve this? > > > > > _______________________________________________ > > General > http://community.qnx.com/sf/go/post114030 > To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com > Fri, 26 Jun 2015 19:08:56 GMT http://community.qnx.com/sf/go/post114031 Ryan Mansfield(deleted) 2015-06-26T19:08:56Z http://community.qnx.com/sf/go/post114030 I'm trying to use the current qcc compiler (4.8.3) for QNX650 on Linux. So far it's just extracting and copy/pasting. But when I try to build my libraries I get the error msg: i486-pc-nto-qnx6.5.0-g++: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory When I ldd on i486-pc-nto-qnx6.5.0-g++ then I get indeed ldd /../qnx650/host/linux/x86/usr/bin/i486-pc-nto-qnx6.5.0-g++-4.8.3 linux-gate.so.1 => (0xf7784000) libstdc++.so.6 => not found libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7721000) libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf7703000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7555000) /lib/ld-linux.so.2 (0xf7785000) Apperently all the other libraries can be found. What am I doing wrong and how can I resolve this? Fri, 26 Jun 2015 19:03:33 GMT http://community.qnx.com/sf/go/post114030 Jane McIllen(deleted) 2015-06-26T19:03:33Z http://community.qnx.com/sf/go/post114001 So is there a way to turn off exceptions when using the -std=gnu++11 option? The -fno-exceptions causes a compilation error in one of the standard header files. Not a big deal if they can't be turned off. Just thought I would ask. Thanks, Rodney Mon, 22 Jun 2015 13:13:12 GMT http://community.qnx.com/sf/go/post114001 Rodney Dowdall(deleted) 2015-06-22T13:13:12Z http://community.qnx.com/sf/go/post113996 A very disturbing thread. I was hoping to use QNX to develop on a PPC platform, but no it seems pointless. Sun, 21 Jun 2015 14:53:00 GMT http://community.qnx.com/sf/go/post113996 JAMES IGOU(deleted) 2015-06-21T14:53:00Z http://community.qnx.com/sf/go/post113995 Thanks Ryan, that solved it. Sat, 20 Jun 2015 00:13:42 GMT http://community.qnx.com/sf/go/post113995 Rodney Dowdall(deleted) 2015-06-20T00:13:42Z http://community.qnx.com/sf/go/post113993 Use -std=gnu++0x or -std=gnu++11. Regards, Ryan Mansfield Original Message From: Rodney Dowdall Sent: Friday, June 19, 2015 7:20 PM To: general-toolchain Reply To: general-toolchain@community.qnx.com Subject: Re: RE: Can't find array include when using "4.8.3,gcc_ntox86_cpp-ne" variant So it looks like the following define in yvals.h is getting missed: #if defined(__GNUC__) && (2 <= __GNUC__) && (!__STRICT_ANSI__) If I specify -Wc,-std=c++11 when I compile the attached test app then the compilation will fail. If I take out that -Wc,-std=c++11 then we go in to that define in yvals.h and then the define #define _C99 1 happens and everything compiles. So is _C99 supposed to be defined when you use -Wc,-std=c++11 or is there another problem? Thanks, Rodney _______________________________________________ General http://community.qnx.com/sf/go/post113992 To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com Fri, 19 Jun 2015 23:26:23 GMT http://community.qnx.com/sf/go/post113993 Ryan Mansfield(deleted) 2015-06-19T23:26:23Z http://community.qnx.com/sf/go/post113992 So it looks like the following define in yvals.h is getting missed: #if defined(__GNUC__) && (2 <= __GNUC__) && (!__STRICT_ANSI__) If I specify -Wc,-std=c++11 when I compile the attached test app then the compilation will fail. If I take out that -Wc,-std=c++11 then we go in to that define in yvals.h and then the define #define _C99 1 happens and everything compiles. So is _C99 supposed to be defined when you use -Wc,-std=c++11 or is there another problem? Thanks, Rodney Fri, 19 Jun 2015 23:20:18 GMT http://community.qnx.com/sf/go/post113992 Rodney Dowdall(deleted) 2015-06-19T23:20:18Z http://community.qnx.com/sf/go/post113991 I guess I was wrong about the gpp only being available for x86. Seems there is a variant for other targets as well. I'll see what the exception enablement does to the code size. However, how does one use math functions when using C++11? I have tried including cmath only and with math.h, and I have tried different orders. I have tried undeffing the functions that I want to use, but to no avail. If I want to use copysign in my code for example, how do I do it? Calling std::copysign doesn't work, and neither does copysign. Thanks, Rodney Fri, 19 Jun 2015 19:57:16 GMT http://community.qnx.com/sf/go/post113991 Rodney Dowdall(deleted) 2015-06-19T19:57:16Z http://community.qnx.com/sf/go/post113990 > You need to switch to gnu C++ lib. Otherwise chaos will ensue. > > -----Message d'origine----- > De : Rodney Dowdall [mailto:community-noreply@qnx.com] > Envoyé : 19 juin 2015 14:23 > À : general-toolchain > Objet : Re: Can't find array include when using "4.8.3,gcc_ntox86_cpp-ne" > variant > > So if I add the following to my command line: > > -I $QNX_TARGET/qnx6/usr/include/c++/4.8.3/ -I $QNX_TARGET/target/qnx6/usr/ > include/c++/4.8.3/i486-pc-nto-qnx6.5.0/ > > then things compile. But that seems oh so very wrong. > > Thanks, > Rodney > > > > > _______________________________________________ > > General > http://community.qnx.com/sf/go/post113988 > To cancel your subscription to this discussion, please e-mail general- > toolchain-unsubscribe@community.qnx.com Thanks Mario, but if I switch to the GNU C++ lib then I can't disable exceptions. Also the GNU CPP lib only seems to be available for x86. I'll do the switch and compile for x86 for now. Fri, 19 Jun 2015 18:26:46 GMT http://community.qnx.com/sf/go/post113990 Rodney Dowdall(deleted) 2015-06-19T18:26:46Z http://community.qnx.com/sf/go/post113989 You need to switch to gnu C++ lib. Otherwise chaos will ensue. -----Message d'origine----- De : Rodney Dowdall [mailto:community-noreply@qnx.com] Envoyé : 19 juin 2015 14:23 À : general-toolchain Objet : Re: Can't find array include when using "4.8.3,gcc_ntox86_cpp-ne" variant So if I add the following to my command line: -I $QNX_TARGET/qnx6/usr/include/c++/4.8.3/ -I $QNX_TARGET/target/qnx6/usr/include/c++/4.8.3/i486-pc-nto-qnx6.5.0/ then things compile. But that seems oh so very wrong. Thanks, Rodney _______________________________________________ General http://community.qnx.com/sf/go/post113988 To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com Fri, 19 Jun 2015 18:24:35 GMT http://community.qnx.com/sf/go/post113989 Mario Charest 2015-06-19T18:24:35Z http://community.qnx.com/sf/go/post113988 So if I add the following to my command line: -I $QNX_TARGET/qnx6/usr/include/c++/4.8.3/ -I $QNX_TARGET/target/qnx6/usr/include/c++/4.8.3/i486-pc-nto-qnx6.5.0/ then things compile. But that seems oh so very wrong. Thanks, Rodney Fri, 19 Jun 2015 18:23:28 GMT http://community.qnx.com/sf/go/post113988 Rodney Dowdall(deleted) 2015-06-19T18:23:28Z http://community.qnx.com/sf/go/post113987 On 15-06-19 01:48 PM, Rodney Dowdall wrote: >> <array> was only added in C++11, and the Dinkumware C++ library that >> shipped with QNX 6.5.0 in 2010 was C++98. It's available in the GNU >> libstdc++ in 6.5.0 as part of the experimental C++0x support. >> >> Regards, >> >> Ryan Mansfield > > So when I download the updates (i.e.: linux-gcc-4.8.3-qnx65x.tar.gz) from Foundary, that doesn't include updated Dinkum libraries? Does the "-Wc,-std=c++0x" not turn on that C++0x support? Or is it a different option? Only the GNU libstdc++ updates are packaged with gcc packages on foundry27. -Wc,-std=c++0x turns on the core language level but doesn't add support in the C++ STL headers. Regards, Ryan Mansfield Fri, 19 Jun 2015 17:51:25 GMT http://community.qnx.com/sf/go/post113987 Ryan Mansfield(deleted) 2015-06-19T17:51:25Z http://community.qnx.com/sf/go/post113986 > <array> was only added in C++11, and the Dinkumware C++ library that > shipped with QNX 6.5.0 in 2010 was C++98. It's available in the GNU > libstdc++ in 6.5.0 as part of the experimental C++0x support. > > Regards, > > Ryan Mansfield So when I download the updates (i.e.: linux-gcc-4.8.3-qnx65x.tar.gz) from Foundary, that doesn't include updated Dinkum libraries? Does the "-Wc,-std=c++0x" not turn on that C++0x support? Or is it a different option? Fri, 19 Jun 2015 17:48:54 GMT http://community.qnx.com/sf/go/post113986 Rodney Dowdall(deleted) 2015-06-19T17:48:54Z http://community.qnx.com/sf/go/post113985 <array> was only added in C++11, and the Dinkumware C++ library that shipped with QNX 6.5.0 in 2010 was C++98. It's available in the GNU libstdc++ in 6.5.0 as part of the experimental C++0x support. Regards, Ryan Mansfield Fri, 19 Jun 2015 17:44:03 GMT http://community.qnx.com/sf/go/post113985 Ryan Mansfield(deleted) 2015-06-19T17:44:03Z http://community.qnx.com/sf/go/post113984 Hello I am trying to build something using the "4.8.3,gcc_ntox86_cpp-ne" variant, but when a header file tries to include the array include file it says that it can't find it. Here is my compile line minus project specific defines: home/rodney/tools/qnx650/host/linux/x86/usr/bin/qcc -lang-c++ -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D__QNXNTO__ -V4.8.3,gcc_ntox86_cpp-ne -Wc,-std=c++0x -lang-c++ -fno-rtti -Wformat -Wformat-security -Werror=format-security -Wl,--no-keep-memory -Wc,-std=c++11 -fno-exceptions -fno-strict-aliasing -fno-rtti -Wall -Wextra -Wcast-align -Wformat-security -Wmissing-format-attribute -Wpointer-arith -Wundef -Wwrite-strings -fPIC The error I get is: fatal error: array: No such file or directory #include <array> Thanks, Rodney Fri, 19 Jun 2015 17:37:15 GMT http://community.qnx.com/sf/go/post113984 Rodney Dowdall(deleted) 2015-06-19T17:37:15Z http://community.qnx.com/sf/go/post113972 Yes, I've reconfigured and rebuilt gcc. Thu, 18 Jun 2015 09:21:53 GMT http://community.qnx.com/sf/go/post113972 Maxim Kuzmin(deleted) 2015-06-18T09:21:53Z http://community.qnx.com/sf/go/post113964 On 15-06-17 04:23 AM, Maxim Kuzmin wrote: > I've successfully built binutils and updated /opt/qnx650/host/linux/x86/usr/bin/ntoppc-as, but unfortunately, I've got same error. This is output from gcc with "--verbose" flag: > > /opt/qnx650/host/linux/x86/usr/bin/ntoppc-as --gdwarf2 -v -I. -I. -I../.././gcc -I/home/max/gcc/gcc_4_6_branch/libgcc -I/home/max/gcc/gcc_4_6_branch/libgcc/. -I/home/max/gcc/gcc_4_6_branch/libgcc/../gcc -I/home/max/gcc/gcc_4_6_branch/libgcc/../include -mppc -many -V -Qy -mbig -o crtsavfpr.o /tmp/ccR7N05D.s > GNU assembler version 2.25 (powerpc-unknown-nto-qnx6.5.0) using BFD version (GNU Binutils) 2.25 > ../.././gcc/crtsavfpr.S: Assembler messages: > ../.././gcc/crtsavfpr.S:41: Error: unrecognized opcode: cfi_endproc' > ../.././gcc/crtsavfpr.S:79: Error: unrecognized opcode: cfi_startproc' > > Am I need to update other executables from binutils? Did you reconfigure and rebuild against the updated binutils? i.e. config/rs6000/ppc-asm.h has #ifdef HAVE_GAS_CFI_DIRECTIVE # define CFI_STARTPROC .cfi_startproc # define CFI_ENDPROC .cfi_endproc # define CFI_OFFSET(reg, off) .cfi_offset reg, off # define CFI_DEF_CFA_REGISTER(reg) .cfi_def_cfa_register reg # define CFI_RESTORE(reg) .cfi_restore reg #else # define CFI_STARTPROC # define CFI_ENDPROC # define CFI_OFFSET(reg, off) # define CFI_DEF_CFA_REGISTER(reg) # define CFI_RESTORE(reg) #endif and HAVE_HAS_CFI_DIRECTIVE will be defined by configure. The binutils 2.25 that you just build should support the .cfi directives. Regards, Ryan Mansfield Wed, 17 Jun 2015 13:59:41 GMT http://community.qnx.com/sf/go/post113964 Ryan Mansfield(deleted) 2015-06-17T13:59:41Z http://community.qnx.com/sf/go/post113963 I've successfully built binutils and updated /opt/qnx650/host/linux/x86/usr/bin/ntoppc-as, but unfortunately, I've got same error. This is output from gcc with "--verbose" flag: /opt/qnx650/host/linux/x86/usr/bin/ntoppc-as --gdwarf2 -v -I. -I. -I../.././gcc -I/home/max/gcc/gcc_4_6_branch/libgcc -I/home/max/gcc/gcc_4_6_branch/libgcc/. -I/home/max/gcc/gcc_4_6_branch/libgcc/../gcc -I/home/max/gcc/gcc_4_6_branch/libgcc/../include -mppc -many -V -Qy -mbig -o crtsavfpr.o /tmp/ccR7N05D.s GNU assembler version 2.25 (powerpc-unknown-nto-qnx6.5.0) using BFD version (GNU Binutils) 2.25 ../.././gcc/crtsavfpr.S: Assembler messages: ../.././gcc/crtsavfpr.S:41: Error: unrecognized opcode: cfi_endproc' ../.././gcc/crtsavfpr.S:79: Error: unrecognized opcode: cfi_startproc' Am I need to update other executables from binutils? Wed, 17 Jun 2015 08:23:02 GMT http://community.qnx.com/sf/go/post113963 Maxim Kuzmin(deleted) 2015-06-17T08:23:02Z http://community.qnx.com/sf/go/post113959 On 15-06-16 09:51 AM, Maxim Kuzmin wrote: > OK, I've solved this problem, but I've got another one: > > make[2]: Entering directory `/home/max/gcc/build/powerpc-unknown-nto-qnx6.5.0/libgcc' > # If this is the top-level multilib, build all the other > # multilibs. > powerpc-unknown-nto-qnx6.5.0-gcc -g -D__GNU_STDC_INLINE__ -O2 -g -D__GNU_STDC_INLINE__ -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fexceptions -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector -I. -I. -I../.././gcc -I/home/max/gcc/gcc_4_6_branch/libgcc -I/home/max/gcc/gcc_4_6_branch/libgcc/. -I/home/max/gcc/gcc_4_6_branch/libgcc/../gcc -I/home/max/gcc/gcc_4_6_branch/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o crtsavfpr.o -MT crtsavfpr.o -MD -MP -MF crtsavfpr.dep -c -xassembler-with-cpp ../.././gcc/crtsavfpr.S > ../.././gcc/crtsavfpr.S: Assembler messages: > ../.././gcc/crtsavfpr.S:41: Error: Unrecognized opcode: `cfi_startproc' > ../.././gcc/crtsavfpr.S:79: Error: Unrecognized opcode: `cfi_endproc' > make[2]: *** [crtsavfpr.o] Error 1 > make[2]: Leaving directory `/home/max/gcc/build/powerpc-unknown-nto-qnx6.5.0/libgcc' > make[1]: *** [all-target-libgcc] Error 2 > make[1]: Leaving directory `/home/max/gcc/build' > make: *** [all] Error 2 > > How to fix it? Your binutils are too old. Build the trunk binutils for ppc. Regards, Ryan Mansfield Tue, 16 Jun 2015 13:52:35 GMT http://community.qnx.com/sf/go/post113959 Ryan Mansfield(deleted) 2015-06-16T13:52:35Z http://community.qnx.com/sf/go/post113958 OK, I've solved this problem, but I've got another one: make[2]: Entering directory `/home/max/gcc/build/powerpc-unknown-nto-qnx6.5.0/libgcc' # If this is the top-level multilib, build all the other # multilibs. powerpc-unknown-nto-qnx6.5.0-gcc -g -D__GNU_STDC_INLINE__ -O2 -g -D__GNU_STDC_INLINE__ -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fexceptions -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector -I. -I. -I../.././gcc -I/home/max/gcc/gcc_4_6_branch/libgcc -I/home/max/gcc/gcc_4_6_branch/libgcc/. -I/home/max/gcc/gcc_4_6_branch/libgcc/../gcc -I/home/max/gcc/gcc_4_6_branch/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o crtsavfpr.o -MT crtsavfpr.o -MD -MP -MF crtsavfpr.dep -c -xassembler-with-cpp ../.././gcc/crtsavfpr.S ../.././gcc/crtsavfpr.S: Assembler messages: ../.././gcc/crtsavfpr.S:41: Error: Unrecognized opcode: `cfi_startproc' ../.././gcc/crtsavfpr.S:79: Error: Unrecognized opcode: `cfi_endproc' make[2]: *** [crtsavfpr.o] Error 1 make[2]: Leaving directory `/home/max/gcc/build/powerpc-unknown-nto-qnx6.5.0/libgcc' make[1]: *** [all-target-libgcc] Error 2 make[1]: Leaving directory `/home/max/gcc/build' make: *** [all] Error 2 How to fix it? Tue, 16 Jun 2015 13:51:13 GMT http://community.qnx.com/sf/go/post113958 Maxim Kuzmin(deleted) 2015-06-16T13:51:13Z http://community.qnx.com/sf/go/post113937 Hello, It's me again and now I'm trying to build GCC for powerpc-unknown-nto-qnx6.5.0 using cross-compilation tools for linux-x86 host. Compilation fails with message: make[4]: Entering directory '/home/max/gcc/build/powerpc-unknown-nto-qnx6.5.0/pic/libgcc' # If this is the top-level multilib, build all the other # multilibs. powerpc-unknown-nto-qnx6.5.0-gcc -g -O2 -fpic -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fexceptions -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fexceptions -I. -I. -I../../.././gcc -I/home/max/gcc/trunk/libgcc -I/home/max/gcc/trunk/libgcc/. -I/home/max/gcc/trunk/libgcc/../gcc -I/home/max/gcc/trunk/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /home/max/gcc/trunk/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS cc1: error: unrecognized command line option -fbuilding-libgcc Makefile:466: recipe for target '_muldi3.o' failed make[4]: *** [_muldi3.o] Error 1 make[4]: Leaving directory '/home/max/gcc/build/powerpc-unknown-nto-qnx6.5.0/pic/libgcc' Makefile:1154: recipe for target 'multi-do' failed make[3]: *** [multi-do] Error 1 make[3]: Leaving directory '/home/max/gcc/build/powerpc-unknown-nto-qnx6.5.0/libgcc' Makefile:117: recipe for target 'all-multi' failed make[2]: *** [all-multi] Error 2 make[2]: Leaving directory '/home/max/gcc/build/powerpc-unknown-nto-qnx6.5.0/libgcc' Makefile:12916: recipe for target 'all-target-libgcc' failed make[1]: *** [all-target-libgcc] Error 2 make[1]: Leaving directory '/home/max/gcc/build' Makefile:877: recipe for target 'all' failed make: *** [all] Error 2 GCC 5.1, downloaded from f27svn.qnx.com/svn/repos/core-dev-tools Configuration options: --build=i686-pc-linux-gnu --host=powerpc-unknown-nto-qnx6.5.0 --target=powerpc-unknown-nto-qnx6.5.0 --with-bugurl=no --program-prefix=ntoppc- --enable-languages=c,c++ --verbose --without-expat --with-expat=no --with-python=no --disable-nls Tue, 09 Jun 2015 10:35:49 GMT http://community.qnx.com/sf/go/post113937 Maxim Kuzmin(deleted) 2015-06-09T10:35:49Z http://community.qnx.com/sf/go/post113890 I tried below code as a cross-platform solution to obtain unique id and it appears to work on Linux, Mac and Windows (maybe I'm lucky). On the other hand thread-ids are being reused after thread termination (join) in the same process on QNX. uint32_t MyGetTid (void) { uint32_t tid = ~0U; #if defined(__linux__) tid = syscall(SYS_gettid); #elif defined(__APPLE__) // Mac OS >= 10.6 has a system call equivalent to Linux's gettid() tid = syscall(SYS_thread_selfid); #elif defined _WIN32 tid = GetCurrentThreadId(); #elif defined(__ANDROID__) tid = gettid(); #elif defined(__QNX__) // FIXME: gettid() appears to reuse the thread-id on QNX tid = gettid(); #endif return tid; } Mon, 01 Jun 2015 16:36:33 GMT http://community.qnx.com/sf/go/post113890 Mayank Jain(deleted) 2015-06-01T16:36:33Z http://community.qnx.com/sf/go/post113889 If this is related to the MIB3 logging requirements the closest we have is maybe to use. volatile struct _thread_local_storage *tls = LIBC_TLS(); tls->__owner which will give you a system wide unique id, but only for that instance, if processes or thread ends it can be reused. But then again you have the same issue for gettid. So if you want runtime unique you'll need a custom solution for both linux and qnx, with a value larger than 32bit. -----Original Message----- From: Mayank Jain [mailto:community-noreply@qnx.com] Sent: Montag, 1. Juni 2015 14:14 To: general-toolchain Subject: API for unique thread-id in QNX Is there any API to obtain *unique* thread-id at least at the process level (if not across processes) in the QNX? Like Linux and Android support gettid API/syscall which returns unique thread-id. Any help is highly appreciated. Please note Id obtained by pthread_self() may be reused after a terminated thread has been joined, or a detached thread has terminated. _______________________________________________ General http://community.qnx.com/sf/go/post113881 To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com Mon, 01 Jun 2015 16:10:10 GMT http://community.qnx.com/sf/go/post113889 John Kearney 2015-06-01T16:10:10Z http://community.qnx.com/sf/go/post113882 You could use a pthread key and store the value of a global counter which you could use as a unique id? Mon, 01 Jun 2015 12:17:31 GMT http://community.qnx.com/sf/go/post113882 Gervais Mulongoy 2015-06-01T12:17:31Z http://community.qnx.com/sf/go/post113881 Is there any API to obtain *unique* thread-id at least at the process level (if not across processes) in the QNX? Like Linux and Android support gettid API/syscall which returns unique thread-id. Any help is highly appreciated. Please note Id obtained by pthread_self() may be reused after a terminated thread has been joined, or a detached thread has terminated. Mon, 01 Jun 2015 12:14:23 GMT http://community.qnx.com/sf/go/post113881 Mayank Jain(deleted) 2015-06-01T12:14:23Z http://community.qnx.com/sf/go/post113828 There is no memory fault now, but debug process of some program terminates with signal "illegal instruction". Besides that, sometimes it fails to load my program. Anyway, thanks for help! Mon, 18 May 2015 08:52:09 GMT http://community.qnx.com/sf/go/post113828 Maxim Kuzmin(deleted) 2015-05-18T08:52:09Z http://community.qnx.com/sf/go/post113824 Touch those files that want to get regenerated E.g. $ touch gdb-6.8/bfd/doc/bfd.info Fri, 15 May 2015 14:23:34 GMT http://community.qnx.com/sf/go/post113824 Aleksandar Ristovski(deleted) 2015-05-15T14:23:34Z http://community.qnx.com/sf/go/post113822 I've applied ldrel to my gdb 7.6 binary, but it didn't help. After that, I've downloaded and patched gdb 6.8, but build process failed with message: make[2]: Entering directory `/home/max/gdb_build/bfd' Making info in doc make[3]: Entering directory `/home/max/gdb_build/bfd/doc' restore=: && backupdir=".am$$" && \ rm -rf $backupdir && mkdir $backupdir && \ if (makeinfo --split-size=5000000 --split-size=5000000 --version) >/dev/null 2>&1; then \ for f in bfd.info bfd.info-[0-9] bfd.info-[0-9][0-9] bfd.i[0-9] bfd.i[0-9][0-9]; do \ if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \ done; \ else :; fi && \ if makeinfo --split-size=5000000 --split-size=5000000 -I /home/max/gdb-6.8/bfd/doc \ -o bfd.info `test -f 'bfd.texinfo' || echo '/home/max/gdb-6.8/bfd/doc/'`bfd.texinfo; \ then \ rc=0; \ else \ rc=$?; \ $restore $backupdir/* `echo "./bfd.info" | sed 's|[^/]*$||'`; \ fi; \ rm -rf $backupdir; exit $rc /home/max/gdb-6.8/bfd/doc/bfd.texinfo:326: unknown command `colophon' /home/max/gdb-6.8/bfd/doc/bfd.texinfo:337: unknown command `cygnus' /home/max/gdb-6.8/bfd/doc/elf.texi:11: raising the section level of @subsubsection which is too low make[3]: *** [bfd.info] Error 1 make[3]: Leaving directory `/home/max/gdb_build/bfd/doc' Making info in po make[3]: Entering directory `/home/max/gdb_build/bfd/po' make[3]: Nothing to be done for `info'. make[3]: Leaving directory `/home/max/gdb_build/bfd/po' make[3]: Entering directory `/home/max/gdb_build/bfd' make[3]: Nothing to be done for `info-am'. make[3]: Leaving directory `/home/max/gdb_build/bfd' make[2]: *** [info-recursive] Error 1 make[2]: Leaving directory `/home/max/gdb_build/bfd' make[1]: *** [all-bfd] Error 2 make[1]: Leaving directory `/home/max/gdb_build' make: *** [all] Error 2 Adding "--disable-doc --without-doc" to configuration flags had no effect. Fri, 15 May 2015 08:13:58 GMT http://community.qnx.com/sf/go/post113822 Maxim Kuzmin(deleted) 2015-05-15T08:13:58Z http://community.qnx.com/sf/go/post113819 On 2015-05-14, 10:35 AM, "Ryan Mansfield" <community-noreply@qnx.com> wrote: >On 15-05-14 10:30 AM, Aleksandar Ristovski wrote: >> Not surprising. We do not support PPC in 6.6.0, and gdb 7.6 was not >>really >> meant to be used with 6.5.0. So I can't help you much more with that. >> >> However, if you do need gdb 7.6 for 6.5.0/ppc, I suggest you go through >> QNX support. >> >> Or you can go back to our gdb 6.8 and try it, it should work better >> (though, again, we never tested it self-hosted on ppc). Similar patch >> would be needed as for 7.6. > >One quick thing to try is that gdb self hosted on ppc might be running >out of stack (default of 512K), so he should try to use ldrel to set a >fairly larger stack size on the gdb binary. That is true. In your build directory: $ ldrel -L -S 4M gdb/gdb Thu, 14 May 2015 14:37:47 GMT http://community.qnx.com/sf/go/post113819 Aleksandar Ristovski(deleted) 2015-05-14T14:37:47Z http://community.qnx.com/sf/go/post113818 On 15-05-14 10:30 AM, Aleksandar Ristovski wrote: > Not surprising. We do not support PPC in 6.6.0, and gdb 7.6 was not really > meant to be used with 6.5.0. So I can't help you much more with that. > > However, if you do need gdb 7.6 for 6.5.0/ppc, I suggest you go through > QNX support. > > Or you can go back to our gdb 6.8 and try it, it should work better > (though, again, we never tested it self-hosted on ppc). Similar patch > would be needed as for 7.6. One quick thing to try is that gdb self hosted on ppc might be running out of stack (default of 512K), so he should try to use ldrel to set a fairly larger stack size on the gdb binary. Regards, Ryan Mansfield Thu, 14 May 2015 14:35:19 GMT http://community.qnx.com/sf/go/post113818 Ryan Mansfield(deleted) 2015-05-14T14:35:19Z http://community.qnx.com/sf/go/post113817 Not surprising. We do not support PPC in 6.6.0, and gdb 7.6 was not really meant to be used with 6.5.0. So I can't help you much more with that. However, if you do need gdb 7.6 for 6.5.0/ppc, I suggest you go through QNX support. Or you can go back to our gdb 6.8 and try it, it should work better (though, again, we never tested it self-hosted on ppc). Similar patch would be needed as for 7.6. --- Aleksandar Thu, 14 May 2015 14:30:17 GMT http://community.qnx.com/sf/go/post113817 Aleksandar Ristovski(deleted) 2015-05-14T14:30:17Z http://community.qnx.com/sf/go/post113816 Thank you, Aleks! I've successfully built gdb. Unfortunately, when I try to run some simple program inside the debugger, it returns me message "Memory fault". Thu, 14 May 2015 14:11:50 GMT http://community.qnx.com/sf/go/post113816 Maxim Kuzmin(deleted) 2015-05-14T14:11:50Z http://community.qnx.com/sf/go/post113815 We do not support ppc host. But if you really want to build it, apply the following patch: Index: gdb/config/powerpc/nto.mh =================================================================== --- gdb/config/powerpc/nto.mh (revision 0) +++ gdb/config/powerpc/nto.mh (working copy) @@ -0,0 +1,4 @@ +# Host: Intel 386 running QNX. + +NATDEPFILES= nto-procfs.o +NAT_FILE= config/nm-nto.h Index: gdb/configure.host =================================================================== --- gdb/configure.host (revision 897) +++ gdb/configure.host (working copy) @@ -134,6 +134,7 @@ powerpc-*-linux*) gdb_host=linux ;; powerpc-*-netbsd* | powerpc-*-knetbsd*-gnu) gdb_host=nbsd ;; powerpc-*-openbsd*) gdb_host=obsd ;; +powerpc*-*-nto*) gdb_host=nto ;; powerpc64-*-linux*) gdb_host=ppc64-linux # Support 'pseudo-native' debugging on the Cell BE Then: $ mkdir build $ cd build $ ../configure --host=powerpc-unknown-nto-qnx6.5.0 --target=powerpc-unknown-nto-qnx6.5.0 --without-expat --with-bugurl=no --with-python=no --program-prefix=ntoppc- --enable-gdbmi --disable-nls --disable-tui --disable-sim --without-sim --with-expat=no --disable-werror --verbose CFLAGS="-D__QNXTARGET__ -g0 -O -D_LARGEFILE64_SOURCE" CPPFLAGS="-I/tmp/stage650/qnx6/usr/include -I${QNX_TARGET}/usr/include" LDFLAGS="-L${QNX_TARGET}/ppc/lib -L${QNX_TARGET}/ppc/usr/lib" $ make You will need proper environment variables (QNX_HOST,QNX_TARGET,MAKEFLAGS,PATH). Good luck, Aleks Thu, 14 May 2015 13:21:20 GMT http://community.qnx.com/sf/go/post113815 Aleksandar Ristovski(deleted) 2015-05-14T13:21:20Z http://community.qnx.com/sf/go/post113814 Hello, I'm trying to build GDB for powerpc-unknown-nto-qnx6.5.0 using cross-compilation tools for linux-x86 host. Compilation fails with message: ntoppc-gcc -c -g -O2 -DHAVE_CONFIG_H -I. -I/home/max/gdb-7.6/qnx/gdb-7.6/intl plural.c plural.c:184: error: conflicting types for 'libintl_gettextparse' /home/max/gdb-7.6/qnx/gdb-7.6/intl/plural-exp.h:114: note: previous declaration of 'libintl_gettextparse' was here plural.c:1129: error: conflicting types for 'libintl_gettextparse' /home/max/gdb-7.6/qnx/gdb-7.6/intl/plural-exp.h:114: note: previous declaration of 'libintl_gettextparse' was here plural.c: In function 'libintl_gettextparse': plural.c:1298: error: too few arguments to function '__gettextlex' /home/max/gdb-7.6/qnx/gdb-7.6/intl/plural.y:178: error: 'arg' undeclared (first use in this function) /home/max/gdb-7.6/qnx/gdb-7.6/intl/plural.y:178: error: (Each undeclared identifier is reported only once /home/max/gdb-7.6/qnx/gdb-7.6/intl/plural.y:178: error: for each function it appears in.) make[2]: *** [plural.o] Error 1 make[2]: Leaving directory `/home/max/gdb-7.6/qnx/gdb_build/intl' make[1]: *** [all-intl] Error 2 make[1]: Leaving directory `/home/max/gdb-7.6/qnx/gdb_build' make: *** [all] Error 2 GDB 7.6, downloaded from f27svn.qnx.com/svn/repos/core-dev-tools Cross-compilation tools: GNU Make 3.81 ntoppc-gcc 4.4.2, target - powerpc-unknown-nto-qnx6.5.0 How to fix it? Thu, 14 May 2015 09:28:49 GMT http://community.qnx.com/sf/go/post113814 Maxim Kuzmin(deleted) 2015-05-14T09:28:49Z http://community.qnx.com/sf/go/post113438 Still have the same issue compiling with linker "-Wl,-LINK=c++ -Wl,-lstdc++" options. What's interesting is that if I change libgcc.a from 4.8.3 folder to libgcc.a from 4.4.2 folder it compiles fine. Is it ok to use 4.4.2 version of libgcc.a while using 4.8.3 compiler? Or it would come to undefined behavior? However it would be great 4.8.3 version of that lib! Sat, 28 Feb 2015 11:05:01 GMT http://community.qnx.com/sf/go/post113438 Alexey Smirnov(deleted) 2015-02-28T11:05:01Z http://community.qnx.com/sf/go/post113360 That builds on first try, and can even do shared library which I was having issues with previously. Frustrating to wade through all the options when simplicity is best. Thank you very much for the insight. Fri, 20 Feb 2015 16:19:34 GMT http://community.qnx.com/sf/go/post113360 Aaron Gawlik(deleted) 2015-02-20T16:19:34Z http://community.qnx.com/sf/go/post113358 On 15-02-20 10:54 AM, Aaron Gawlik wrote: > I am trying to cross-compile FFTW from build machine x86-64bit Ubuntu Linux to host machine armv7le QNX6.6 neutrino. When I build with neon option, the autoconf utility tests that the compiler accepts neon flag and fails because QCC uses the build compiler (x86 with no neon support), not the host compiler. Is there a flag setting I'm missing from below, or this an issue with autoconf tools? Other tests use the host (arm) compiler. Enabling threads has no effect on this error. > > Attached is the config.log. > > I've since commented out the ./configure lines associated with testing for -mfpu=neon and hardcode the flags in order to successfully compile with neon support. > > The configure setup is: > ARM_CPU_TYPE=cortex-a9 \ > CFLAGS="$CFLAGS $MAKEFLAGS -V4.7.3,gcc_ntoarmv7le -w9 -march=armv7-a -mfpu=neon -mfloat-abi=softfp" \ > LDFLAGS="$LDFLAGS -V4.7.3,gcc_ntoarmv7le" \ > NM=ntoarmv7-nm AR=ntoarmv7-ar RANLIB=ntoarmv7-ranlib \ > STRIP=ntoarmv7-strip CC=qcc LD=qcc \ > ./configure --host=armv7-nto \ > --prefix=$HOME/fftw_test --enable-neon --enable-single \ > --enable-threads It looks like CFLAGS aren't being passed down to the neon conftest to specify -Vgcc_ntoarmv7le, and it's just invoking qcc which defaults to x86. Have you tried using --host=arm-unknown-nto-qnx6.6.0eabi and using the gcc driver, instead of using qcc or and setting qcc options with CFLAGS? i.e ./configure --host=arm-unknown-nto-qnx6.6.0eabi --prefix=$HOME/fftw_test --enable-neon --enable-singl --enable-threads Regards, Ryan Mansfield Fri, 20 Feb 2015 16:00:40 GMT http://community.qnx.com/sf/go/post113358 Ryan Mansfield(deleted) 2015-02-20T16:00:40Z http://community.qnx.com/sf/go/post113356 I am trying to cross-compile FFTW from build machine x86-64bit Ubuntu Linux to host machine armv7le QNX6.6 neutrino. When I build with neon option, the autoconf utility tests that the compiler accepts neon flag and fails because QCC uses the build compiler (x86 with no neon support), not the host compiler. Is there a flag setting I'm missing from below, or this an issue with autoconf tools? Other tests use the host (arm) compiler. Enabling threads has no effect on this error. Attached is the config.log. I've since commented out the ./configure lines associated with testing for -mfpu=neon and hardcode the flags in order to successfully compile with neon support. The configure setup is: ARM_CPU_TYPE=cortex-a9 \ CFLAGS="$CFLAGS $MAKEFLAGS -V4.7.3,gcc_ntoarmv7le -w9 -march=armv7-a -mfpu=neon -mfloat-abi=softfp" \ LDFLAGS="$LDFLAGS -V4.7.3,gcc_ntoarmv7le" \ NM=ntoarmv7-nm AR=ntoarmv7-ar RANLIB=ntoarmv7-ranlib \ STRIP=ntoarmv7-strip CC=qcc LD=qcc \ ./configure --host=armv7-nto \ --prefix=$HOME/fftw_test --enable-neon --enable-single \ --enable-threads Thank you for any thoughts. Fri, 20 Feb 2015 15:54:35 GMT http://community.qnx.com/sf/go/post113356 Aaron Gawlik(deleted) 2015-02-20T15:54:35Z http://community.qnx.com/sf/go/post113269 It is enabled by default. If you don't see it - it probably cannot unwind stack On 15-02-03 02:40 AM, Желобанов Дмитрий Владимирович wrote: > > Hello > > How to enable printing backtrace in mudflap violations? > > I use SDK 6.5.0 > > Dmitry Zhelobanov. > Mon, 09 Feb 2015 14:26:44 GMT http://community.qnx.com/sf/go/post113269 Elena Laskavaia 2015-02-09T14:26:44Z http://community.qnx.com/sf/go/post113197 Hello How to enable printing backtrace in mudflap violations? I use SDK 6.5.0 Dmitry Zhelobanov. Tue, 03 Feb 2015 07:40:40 GMT http://community.qnx.com/sf/go/post113197 Dmitry Zhelobanov(deleted) 2015-02-03T07:40:40Z http://community.qnx.com/sf/go/post113109 Thank you - that was exactly what I was looking for! Best regards, Vincent Tue, 27 Jan 2015 21:58:57 GMT http://community.qnx.com/sf/go/post113109 Vincent Wan(deleted) 2015-01-27T21:58:57Z http://community.qnx.com/sf/go/post113086 Hi Vincent, You can try adding this to the end of your common.mk # Quiet the build output so we can see the warnings ifneq ($(V),1) MAKE = @$(MAKE_COMMAND) --no-print-directory RM_HOST := @$(RM_HOST) ifeq ($(V),0) CCPREF := @$(CCPREF) ASPREF := @$(ASPREF) LDPREF := @$(LDPREF) ARPREF := @$(ARPREF) 2>/dev/null UMPREF := @$(UMPREF) MKASMOFF_HOST := @$(MKASMOFF_HOST) else QUIET_ROOT := $(PROJECT_ROOT) #QUIET_ROOT := $(PRODUCT_ROOT) CCPREF_CMD := $(CCPREF) CCPREF = @echo "Compiling " $(<:$(QUIET_ROOT)/%=%) && $(CCPREF_CMD) ASPREF_CMD := $(ASPREF) ASPREF = @echo "Assembling" $(<:$(QUIET_ROOT)/%=%) && $(ASPREF_CMD) LDPREF_CMD := $(LDPREF) LDPREF = @echo "Linking " $(@:$(QUIET_ROOT)/%=%) && $(LDPREF_CMD) ARPREF_CMD := $(ARPREF) 2>/dev/null ARPREF = @echo "Archiving " $(@:$(QUIET_ROOT)/%=%) && $(ARPREF_CMD) UMPREF_CMD := $(UMPREF) UMPREF = @echo "Usemsg " $(@:$(QUIET_ROOT)/%=%) && $(UMPREF_CMD) MKASMOFF_CMD := $(MKASMOFF_HOST) MKASMOFF_HOST = @echo "Generating" $(CURDIR:$(QUIET_ROOT)/%=%)/$@ && $(MKASMOFF_CMD) endif endif On 2015-01-26 8:05 PM, Vincent Wan wrote: > I have noticed that when building a project, all qcc invocation command lines are printed out on the console, e.g. > > C:/qnx660/host/win32/x86/usr/bin/qcc -Vgcc_ntoarmv7 -c -Os -Wc,-Wall -DF3S_VER=3 -DMTD_VER=2 -DNDEBUG -I. -IC:/Users/me/ide-5.0-workspace/bsp-TI-DRA72x-evm-SDP6.6_M2/src/hardware/flash/boards/ti_qspi/arm/le.v7 -IC:/Users/me/ide-5.0-workspace/bsp-TI-DRA72x-evm-SDP6.6_M2/src/hardware/flash/boards/ti_qspi/arm -IC:/Users/me/ide-5.0-workspace/bsp-TI-DRA72x-evm-SDP6.6_M2/src/hardware/flash/boards/ti_qspi -IC:/Users/me/ide-5.0-workspace/bsp-TI-DRA72x-evm-SDP6.6_M2/src/hardware/flash/boards -IC:/Users/me/ide-5.0-workspace/bsp-TI-DRA72x-evm-SDP6.6_M2/src/hardware/flash/mtd-flash/public -IC:/Users/me/ide-5.0-workspace/bsp-TI-DRA72x-evm-SDP6.6_M2/src/hardware/flash -IC:/Users/me/ide-5.0-workspace/bsp-TI-DRA72x-evm-SDP6.6_M2/src/hardware/flash/boards/../../../../install/usr/include -IC:/qnx660/target/qnx6/usr/include -EL -DVARIANT_le -DVARIANT_v7 -DVARIANT_ti_qspi -DBUILDENV_qss C:/Users/me/ide-5.0-workspace/bsp-TI-DRA72x-evm-SDP6.6_M2/src/hardware/flash/boards/ti_qspi/f3s_qspi_erase.c > > Is there a way to reduce verbosity of the build process to hide these lines and other similar ones? This becomes excessively verbose when there is a long list of include paths. > > Thank you. > > > > > _______________________________________________ > > General > http://community.qnx.com/sf/go/post113085 > To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com Tue, 27 Jan 2015 01:08:07 GMT http://community.qnx.com/sf/go/post113086 Colin Burgess(deleted) 2015-01-27T01:08:07Z http://community.qnx.com/sf/go/post113085 I have noticed that when building a project, all qcc invocation command lines are printed out on the console, e.g. C:/qnx660/host/win32/x86/usr/bin/qcc -Vgcc_ntoarmv7 -c -Os -Wc,-Wall -DF3S_VER=3 -DMTD_VER=2 -DNDEBUG -I. -IC:/Users/me/ide-5.0-workspace/bsp-TI-DRA72x-evm-SDP6.6_M2/src/hardware/flash/boards/ti_qspi/arm/le.v7 -IC:/Users/me/ide-5.0-workspace/bsp-TI-DRA72x-evm-SDP6.6_M2/src/hardware/flash/boards/ti_qspi/arm -IC:/Users/me/ide-5.0-workspace/bsp-TI-DRA72x-evm-SDP6.6_M2/src/hardware/flash/boards/ti_qspi -IC:/Users/me/ide-5.0-workspace/bsp-TI-DRA72x-evm-SDP6.6_M2/src/hardware/flash/boards -IC:/Users/me/ide-5.0-workspace/bsp-TI-DRA72x-evm-SDP6.6_M2/src/hardware/flash/mtd-flash/public -IC:/Users/me/ide-5.0-workspace/bsp-TI-DRA72x-evm-SDP6.6_M2/src/hardware/flash -IC:/Users/me/ide-5.0-workspace/bsp-TI-DRA72x-evm-SDP6.6_M2/src/hardware/flash/boards/../../../../install/usr/include -IC:/qnx660/target/qnx6/usr/include -EL -DVARIANT_le -DVARIANT_v7 -DVARIANT_ti_qspi -DBUILDENV_qss C:/Users/me/ide-5.0-workspace/bsp-TI-DRA72x-evm-SDP6.6_M2/src/hardware/flash/boards/ti_qspi/f3s_qspi_erase.c Is there a way to reduce verbosity of the build process to hide these lines and other similar ones? This becomes excessively verbose when there is a long list of include paths. Thank you. Tue, 27 Jan 2015 01:05:08 GMT http://community.qnx.com/sf/go/post113085 Vincent Wan(deleted) 2015-01-27T01:05:08Z http://community.qnx.com/sf/go/post112776 Just open the path and read() on the fd. On Mon, Dec 22, 2014 at 06:18:19PM +0530, Akshat Gill wrote: > Hello, > I am having trouble understating the nature of realpath() on QNX. > On Linux realpath("/proc/self/exe", buf) returns the name of the executable > > real_path (name of the executable) > >/home/abc/real_path > while on QNX > realpath("/proc/self/exefile",buf) returns > /proc/self/exefile . > I have attached the sample program for the same. In the program change /exe to > exefile on QNX. > > Regards > -Akshat > > /* > * Read the contents of the named symbolic links > */ > #include <limits.h> > #include <stdio.h> > #include <stdlib.h> > #include <unistd.h> > > > int main( int argc, char** argv ) > { > char *buf = NULL; > printf("## The value ::%s\n",realpath("/proc/self/exe", buf )); > > return( 0 ); > } Wed, 24 Dec 2014 00:51:22 GMT http://community.qnx.com/sf/go/post112776 Sean Boudreau(deleted) 2014-12-24T00:51:22Z http://community.qnx.com/sf/go/post112759 Hello, I am having trouble understating the nature of realpath() on QNX. On Linux realpath("/proc/self/exe", buf) returns the name of the executable > real_path (name of the executable) >/home/abc/real_path while on QNX realpath("/proc/self/exefile",buf) returns /proc/self/exefile . I have attached the sample program for the same. In the program change /exe to exefile on QNX. Regards -Akshat Mon, 22 Dec 2014 12:48:42 GMT http://community.qnx.com/sf/go/post112759 Akshat Gill(deleted) 2014-12-22T12:48:42Z http://community.qnx.com/sf/go/post112756 Hello, I am trying to run a sample program which uses readlink("/proc/self/exefile",buf.PATH_MAX). It returns -1. I am using QNX 6.6.0 32-bit. Doing ls to /proc/self/exefile displays:- -rw------- 1 root 0 14 Mar 09 06:32 /proc/self/exefile I tried changing the permission using chmod. Using the command :- > chmod u+x /proc/self/exefile gives result :- chmod: changing permission of /proc/self/exefile : No such file or directory Please assist. I have attached the sample program. Regards -Akshat Mon, 22 Dec 2014 11:49:19 GMT http://community.qnx.com/sf/go/post112756 Akshat Gill(deleted) 2014-12-22T11:49:19Z http://community.qnx.com/sf/go/post112347 Hi QNX folks, Using the std=c++11, QNX 6.6 QCC threw a compile error when I included boost/shared_ptr. #include <boost/shared_ptr.hpp> In file included from /home/test/qnx/ThirdParty/boost_1_55_0/boost/smart_ptr/detail/spinlock_sync.hpp:18:0, from /home/test/qnx/ThirdParty/boost_1_55_0/boost/smart_ptr/detail/spinlock.hpp:41, from /home/test/qnx/ThirdParty/boost_1_55_0/boost/smart_ptr/detail/spinlock_pool.hpp:25, from /home/test/qnx/ThirdParty/boost_1_55_0/boost/smart_ptr/shared_ptr.hpp:38, from /home/test/qnx/ThirdParty/boost_1_55_0/boost/shared_ptr.hpp:17, from /home/test/qnx/TestProgram/math/math.cpp:5: /home/test/qnx/ThirdParty/boost_1_55_0/boost/smart_ptr/detail/yield_k.hpp: In function 'void boost::detail::yield(unsigned int)': /home/test/qnx/ThirdParty/boost_1_55_0/boost/smart_ptr/detail/yield_k.hpp:122:29: error: 'nanosleep' was not declared in this scope cc: /opt/qnx660/host/linux/x86/usr/lib/gcc/arm-unknown-nto-qnx6.6.0eabi/4.7.3/cc1plus error 1 make[2]: *** [TestProgram/math/CMakeFiles/testapp.math.dir/math.cpp.o] Error 1 make[1]: *** [TestProgram/math/CMakeFiles/testapp.math.dir/all] Error 2 Is this a boost issue or the QNX 6.6 toolchain issue? Best regards, Anton Fri, 14 Nov 2014 18:03:09 GMT http://community.qnx.com/sf/go/post112347 Anton Indrawan(deleted) 2014-11-14T18:03:09Z http://community.qnx.com/sf/go/post112288 See also: --> http://www.qnx.com --> Log on to myQNX (top right) --> Click on "Download QNX 6.6.0" (near center of page) --> Download "QNX® Software Development Platform 6.6 Header Files Patch [Patch ID 3851] " Thu, 06 Nov 2014 14:35:35 GMT http://community.qnx.com/sf/go/post112288 Peter Luscher(deleted) 2014-11-06T14:35:35Z http://community.qnx.com/sf/go/post112066 Using gcc 4.8.3 objdump-2.24 (or any other version I could try ) when used with -S and -d, to look at assembly code is giving an output that doesn't make any sense. Example, output of objdump: 0: 55 push %ebp 131: 89 e5 57 56 53 83 e4 movl $0xe,0x4(%esp) 138: f0 139: 81 ec 40 02 00 00 e8 movl $0x0,(%esp) 140: fc ff fmulp %st,%st(1) 142: ff ff 85 c0 fstpl 0x18(%esp) 146: 74 0c c7 04 24 call 147 <main+0x17> 14b: 00 00 00 00 fldl 0x18(%esp) 14f: e8 fc ff mov %eax,(%esp) 152: ff ff 0f 31 fstpl 0x4(%esp) And same thing but using -S with gcc pushl %ebp .cfi_def_cfa_offset 8 .cfi_offset 5, -8 movl %esp, %ebp .cfi_def_cfa_register 5 pushl %edi pushl %esi pushl %ebx andl $-16, %esp subl $576, %esp .cfi_offset 7, -12 .cfi_offset 6, -16 .cfi_offset 3, -20 .LEHB0: call _Z21FindCpuSpeedForPClockv testl %eax, %eax je .L2 movl $.LC0, (%esp) call puts Sat, 18 Oct 2014 00:05:50 GMT http://community.qnx.com/sf/go/post112066 Mario Charest 2014-10-18T00:05:50Z http://community.qnx.com/sf/go/post112065 Ok, saw the problem. Repeated it to make sure it continued happening, then set LOGONSERVER=, and it is now blazing fast again! Good one, checking a logon server when spawning a process. Fri, 17 Oct 2014 19:45:52 GMT http://community.qnx.com/sf/go/post112065 Kevin Schaffer(deleted) 2014-10-17T19:45:52Z http://community.qnx.com/sf/go/post112045 Still here, it just hasn't manifested as a problem the past few days, so can't test it. Wed, 15 Oct 2014 13:57:27 GMT http://community.qnx.com/sf/go/post112045 Kevin Schaffer(deleted) 2014-10-15T13:57:27Z http://community.qnx.com/sf/go/post112033 > It's probably because isnan is a macro. Try with (boost::math::isnan)(5) > instead. It's explained in the Boost documentation: > http://www.boost.org/doc/libs/1_55_0/libs/math/doc/html/math_toolkit/fpclass. > html Hi Niklas, My bad, I didn't read the boost doc first. Thanks for the information, it compiles fine now. Best regards, Anton Sat, 11 Oct 2014 18:50:18 GMT http://community.qnx.com/sf/go/post112033 Anton Indrawan(deleted) 2014-10-11T18:50:18Z http://community.qnx.com/sf/go/post112024 You can try setting the LOGONSERVER variables to that of your PC within the éclos env. Have had some level of success with this. ________________________________________ From: Kevin Schaffer [community-noreply@qnx.com] Sent: Friday, October 10, 2014 10:16 AM To: general-toolchain Subject: Re: RE: Make builds excruciatingly slow -- sometimes Oh. My. God. I think you're right. Looking at network activity with the process monitor, it does indeed seem to be doing something on the network. Our network is wireless and could be clogged at certain times of the day. It's morning and speedy now. Next time massive slowdown occurs, I will check it again. _______________________________________________ General http://community.qnx.com/sf/go/post112022 To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com Fri, 10 Oct 2014 14:35:29 GMT http://community.qnx.com/sf/go/post112024 Mario Charest 2014-10-10T14:35:29Z http://community.qnx.com/sf/go/post112022 Oh. My. God. I think you're right. Looking at network activity with the process monitor, it does indeed seem to be doing something on the network. Our network is wireless and could be clogged at certain times of the day. It's morning and speedy now. Next time massive slowdown occurs, I will check it again. Fri, 10 Oct 2014 14:16:58 GMT http://community.qnx.com/sf/go/post112022 Kevin Schaffer(deleted) 2014-10-10T14:16:58Z http://community.qnx.com/sf/go/post112015 If you are under a Windows Domain, the shell (from MSYS I believe) will, every time it starts, contact the logon server, not nice. It can get messy, if you logon the domain then disconnect from the network. We have moved all our development under Linux which we run in a virtual machine under Windows ( we aren`t ready yet to use Linux natively on our development PC). Our build time has gone down by an average of 25%, yep 25% faster on the same machine but in a virtual machine. Only down side we have found so far is the Index seems to be slower, don`t know why. There some issue with VMWare loosing cut and paste functionality between the guess and host, but overall the experience has been more then positive. We can deploy a setup in minutes, move it from PC to PC very simply if the hardware is being upgrade. I`m currently on the road and have move my VM from by main desktop machine to a laptop, make my live much simpler. We can deploy upgrades by telling everyone to get a new image. Everyone should use Momentic under Linux in my opinion. Virtual machine or not. Even better yet, get Luna, and install the QNX stuff from a REPOS file. The CDT is much better. People at the office enjoy the dark theme very much ;-) With QNX dropping features and product lines left and right, Momentics for Windows is one I wouldn`t mind they dropped ;-) Back to work now. -----Message d'origine----- De : Kevin Schaffer [mailto:community-noreply@qnx.com] Envoyé : Thursday, October 09, 2014 5:25 PM À : general-toolchain Objet : Make builds excruciatingly slow -- sometimes All our machines have this problem, though some are different models. Mine is Windows 7, 32gb, 8-core. We start a make build of a project with dozens of folders and thousands of files. Sometimes it is lightning fast. Other times it is very slow, like 2-3s per processed line. Turning on -d shows the bottleneck seems to be right after the CreateProcess(blah blah)/Live Child lines. Then 2-3s pause Then it does what the process should do (that line in a makefile) Then Reaping winning child... instant repeat. This happens even on echo hello world type lines that do not even reference a variable (so there could be no permutational explosion of references as variables are resolvled.) That makes no sense anyway because it sometimes is lightning fast and nothing else has changed. The CPU is not busy at all during this (no process is above 1%, and none of the make/compiler things are even that. A locked octo'th processor would be a process at 13%-ish.) I've killed and restarted the command window, no change. Sometimes it just "goes away" and it's fast again. Any ideas? _______________________________________________ General http://community.qnx.com/sf/go/post112014 To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com Thu, 09 Oct 2014 22:03:50 GMT http://community.qnx.com/sf/go/post112015 Mario Charest 2014-10-09T22:03:50Z http://community.qnx.com/sf/go/post112014 All our machines have this problem, though some are different models. Mine is Windows 7, 32gb, 8-core. We start a make build of a project with dozens of folders and thousands of files. Sometimes it is lightning fast. Other times it is very slow, like 2-3s per processed line. Turning on -d shows the bottleneck seems to be right after the CreateProcess(blah blah)/Live Child lines. Then 2-3s pause Then it does what the process should do (that line in a makefile) Then Reaping winning child... instant repeat. This happens even on echo hello world type lines that do not even reference a variable (so there could be no permutational explosion of references as variables are resolvled.) That makes no sense anyway because it sometimes is lightning fast and nothing else has changed. The CPU is not busy at all during this (no process is above 1%, and none of the make/compiler things are even that. A locked octo'th processor would be a process at 13%-ish.) I've killed and restarted the command window, no change. Sometimes it just "goes away" and it's fast again. Any ideas? Thu, 09 Oct 2014 21:24:50 GMT http://community.qnx.com/sf/go/post112014 Kevin Schaffer(deleted) 2014-10-09T21:24:50Z http://community.qnx.com/sf/go/post112000 It's probably because isnan is a macro. Try with (boost::math::isnan)(5) instead. It's explained in the Boost documentation: http://www.boost.org/doc/libs/1_55_0/libs/math/doc/html/math_toolkit/fpclass.html Thu, 09 Oct 2014 10:58:38 GMT http://community.qnx.com/sf/go/post112000 Niklas Angare 2014-10-09T10:58:38Z http://community.qnx.com/sf/go/post111973 Here is the build file I have been using. Thanks Kevin Sat, 04 Oct 2014 22:18:40 GMT http://community.qnx.com/sf/go/post111973 Kevin Stallard 2014-10-04T22:18:40Z http://community.qnx.com/sf/go/post111972 > Okay, after several days of additional investigation and such here is where I > am : > > 1. I eliminated the possibility that it was the medium I was using to boot > the x86 box. I was using a USB stick formatted using mkqnx6fsimg in > combination with the new diskimage utility. If found a SATA to USB adapter, > conencted a laptop harddisk to my Ubuntu host, and QNX 6.5 VM. I used these > hosts to format and load the harddisk with the images. I both formatted the > HD using the mkqnx6fs utility on QNX 6.5 and just copied the resulting image > from disk image. Results were the same. > > 2. I then disconnected the harddisk from the SATA to USB adapter and > connected the harddisk directly to the x86 box to boot it. > > The problem remains, there are always a handful of binaries that are corrupted > > QNX 6.6.0 > 6fa000 2c75 8049090 --- proc/boot/sloginfo=/opt/qnx660/target/qnx6/ > x86/bin/sloginfo > 6fd000 a94a 804a024 --- proc/boot/devb-umass=/opt/qnx660/target/qnx6 > /x86/sbin/devb-umass > 708000 2136d 804af94 --- proc/boot/io-usb=/opt/qnx660/target/qnx6/x86 > /sbin/io-usb > One other thing, any binaries after these locations (as well as before) are fine. > > Thanks > Kevin Sat, 04 Oct 2014 22:13:47 GMT http://community.qnx.com/sf/go/post111972 Kevin Stallard 2014-10-04T22:13:47Z http://community.qnx.com/sf/go/post111970 Okay, after several days of additional investigation and such here is where I am : 1. I eliminated the possibility that it was the medium I was using to boot the x86 box. I was using a USB stick formatted using mkqnx6fsimg in combination with the new diskimage utility. If found a SATA to USB adapter, conencted a laptop harddisk to my Ubuntu host, and QNX 6.5 VM. I used these hosts to format and load the harddisk with the images. I both formatted the HD using the mkqnx6fs utility on QNX 6.5 and just copied the resulting image from disk image. Results were the same. 2. I then disconnected the harddisk from the SATA to USB adapter and connected the harddisk directly to the x86 box to boot it. The problem remains, there are always a handful of binaries that are corrupted. 3. I then started to build using QNX 6.5 utilities. While the corrupted files were different, the problem remained. After a bunch of trial and error I found that the corrupt files always reside in the range of 6f9000 and 710000. For example, the following files are corrupted: QNX 6.5.0 6f9000 1d0f 8048668 --- proc/boot/umount=/opt/qnx650/target/qnx6/x86/bin/umount 6fb000 fc12 80492c8 --- proc/boot/pci-bios=/opt/qnx650/target/qnx6/x86/sbin/pci-bios 70b000 657d1 8048a18 --- proc/boot/pci=/opt/qnx650/target/qnx6/x86/usr/sbin/pci QNX 6.6.0 6fa000 2c75 8049090 --- proc/boot/sloginfo=/opt/qnx660/target/qnx6/x86/bin/sloginfo 6fd000 a94a 804a024 --- proc/boot/devb-umass=/opt/qnx660/target/qnx6/x86/sbin/devb-umass 708000 2136d 804af94 --- proc/boot/io-usb=/opt/qnx660/target/qnx6/x86/sbin/io-usb 4. This range of corruption is the same no matter what x86 box I boot. I've tried several, all different motherboards and ram combinations, the problem is the same. Any ideas on what I can do to fix this? Thanks Kevin Sat, 04 Oct 2014 22:01:20 GMT http://community.qnx.com/sf/go/post111970 Kevin Stallard 2014-10-04T22:01:20Z http://community.qnx.com/sf/go/post111965 Followup: I checked my installation of QNX660 SDP, the binaries are fine. If I change the order they are included in the build script, they work, and the ones that took their place don't. I know this should tell me what is going on, but the only thing I can think of is that the image file system is being loaded into RAM, the checksum taken, it passes and then it is copied somewhere else where pot hole in memory exists thus the apparent dependency on location.....wait...isn't that a real-estate thing? --Kevin Fri, 03 Oct 2014 07:34:57 GMT http://community.qnx.com/sf/go/post111965 Kevin Stallard 2014-10-03T07:34:57Z http://community.qnx.com/sf/go/post111964 In my build file, under [data=copy], I include io-hid. When it tries to run I get: /proc/boot/io-hid[1]: syntax error: '|' unexpected That looked a lot like the output of a script interpreter, so I included ldd with the image and ran ldd io-hid and subsequently got the following message: ldd: /proc/boot/io-hid: corrupt ELF file One file before io-hid appears to be corrupted and one file after io-hid is also corrupted. But the rest seem to be fine. I've attached the build file for you reading pleasure. This is being built on an x86 system with 8Gb of RAM. QNX 6.6 Very, very weird... Fri, 03 Oct 2014 03:42:32 GMT http://community.qnx.com/sf/go/post111964 Kevin Stallard 2014-10-03T03:42:32Z http://community.qnx.com/sf/go/post111957 Thanks Bob. We have upgraded libz to libz.so.1.2.3.4 and it seems to get rid of the message. Before the upgrade, the resulting binaries seemed to work correctly, so it seems this warning is benign. Thu, 02 Oct 2014 16:44:16 GMT http://community.qnx.com/sf/go/post111957 Vincent Wan(deleted) 2014-10-02T16:44:16Z http://community.qnx.com/sf/go/post111950 Interesting, thanks for the feedback on this. I just changed the way I do this to sectors and it worked without modification. I know it was one of the things I tried, not sure why it didn't work. So, I guess I concur, we don't need the num_blocks functionality :) Thanks Thomas, Kevin On Oct 1, 2014, at 12:39 AM, Thomas Haupt <community-noreply@qnx.com> wrote: > Mea culpa, I think. > > You wrote: >> 1. The file size wasn't matching the C*H*S*sector_size, even though I >> was using the right parameters in the blksize and num_blocks attributes. >> An additional 15872 bytes were being added to the resulting image. I >> modified the attributes so that the block size was reduced that amount >> and ti worked (reduced it by 32 blocks of blksize=512). > > When I originally implemented mkqnx6fsimg, I didn't realize that an explicit "num_blocks" attribute would, at best, be mostly useless and usually and up badly confusing or even irritating the user - which is definitely nothing a good tool should do. The problem with num_blocks is that, as you have indirectly noticed, the net size of a QNX6 file system is greater than just the combined sum of its (data) blocks. It also contains some metadata (a "boot" and two "super" blocks) that will alone take up ~16k . Upon realizing how intricate it actually was to create an image of defined size using this attribute, I first tried to account for this by better documenting the relation between block- and sector count, but by now I've come to believe it'll probably be best to completely remove the "num_blocks" attribute to avoid any further confusion. > > Instead, one should _always_ use the "num_sectors" attribute to define the file-system size. The relation between sector count and actually usable data space in the file system isn't much worse than for the block count, but num_sectors at allows you to tell exactly how many sectors the resulting image will take up. The tool will automatically account and adjust for "odd" sector counts, so you don't have to worry about sector counts that aren't exact multiples of the block size. Instead, just look at your target media's/partition's sector count and put that into the build file. > > Best regards, and my sincere apologies for wasting your time with this useless feature: > Thomas > > > > _______________________________________________ > > General > http://community.qnx.com/sf/go/post111939 > To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com Wed, 01 Oct 2014 19:45:43 GMT http://community.qnx.com/sf/go/post111950 Kevin Stallard 2014-10-01T19:45:43Z http://community.qnx.com/sf/go/post111939 Mea culpa, I think. You wrote: >1. The file size wasn't matching the C*H*S*sector_size, even though I >was using the right parameters in the blksize and num_blocks attributes. >An additional 15872 bytes were being added to the resulting image. I >modified the attributes so that the block size was reduced that amount >and ti worked (reduced it by 32 blocks of blksize=512). When I originally implemented mkqnx6fsimg, I didn't realize that an explicit "num_blocks" attribute would, at best, be mostly useless and usually and up badly confusing or even irritating the user - which is definitely nothing a good tool should do. The problem with num_blocks is that, as you have indirectly noticed, the net size of a QNX6 file system is greater than just the combined sum of its (data) blocks. It also contains some metadata (a "boot" and two "super" blocks) that will alone take up ~16k . Upon realizing how intricate it actually was to create an image of defined size using this attribute, I first tried to account for this by better documenting the relation between block- and sector count, but by now I've come to believe it'll probably be best to completely remove the "num_blocks" attribute to avoid any further confusion. Instead, one should _always_ use the "num_sectors" attribute to define the file-system size. The relation between sector count and actually usable data space in the file system isn't much worse than for the block count, but num_sectors at allows you to tell exactly how many sectors the resulting image will take up. The tool will automatically account and adjust for "odd" sector counts, so you don't have to worry about sector counts that aren't exact multiples of the block size. Instead, just look at your target media's/partition's sector count and put that into the build file. Best regards, and my sincere apologies for wasting your time with this useless feature: Thomas Wed, 01 Oct 2014 06:39:54 GMT http://community.qnx.com/sf/go/post111939 Thomas Haupt 2014-10-01T06:39:54Z http://community.qnx.com/sf/go/post111928 I have a solution: 1. The file size wasn't matching the C*H*S*sector_size, even though I was using the right parameters in the blksize and num_blocks attributes. An additional 15872 bytes were being added to the resulting image. I modified the attributes so that the block size was reduced that amount and ti worked (reduced it by 32 blocks of blksize=512). 2. Must not use devb-umass blk qnx6 sync=optional but rather use mount -t qnx6 -o sync=optional <device> <mount> I now have an image created in Linux mounting to a qnx6.5 vm! Tue, 30 Sep 2014 12:06:42 GMT http://community.qnx.com/sf/go/post111928 Kevin Stallard 2014-09-30T12:06:42Z http://community.qnx.com/sf/go/post111925 Well, shoot, this is addressed to all, not just the talented Northern CA FAE..... > Hi Hasnat, > > I'm having trouble getting this utility to create a qnx file system that I can > mount. I understand that the build script for the utility must specify the > exact size of the partition it is going to be copied to, but as much as I've > tried I get a corrupted file system error every time I try to nount it. > > The steps I take are: > > 1. Partition a USB drive use fdisk under qnx > 2. Use the attached build script and run mkqnx6fsimg (in linux). > 3. DD the resulting file to my USB stick. > 4. In Qnx start devb-umass and mount -t qnx6 /dev/hd1t179 /fs/qnx6 > 5. ls /fs/qnx6 > > Result: Corupted file system detected. > > The USB Stick partition specifics are: > Cyls: 975 > Heads: 255 > Sec/Trac: 63 > > Partition starts on Cyl 1 and ends on Cyl 200 > > Thanks > Kevin Tue, 30 Sep 2014 04:00:53 GMT http://community.qnx.com/sf/go/post111925 Kevin Stallard 2014-09-30T04:00:53Z http://community.qnx.com/sf/go/post111924 Hi Hasnat, I'm having trouble getting this utility to create a qnx file system that I can mount. I understand that the build script for the utility must specify the exact size of the partition it is going to be copied to, but as much as I've tried I get a corrupted file system error every time I try to nount it. The steps I take are: 1. Partition a USB drive use fdisk under qnx 2. Use the attached build script and run mkqnx6fsimg (in linux). 3. DD the resulting file to my USB stick. 4. In Qnx start devb-umass and mount -t qnx6 /dev/hd1t179 /fs/qnx6 5. ls /fs/qnx6 Result: Corupted file system detected. The USB Stick partition specifics are: Cyls: 975 Heads: 255 Sec/Trac: 63 Partition starts on Cyl 1 and ends on Cyl 200 Thanks Kevin Tue, 30 Sep 2014 03:54:54 GMT http://community.qnx.com/sf/go/post111924 Kevin Stallard 2014-09-30T03:54:54Z http://community.qnx.com/sf/go/post111923 In examining the output of the mkqnx6fsimg, it appears that the utility is including the boot loader. Also if you map /.boot/some_image = some_image.img it doesn't complain. However, I am having trouble getting the file system to mount... Kevin Tue, 30 Sep 2014 03:40:55 GMT http://community.qnx.com/sf/go/post111923 Kevin Stallard 2014-09-30T03:40:55Z http://community.qnx.com/sf/go/post111902 Dinkum is not supply with 4.8.3, you must use gnu ( libstdc++.so ), sorry should have mentioned that. QNX Support offered to build me a version of the Dinkum libs, but I declined, switching to libstdc++ turned out to be positive for us. Had I known I would have switch to it earlier. -----Message d'origine----- De : Anton Indrawan [mailto:community-noreply@qnx.com] Envoyé : 26 septembre 2014 16:13 À : general-toolchain Objet : Re: RE: QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target Hi Mario, Thanks for your information. However, the libcpp.so under the GCC 4.8.3 seems to intentionally be pointing to a non-existent file. I am not sure if I can take it from the standard QNX 6.5 toolchain. I will give it a try later. Best regards, Anton _______________________________________________ General http://community.qnx.com/sf/go/post111901 To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com Fri, 26 Sep 2014 21:05:54 GMT http://community.qnx.com/sf/go/post111902 Mario Charest 2014-09-26T21:05:54Z http://community.qnx.com/sf/go/post111901 Hi Mario, Thanks for your information. However, the libcpp.so under the GCC 4.8.3 seems to intentionally be pointing to a non-existent file. I am not sure if I can take it from the standard QNX 6.5 toolchain. I will give it a try later. Best regards, Anton Fri, 26 Sep 2014 20:13:07 GMT http://community.qnx.com/sf/go/post111901 Anton Indrawan(deleted) 2014-09-26T20:13:07Z http://community.qnx.com/sf/go/post111882 Yes that is exactly what I`m doing. There is release of 4.8.3 for 650 and another 4.8.3 for 6.6.0. Thu, 25 Sep 2014 17:04:34 GMT http://community.qnx.com/sf/go/post111882 Mario Charest 2014-09-25T17:04:34Z http://community.qnx.com/sf/go/post111881 Hi Mario, Will this work on a standard QNX 6.5 target? I don't make the target image, so I don't really know if this would work. Best regards, Anton Thu, 25 Sep 2014 16:52:38 GMT http://community.qnx.com/sf/go/post111881 Anton Indrawan(deleted) 2014-09-25T16:52:38Z http://community.qnx.com/sf/go/post111880 Hi Ryan, This works well. Thank you. Best regards, Anton Thu, 25 Sep 2014 16:50:34 GMT http://community.qnx.com/sf/go/post111880 Anton Indrawan(deleted) 2014-09-25T16:50:34Z http://community.qnx.com/sf/go/post111858 On 14-09-22 05:08 PM, Anton Indrawan wrote: > @Ryan: > Anton: I tried the following command > QCC -Vgcc_ntoarmv7le -Bstatic -lcpp -Bdynamic helloworld.cpp > > but the resulting binary still contains a dependency to the shared libcpp library. > > Tag Type Name/Value > 0x00000001 (NEEDED) Shared library: [libcpp.so.5] > 0x00000001 (NEEDED) Shared library: [libc.so.3] > > I am not sure how I can just statically link to the static libcpp library. > Could you also reproduce it? When you link C++, qcc automatically links against libcpp. You should specify -nostdlib++. e.g. $ qcc math.cpp -Bstatic -lcpp -lcxa -lm -Bdynamic -nostdlib++ $ ntox86-readelf -d a.out | grep NEEDED 0x00000001 (NEEDED) Shared library: [libc.so.3] One problem you might hit trying to get 6.6.0 binaries to run on 6.5.0, is that everything is built is with -fstack-protector, which relies on support in libc. This wasn't in the 6.5.0 libc but IIRC, 6.5.0SP1 added. Regards, Ryan Mansfield Wed, 24 Sep 2014 01:27:15 GMT http://community.qnx.com/sf/go/post111858 Ryan Mansfield(deleted) 2014-09-24T01:27:15Z http://community.qnx.com/sf/go/post111831 -----Message d'origine----- De : Anton Indrawan [mailto:community-noreply@qnx.com] Envoyé : 22 septembre 2014 17:09 À : general-toolchain Objet : Re: QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target >@Mario: If I could use the QNX 6.6 toolchain for building binaries (at least with statically linked libcpp library) >which can be deployed on a QNX 6.5 target, it would save me lots of linking time. In my case, linking my big app > using the QNX 6.5's ld takes ~15-20 minutes or even more, while using QNX 6.6's ld is much faster. > I am not sure how fast it is, but it won't take longer than 5 minutes. Can't you just use 4.8.3 and the bin utils for 6.5.0 ? Thanks, Anton _______________________________________________ General http://community.qnx.com/sf/go/post111830 To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com Mon, 22 Sep 2014 21:53:46 GMT http://community.qnx.com/sf/go/post111831 Mario Charest 2014-09-22T21:53:46Z http://community.qnx.com/sf/go/post111830 > On 14-09-22 03:54 AM, Anton Indrawan wrote: > > Hi guys, > > > > I understood that binaries produced by QNX 6.5 toolchain will work on QNX 6. > 6 targets. I was wondering whether the other way around would work. So, I > created a hello world application which basically does a printf, compiled with > QNX 6.6's QCC, deployed on a QNX 6.5 target and that worked. However, when I > was using std::pow, it threw a memory fault. > > Running newer binaries on older versions of the OS might work, but it's > not guaranteed to work so it's an unsupported use case. > Anton: Thanks for your reply. I will take that input into account. > > Note: I statically linked the program against libcpp and libm using the - > Bstatic option. Can somebody confirm that this is the right way to statically > link to the static libcpp library. > > Yes, but leaving it without a -Bdynamic, means the -lc that the compiler > drivers automatically link in will be statically linked as well. If you > want to create a full static binary, then you should link with -static. > If you still want dynamically linked program, you need to link against > libc.so, in which case you should to do, -Bstatic -lcpp -Bdynamic > > Regards, > > Ryan Mansfield > @Ryan: Anton: I tried the following command QCC -Vgcc_ntoarmv7le -Bstatic -lcpp -Bdynamic helloworld.cpp but the resulting binary still contains a dependency to the shared libcpp library. Tag Type Name/Value 0x00000001 (NEEDED) Shared library: [libcpp.so.5] 0x00000001 (NEEDED) Shared library: [libc.so.3] I am not sure how I can just statically link to the static libcpp library. Could you also reproduce it? @Mario: If I could use the QNX 6.6 toolchain for building binaries (at least with statically linked libcpp library) which can be deployed on a QNX 6.5 target, it would save me lots of linking time. In my case, linking my big app using the QNX 6.5's ld takes ~15-20 minutes or even more, while using QNX 6.6's ld is much faster. I am not sure how fast it is, but it won't take longer than 5 minutes. Thanks, Anton Mon, 22 Sep 2014 21:08:44 GMT http://community.qnx.com/sf/go/post111830 Anton Indrawan(deleted) 2014-09-22T21:08:44Z http://community.qnx.com/sf/go/post111819 Why would you want to do that ? -----Message d'origine----- De : Anton Indrawan [mailto:community-noreply@qnx.com] Envoyé : 22 septembre 2014 03:55 À : general-toolchain Objet : QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target Hi guys, I understood that binaries produced by QNX 6.5 toolchain will work on QNX 6.6 targets. I was wondering whether the other way around would work. So, I created a hello world application which basically does a printf, compiled with QNX 6.6's QCC, deployed on a QNX 6.5 target and that worked. However, when I was using std::pow, it threw a memory fault. Here is the test code: #include <stdio.h> #include <math.h> int main() { double result = std::pow(2.0, 2); printf("Result: %lf\n", result); return 0; } Compile with: QCC -Vgcc_ntoarmv7le -Bstatic -lcpp math.cpp -lm. Note: I statically linked the program against libcpp and libm using the -Bstatic option. Can somebody confirm that this is the right way to statically link to the static libcpp library. Best regards, Anton _______________________________________________ General http://community.qnx.com/sf/go/post111814 To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com Mon, 22 Sep 2014 14:18:57 GMT http://community.qnx.com/sf/go/post111819 Mario Charest 2014-09-22T14:18:57Z