Feed for discussion General in project Core Development Tools.
http://community.qnx.com/sf/discussion/do/listTopics/projects.toolchain/discussion.core_development_tools
Posts for Generalpost122271: Re: Python script to debug my binary using gdb on QNX OS
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-PythonPeter Nguyen2023-05-19T16:23:03Zpost122239: Re: Python script to debug my binary using gdb on QNX OS
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.Jim Sleeth2023-04-28T16:03:11Zpost122124: Python script to debug my binary using gdb on QNX OS
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?Preethi Selvaraju2023-02-01T04:21:42Zpost121942: Anyone compile and use GDB native to QNX on 7.1?
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.topc28211Tyler Bernhardt(deleted)2022-09-26T17:31:37Zpost121941: Re: GDB Native On QNX OS 7.1
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?Jim P(deleted)2022-09-26T14:21:57Zpost121905: Re: GDB On QNX OS
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.htmlJohn Kearney2022-08-26T17:18:10Zpost121903: Re: GDB On QNX OS
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.htmlJim Sleeth2022-08-26T11:18:21Zpost121902: GDB On QNX OS
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.Preethi Selvaraju2022-08-25T04:00:56Zpost121620: Re: Rust for QNX 7
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, FlorianFlorian Bartels2021-10-11T14:37:38Zpost121619: Re: Rust for QNX 7
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.
JimJim Sleeth2021-10-08T20:10:36Zpost121615: Rust for QNX 7
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 regardsFlorian Bartels2021-10-06T18:39:45Zpost121128: gcc 4.8.3 and binutils 2.25 + QNX650
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.Pavel Kopylov(deleted)2020-11-27T20:49:50Zpost120155: Use GCC 4.8.1 for QNX6.4.1
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.Danny Yen(deleted)2020-01-16T18:23:55Zpost120086: Re: RE: Looking for debug symbols of libstdc++.so.6
http://community.qnx.com/sf/go/post120086
Sorry forgot to mention it is for aarch64le architectue.Roberto Alejandro Flores Estrada2019-11-26T14:47:21Zpost120085: Re: RE: Looking for debug symbols of libstdc++.so.6
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.Roberto Alejandro Flores Estrada2019-11-26T14:46:13Zpost120002: Where can i get the BSP for Raspberry Pi 3 board?
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.Dharani kumar Srinivasan(deleted)2019-09-27T11:24:47Zpost119979: Thread Sanitizer
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,
AaronAaron Husz2019-09-24T22:00:05Zpost119754: where i can find a guide to develop CAN bus driver
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.Chris Liang(deleted)2019-06-11T20:17:30Zpost119753: Re: How to use just compiled gcc to build programs for a target (in Momentics)
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"fn ln(deleted)2019-06-10T22:39:57Zpost119752: How to use just compiled gcc to build programs for a target (in Momentics)
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?fn ln(deleted)2019-06-10T21:08:16Zpost119744: PCI program is crashing
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 ()Anand Shastry2019-06-07T12:47:11Zpost119734: Re: Building gcc 8 for QNX 6.6
http://community.qnx.com/sf/go/post119734
*Can you run the new compiler with qcc?fn ln(deleted)2019-06-06T20:27:43Zpost119733: Re: Building gcc 8 for QNX 6.6
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?fn ln(deleted)2019-06-06T20:26:29Zpost119722: Re: RE: Qcc and spaces in arguments
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.Tom Rouillard(deleted)2019-06-03T08:42:56Zpost119721: RE: Qcc and spaces in arguments
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.comJohn Kearney2019-05-31T19:48:26Zpost119715: Qcc and spaces in arguments
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,
TomTom Rouillard(deleted)2019-05-29T07:35:06Zpost119586: Re: Integrating QNX toolchain into Bitbake/OpenEmbedded/Yocto as a foreign (external) tool-chain
http://community.qnx.com/sf/go/post119586
hey this seems quite interesting.
any progress so far?
I'd love to contribute.bernardo araujo rodrigues(deleted)2019-03-16T17:48:12Zpost119538: Re: Building gcc 8 for QNX 6.6
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.Kevin Stallard(deleted)2019-02-24T07:27:32Zpost119537: Re: Uncertain header file inclusions in gcc build
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
KevinKevin Stallard(deleted)2019-02-24T06:55:52Zpost119536: Re: Building gcc 8 for QNX 6.6
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.Kevin Stallard(deleted)2019-02-24T06:54:07Zpost119535: Re: Uncertain header file inclusions in gcc build
http://community.qnx.com/sf/go/post119535
Sure is quiet around here these days....Kevin Stallard(deleted)2019-02-22T10:12:53Zpost119525: Uncertain header file inclusions in gcc build
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!
KevinKevin Stallard(deleted)2019-02-15T19:32:30Zpost119524: Re: Building gcc 8 for QNX 6.6
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
KevinKevin Stallard(deleted)2019-02-15T18:44:24Zpost119514: Re: Building gcc 8 for QNX 6.6
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....Kevin Stallard(deleted)2019-02-13T20:28:54Zpost119513: Re: Building gcc 8 for QNX 6.6
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
KevinKevin Stallard(deleted)2019-02-13T19:30:41Zpost119506: Building gcc 8 for QNX 6.6
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
KevinKevin Stallard(deleted)2019-02-13T07:15:32Zpost119375: What is the POSIX version of QNX SDP 7.0
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,
VijayVijay Chinimilli2018-12-27T10:24:00Zpost119371: RE: Clang support inn QNX
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.comJohn Kearney2018-12-19T12:57:57Zpost119370: Clang support inn QNX
http://community.qnx.com/sf/go/post119370
Hello,
Is there any support of clang in QNX?Vijay Chinimilli2018-12-19T12:42:47Zpost119120: Re: GCC 4.8.3 instalation
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 lineElena Laskavaia2018-09-17T17:53:52Zpost119098: Re: GCC 4.8.3 instalation
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.Vasilij Yanikeev(deleted)2018-09-14T05:41:43Zpost119097: Re: GCC 4.8.3 instalation
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.Vasilij Yanikeev(deleted)2018-09-14T05:41:42Zpost119096: Re: GCC 4.8.3 instalation
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.Vasilij Yanikeev(deleted)2018-09-14T05:41:41Zpost119095: Re: GCC 4.8.3 instalation
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,
BobBob Powell2018-09-13T15:49:54Zpost119094: GCC 4.8.3 instalation
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?Vasilij Yanikeev(deleted)2018-09-13T11:00:39Zpost119093: GCC 4.8.3 instalation
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?Vasilij Yanikeev(deleted)2018-09-13T11:00:38Zpost119092: GCC 4.8.3 instalation
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?Vasilij Yanikeev(deleted)2018-09-13T11:00:36Zpost119043: Re: "Resource busy" error when try to collect tracelog
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.Steve Reid2018-08-08T17:32:00Zpost119042: Re: "Resource busy" error when try to collect tracelog
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
OZOvidiu Zaharia2018-08-08T14:42:58Zpost118843: Re: Is there an easy way to print compiler information during a make?
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.Jim Sleeth2018-05-23T16:35:30Zpost118842: Re: Is there an easy way to print compiler information during a make?
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?Eric Fossum(deleted)2018-05-22T22:02:08Zpost118837: Re: Is there an easy way to print compiler information during a make?
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.Jim Sleeth2018-05-19T21:59:39Zpost118820: QNX 6.6.0 with GCC 4.9.3 Requires Path?
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?Kevin Smith(deleted)2018-05-16T20:35:21Zpost118815: Is there an easy way to print compiler information during a make?
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?Eric Fossum(deleted)2018-05-15T18:10:42Zpost118786: Re: CLANG QNX650
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?Ivo Petkovic(deleted)2018-04-24T06:44:19Zpost118749: Re: CLANG QNX650
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 \
../trunkMario Charest2018-04-09T13:31:25Zpost118748: Re: CLANG QNX650
http://community.qnx.com/sf/go/post118748
Hi Mario,
Could you share the patches for clang?Ivo Petkovic(deleted)2018-04-09T07:39:20Zpost118420: Re: QNX 7/Momentics 4.7 C linker error: VFP Register arguments
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 :)Chris Buck(deleted)2018-01-22T13:56:22Zpost118405: QNX 7/Momentics 4.7 C linker error: VFP Register arguments
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!Chris Buck(deleted)2018-01-18T22:27:16Zpost118247: How can i rebase the QNX provided msys-1.0 dll
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,
Manasmanas sahoo2017-11-29T08:50:01Zpost118198: uncaught_exception doesn't work with Dinkumware
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 normallyNiklas Angare2017-11-13T19:30:31Zpost118192: CLANG QNX650
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.Mario Charest2017-11-11T00:28:39Zpost118163: Re: linux-gcc-4.9.3-qnx660.tar.gz needs a qcc update
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)?
ThanksKevin Stallard(deleted)2017-10-31T04:20:47Zpost118162: Re: "Ignoring unknown option" output when using 4.9,3 compiler
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
KevinKevin Stallard(deleted)2017-10-31T03:44:35Zpost118151: Making nand memory (etfs filesystem) noexec
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?Dimitar Slavchev2017-10-26T13:32:38Zpost118147: Re: hidden symbol `_Unwind_Resume' error with GCC 4.9.3 and QNX SDP 6.6.0
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,
RajuRaju A(deleted)2017-10-25T14:39:10Zpost118089: Re: gdb disconnects from Armv7 target (AM335) on break point hit
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_0Elena Laskavaia2017-09-29T17:10:01Zpost118022: Re: GOLD linker for QNX
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 MansfieldMario Charest2017-09-08T04:12:41Zpost118018: QNX developper
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.comFarshid Shadpey(deleted)2017-09-06T20:52:00Zpost118017: qcc with higher gcc version
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 youMartin Knotek(deleted)2017-09-06T11:19:51Zpost117947: "Ignoring unknown option" output when using 4.9,3 compiler
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,
RodneyRodney Dowdall(deleted)2017-08-08T14:55:21Zpost117797: gdb disconnects from Armv7 target (AM335) on break point hit
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
KevinKevin Stallard(deleted)2017-06-19T23:46:50Zpost117737: RE: Looking for debug symbols of libstdc++.so.6
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.comMax Feil2017-05-16T17:12:53Zpost117725: Looking for debug symbols of libstdc++.so.6
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?Claudia Choi2017-05-10T20:32:40Zpost117282: Mudflap Launch Error: executable must have DT_BIND_NOW or environment variable LD_BIND_NOW must be set
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,MurugaiyanMurugaiyan Perumal(deleted)2016-12-15T09:51:52Zpost117092: Re: Building GCC
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.Michael Daniels(deleted)2016-11-07T18:46:38Zpost117032: Re: Building GCC
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 :))Alexey Smirnov(deleted)2016-10-30T07:33:01Zpost116967: linux-gcc-4.9.3-qnx660.tar.gz needs a qcc update
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'Oleh Derevenko2016-10-12T21:14:57Zpost116943: Missing options for mkqnx6fsimg
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,
SannaSanna Haraginadoni(deleted)2016-10-05T17:32:09Zpost116932: Re: RE: New Guy here
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?Matthew Johnston(deleted)2016-09-30T16:08:59Zpost116924: RE: New Guy here
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.comMario Charest2016-09-30T12:59:58Zpost116923: New Guy here
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.Matthew Johnston(deleted)2016-09-30T12:33:30Zpost116878: Re: about Intel Thread Building Block support on QNX
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
> Leilei xing(deleted)2016-09-24T18:17:04Zpost116876: Re: Query in qnx
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
>Ramanna M(deleted)2016-09-24T13:19:39Zpost116875: Re: Query in qnx
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.Michael Daniels(deleted)2016-09-24T12:41:36Zpost116874: Query in qnx
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.Ramanna M(deleted)2016-09-24T07:59:35Zpost116812: Behaviour conflict with api screen_create_context(&screen_ctx, SCREEN_APPLICATION_CONTEXT);
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,
RupaliRupali Kotgire(deleted)2016-09-19T10:06:21Zpost116664: Re: GCC 4.8.3 doesn't recognize C++11 mathematics functions
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); }Michael Daniels(deleted)2016-08-17T11:39:07Zpost116663: GCC 4.8.3 doesn't recognize C++11 mathematics functions
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?Denis Kimcherenko(deleted)2016-08-17T10:42:54Zpost116661: Re: 4.8.3 (QNX650) and new to_string(), stoi() ...
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=4Denis Kimcherenko(deleted)2016-08-17T07:52:36Zpost116660: Re: GCC nor 4.8.3 neither 4.9.3 doesn't support to_string C++11 feature
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/customDenis Kimcherenko(deleted)2016-08-17T07:51:00Zpost116658: Re: GCC nor 4.8.3 neither 4.9.3 doesn't support to_string C++11 feature
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.Mario Charest2016-08-16T17:12:24Zpost116657: Re: GCC nor 4.8.3 neither 4.9.3 doesn't support to_string C++11 feature
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'Denis Kimcherenko(deleted)2016-08-16T16:10:36Zpost116656: Re: GCC nor 4.8.3 neither 4.9.3 doesn't support to_string C++11 feature
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.Michael Daniels(deleted)2016-08-16T15:52:50Zpost116653: GCC nor 4.8.3 neither 4.9.3 doesn't support to_string C++11 feature
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?Denis Kimcherenko(deleted)2016-08-15T11:07:33Zpost116652: Re: 4.8.3 (QNX650) and new to_string(), stoi() ...
http://community.qnx.com/sf/go/post116652
Hi guys,
Did someone find a solution how to use to_string ?Denis Kimcherenko(deleted)2016-08-15T10:51:53Zpost116629: Re: Building GCC
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 ;-)Mario Charest2016-08-03T13:32:14Zpost116628: Re: Building GCC
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.Michael Daniels(deleted)2016-08-02T21:53:31Zpost116627: Re: Building GCC
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 2Mario Charest2016-08-02T21:22:52Zpost116626: Re: Building GCC
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.Michael Daniels(deleted)2016-08-02T21:12:17Zpost116625: Building GCC
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.
- MarioMario Charest2016-08-02T20:24:53Zpost116514: RE: hidden symbol `_Unwind_Resume' error with GCC 4.9.3 and QNX SDP 6.6.0
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.comMario Charest2016-07-04T15:40:52Zpost116513: Re: hidden symbol `_Unwind_Resume' error with GCC 4.9.3 and QNX SDP 6.6.0
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_9Michael Daniels(deleted)2016-07-04T15:39:02Zpost116512: Re: hidden symbol `_Unwind_Resume' error with GCC 4.9.3 and QNX SDP 6.6.0
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 ?Mario Charest2016-07-04T13:29:46Zpost116511: Re: hidden symbol `_Unwind_Resume' error with GCC 4.9.3 and QNX SDP 6.6.0
http://community.qnx.com/sf/go/post116511
For what it's worth, the 4.8 and 4.9 packages have been updated.Michael Daniels(deleted)2016-07-04T11:38:27Zpost116488: Re: hidden symbol `_Unwind_Resume' error with GCC 4.9.3 and QNX SDP 6.6.0
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.Michael Daniels(deleted)2016-06-27T13:53:16Zpost116487: Re: hidden symbol `_Unwind_Resume' error with GCC 4.9.3 and QNX SDP 6.6.0
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>.e zhong(deleted)2016-06-27T13:43:34Zpost116486: Re: hidden symbol `_Unwind_Resume' error with GCC 4.9.3 and QNX SDP 6.6.0
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?
Erice zhong(deleted)2016-06-26T03:05:50Zpost116483: Re: hidden symbol `_Unwind_Resume' error with GCC 4.9.3 and QNX SDP 6.6.0
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.Michael Daniels(deleted)2016-06-24T20:22:38Zpost116482: hidden symbol `_Unwind_Resume' error with GCC 4.9.3 and QNX SDP 6.6.0
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!
Erice zhong(deleted)2016-06-24T20:14:00Zpost116354: Re: Include<boost/shared_ptr> doesn't compile with QNX 6.6 QCC and c++11
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
>Will Miles2016-05-27T18:20:02Zpost116353: Re: Include<boost/shared_ptr> doesn't compile with QNX 6.6 QCC and c++11
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.Michael Daniels(deleted)2016-05-27T15:19:46Zpost116346: Re: Include<boost/shared_ptr> doesn't compile with QNX 6.6 QCC and c++11
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.Anton Indrawan(deleted)2016-05-26T20:15:45Zpost116343: Re: Include<boost/shared_ptr> doesn't compile with QNX 6.6 QCC and c++11
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...Alexander Fagrell(deleted)2016-05-26T11:40:18Zpost116337: Re: Include<boost/shared_ptr> doesn't compile with QNX 6.6 QCC and c++11
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.Michael Daniels(deleted)2016-05-25T16:12:38Zpost116332: Re: Include<boost/shared_ptr> doesn't compile with QNX 6.6 QCC and c++11
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? ThanksAlexander Fagrell(deleted)2016-05-25T13:56:05Zpost116307: Re: Include<boost/shared_ptr> doesn't compile with QNX 6.6 QCC and c++11
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.Michael Daniels(deleted)2016-05-19T16:17:39Zpost116305: Re: Include<boost/shared_ptr> doesn't compile with QNX 6.6 QCC and c++11
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.Alexander Fagrell(deleted)2016-05-19T16:01:15Zpost116179: Re: python2.7 (gdb-prereq): missing _scruct module
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.Igor Rondarev2016-04-27T12:31:40Zpost116135: Re: python2.7 (gdb-prereq): missing _scruct module
http://community.qnx.com/sf/go/post116135
What's missing from the win32 package?Michael Daniels(deleted)2016-04-23T20:41:42Zpost116124: Re: std::mutex::lock fails when on same stack address as another mutex before
http://community.qnx.com/sf/go/post116124
Thank you!Mario Charest2016-04-20T14:35:56Zpost116123: Re: std::mutex::lock fails when on same stack address as another mutex before
http://community.qnx.com/sf/go/post116123
Updated packages for 4.8 have been uploaded.Michael Daniels(deleted)2016-04-20T14:33:29Zpost115898: Re: How to use libcpp.so.4 instead of lincpp.so.5 in qnx SDP 6.6?
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.Michael Daniels(deleted)2016-03-03T14:29:10Zpost115896: How to use libcpp.so.4 instead of lincpp.so.5 in qnx SDP 6.6?
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?swapnil Belote(deleted)2016-03-03T06:40:14Zpost115888: Re: python2.7 (gdb-prereq): missing _scruct module
http://community.qnx.com/sf/go/post115888
Michael,
thank you, it works indeed. Could you please provide win32 build too?Igor Rondarev2016-03-01T09:51:44Zpost115873: Re: std::mutex::lock fails when on same stack address as another mutex before
http://community.qnx.com/sf/go/post115873
> I'll take a look when I get some time.
Doctor, any hope?Mario Charest2016-02-26T17:00:30Zpost115841: Re: Build problem when using 5.1 branch (possibly applies elsewhere)
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.Michael Daniels(deleted)2016-02-22T21:06:35Zpost115832: Build problem when using 5.1 branch (possibly applies elsewhere)
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).Alex Khripin2016-02-22T16:10:43Zpost115691: Re: python2.7 (gdb-prereq): missing _scruct module
http://community.qnx.com/sf/go/post115691
Now works just fine, thanks!Alexey Smirnov(deleted)2016-02-08T06:29:35Zpost115690: Re: python2.7 (gdb-prereq): missing _scruct module
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.Michael Daniels(deleted)2016-02-06T17:52:27Zpost115681: Re: python2.7 (gdb-prereq): missing _scruct module
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?Alexey Smirnov(deleted)2016-02-05T12:52:10Zpost115673: Re: GOLD linker for QNX
http://community.qnx.com/sf/go/post115673
Yup. It seems I didn't realize how old the thread was.Michael Daniels(deleted)2016-02-03T23:30:33Zpost115672: Re: GOLD linker for QNX
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 issueMario Charest2016-02-03T23:28:14Zpost115671: Re: GOLD linker for QNX
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.Michael Daniels(deleted)2016-02-03T23:16:24Zpost115670: Re: GOLD linker for QNX
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.Michael Daniels(deleted)2016-02-03T22:30:16Zpost115669: Re: python2.7 (gdb-prereq): missing _scruct module
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.Michael Daniels(deleted)2016-02-03T21:51:47Zpost115637: Re: GOLD linker for QNX
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/fMario Charest2016-01-30T02:10:12Zpost115606: python2.7 (gdb-prereq): missing _scruct module
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,
IgorIgor Rondarev2016-01-25T15:44:26Zpost115589: Re: std::mutex::lock fails when on same stack address as another mutex before
http://community.qnx.com/sf/go/post115589
I'll take a look when I get some time.Michael Daniels(deleted)2016-01-22T13:06:41Zpost115587: Re: std::mutex::lock fails when on same stack address as another mutex before
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".Mario Charest2016-01-22T03:46:35Zpost115586: RE: QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target
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.comMario Charest2016-01-21T23:38:41Zpost115585: Re: QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target
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,
JohnJohn Hagen(deleted)2016-01-21T23:36:42Zpost115372: Re: RE: RE: Specifying the -gsplit-dwarf option
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.Rodney Dowdall(deleted)2015-12-22T01:15:24Zpost115371: Re: RE: RE: Specifying the -gsplit-dwarf option
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,
RodneyRodney Dowdall(deleted)2015-12-22T00:10:15Zpost115370: RE: RE: Specifying the -gsplit-dwarf option
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.comMichael Daniels(deleted)2015-12-21T23:50:16Zpost115369: Re: RE: Specifying the -gsplit-dwarf option
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,
RodneyRodney Dowdall(deleted)2015-12-21T23:41:38Zpost115368: RE: Specifying the -gsplit-dwarf option
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.comMichael Daniels(deleted)2015-12-21T23:03:12Zpost115366: Specifying the -gsplit-dwarf option
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,
RodneyRodney Dowdall(deleted)2015-12-21T19:37:20Zpost115294: Re: Undefined simple when compiling C++ for armv7le using 4.9.3
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,
RodneyRodney Dowdall(deleted)2015-12-12T23:34:35Zpost115293: Undefined simple when compiling C++ for armv7le using 4.9.3
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,
RodneyRodney Dowdall(deleted)2015-12-12T19:01:31Zpost114584: GCC 4.9.3 error: hidden symbol `__aeabi_ldiv0'
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.Daniel Levin(deleted)2015-10-02T17:47:03Zpost114545: Re: RE: Using the 4.8.1 Compiler
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.?Sriram Sundararajan(deleted)2015-09-29T20:23:07Zpost114538: Re: std::mutex::lock fails when on same stack address as another mutex before
http://community.qnx.com/sf/go/post114538
Thank you for the fix.
Will this be included in a new "File release" of this project?Matthias Gehre(deleted)2015-09-29T07:54:12Zpost114516: Re: std::mutex::lock fails when on same stack address as another mutex before
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 MansfieldRyan Mansfield(deleted)2015-09-24T18:09:09Zpost114515: RE: std::mutex::lock fails when on same stack address as another mutex before
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.comMario Charest2015-09-24T18:04:10Zpost114514: Re: std::mutex::lock fails when on same stack address as another mutex before
http://community.qnx.com/sf/go/post114514
Ryan,
Related: Check out case 00139008 and bug report (JIRA ID 812757)
- CheersMario Charest2015-09-24T18:02:12Zpost114512: Re: std::mutex::lock fails when on same stack address as another mutex before
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 MansfieldRyan Mansfield(deleted)2015-09-24T17:56:47Zpost114509: Re: std::mutex::lock fails when on same stack address as another mutex before
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?Matthias Gehre(deleted)2015-09-24T10:54:04Zpost114507: Re: std::mutex::lock fails when on same stack address as another mutex before
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.Matthias Gehre(deleted)2015-09-24T08:26:49Zpost114497: std::mutex::lock fails when on same stack address as another mutex before
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 GehreMatthias Gehre(deleted)2015-09-23T13:49:27Zpost114253: Re: ARM hosted complier?
http://community.qnx.com/sf/go/post114253
The compiler itself is only available for x86 hosts (Neutrino, Linux or Windows) for 6.5.0.Dave Nickerson2015-08-11T19:39:02Zpost114243: ARM hosted complier?
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.Zhiying Xiang(deleted)2015-08-10T07:04:25Zpost114156: Re: GOLD linker for QNX
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.Rodney Dowdall(deleted)2015-07-23T14:05:14Zpost114139: Re: GOLD linker for QNX
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 MansfieldRyan Mansfield(deleted)2015-07-16T18:14:01Zpost114136: Re: GOLD linker for QNX
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,
RodneyRodney Dowdall(deleted)2015-07-16T18:02:29Zpost114130: Re: GOLD linker for QNX
http://community.qnx.com/sf/go/post114130
Thanks Ryan. I'll give these a try and let you know how it goes.Rodney Dowdall(deleted)2015-07-15T13:59:43Zpost114129: Re: GOLD linker for QNX
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 MansfieldRyan Mansfield(deleted)2015-07-15T13:57:22Zpost114128: Re: GOLD linker for QNX
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
>Ryan Mansfield(deleted)2015-07-15T13:25:56Zpost114127: Re: GOLD linker for QNX
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,
RodneyRodney Dowdall(deleted)2015-07-15T13:19:24Zpost114126: Re: GOLD linker for QNX
http://community.qnx.com/sf/go/post114126
Yes, it should work on 6.5.0SP1
Regards,
Ryan MansfieldRyan Mansfield(deleted)2015-07-15T13:16:10Zpost114125: GOLD linker for QNX
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,
RodneyRodney Dowdall(deleted)2015-07-15T12:58:17Zpost114033: Re: QNX650: qcc (4.8.3) gives error while loading shared libraries (libstdc++.so.6)
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.Jane McIllen(deleted)2015-06-26T19:28:20Zpost114031: Re: QNX650: qcc (4.8.3) gives error while loading shared libraries (libstdc++.so.6)
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
>Ryan Mansfield(deleted)2015-06-26T19:08:56Zpost114030: QNX650: qcc (4.8.3) gives error while loading shared libraries (libstdc++.so.6)
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?Jane McIllen(deleted)2015-06-26T19:03:33Zpost114001: Re: Can't find array include when using "4.8.3,gcc_ntox86_cpp-ne" variant
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,
RodneyRodney Dowdall(deleted)2015-06-22T13:13:12Zpost113996: Re: GDB for powerpc-unknown-nto-qnx6.5.0
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.JAMES IGOU(deleted)2015-06-21T14:53:00Zpost113995: Re: Can't find array include when using "4.8.3,gcc_ntox86_cpp-ne" variant
http://community.qnx.com/sf/go/post113995
Thanks Ryan, that solved it.Rodney Dowdall(deleted)2015-06-20T00:13:42Zpost113993: Re: Can't find array include when using "4.8.3,gcc_ntox86_cpp-ne" variant
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.comRyan Mansfield(deleted)2015-06-19T23:26:23Zpost113992: Re: RE: Can't find array include when using "4.8.3,gcc_ntox86_cpp-ne" variant
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,
RodneyRodney Dowdall(deleted)2015-06-19T23:20:18Zpost113991: Re: RE: Can't find array include when using "4.8.3,gcc_ntox86_cpp-ne" variant
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,
RodneyRodney Dowdall(deleted)2015-06-19T19:57:16Zpost113990: Re: RE: Can't find array include when using "4.8.3,gcc_ntox86_cpp-ne" variant
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.Rodney Dowdall(deleted)2015-06-19T18:26:46Zpost113989: RE: Can't find array include when using "4.8.3,gcc_ntox86_cpp-ne" variant
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.comMario Charest2015-06-19T18:24:35Zpost113988: Re: Can't find array include when using "4.8.3,gcc_ntox86_cpp-ne" variant
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,
RodneyRodney Dowdall(deleted)2015-06-19T18:23:28Zpost113987: Re: Can't find array include when using "4.8.3,gcc_ntox86_cpp-ne" variant
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 MansfieldRyan Mansfield(deleted)2015-06-19T17:51:25Zpost113986: Re: Can't find array include when using "4.8.3,gcc_ntox86_cpp-ne" variant
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?Rodney Dowdall(deleted)2015-06-19T17:48:54Zpost113985: Re: Can't find array include when using "4.8.3,gcc_ntox86_cpp-ne" variant
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 MansfieldRyan Mansfield(deleted)2015-06-19T17:44:03Zpost113984: Can't find array include when using "4.8.3,gcc_ntox86_cpp-ne" variant
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,
RodneyRodney Dowdall(deleted)2015-06-19T17:37:15Zpost113972: Re: GCC for powerpc-unknown-nto-qnx6.5.0
http://community.qnx.com/sf/go/post113972
Yes, I've reconfigured and rebuilt gcc.Maxim Kuzmin(deleted)2015-06-18T09:21:53Zpost113964: Re: GCC for powerpc-unknown-nto-qnx6.5.0
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 MansfieldRyan Mansfield(deleted)2015-06-17T13:59:41Zpost113963: Re: GCC for powerpc-unknown-nto-qnx6.5.0
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?Maxim Kuzmin(deleted)2015-06-17T08:23:02Zpost113959: Re: GCC for powerpc-unknown-nto-qnx6.5.0
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 MansfieldRyan Mansfield(deleted)2015-06-16T13:52:35Zpost113958: Re: GCC for powerpc-unknown-nto-qnx6.5.0
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?Maxim Kuzmin(deleted)2015-06-16T13:51:13Zpost113937: GCC for powerpc-unknown-nto-qnx6.5.0
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-nlsMaxim Kuzmin(deleted)2015-06-09T10:35:49Zpost113890: Re: RE: API for unique thread-id in QNX
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;
}Mayank Jain(deleted)2015-06-01T16:36:33Zpost113889: RE: API for unique thread-id in QNX
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.comJohn Kearney2015-06-01T16:10:10Zpost113882: RE: API for unique thread-id in QNX
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?Gervais Mulongoy2015-06-01T12:17:31Zpost113881: API for unique thread-id in QNX
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.Mayank Jain(deleted)2015-06-01T12:14:23Zpost113828: Re: GDB for powerpc-unknown-nto-qnx6.5.0
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!Maxim Kuzmin(deleted)2015-05-18T08:52:09Zpost113824: Re: GDB for powerpc-unknown-nto-qnx6.5.0
http://community.qnx.com/sf/go/post113824
Touch those files that want to get regenerated
E.g.
$ touch gdb-6.8/bfd/doc/bfd.infoAleksandar Ristovski(deleted)2015-05-15T14:23:34Zpost113822: Re: GDB for powerpc-unknown-nto-qnx6.5.0
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.Maxim Kuzmin(deleted)2015-05-15T08:13:58Zpost113819: Re: GDB for powerpc-unknown-nto-qnx6.5.0
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/gdbAleksandar Ristovski(deleted)2015-05-14T14:37:47Zpost113818: Re: GDB for powerpc-unknown-nto-qnx6.5.0
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 MansfieldRyan Mansfield(deleted)2015-05-14T14:35:19Zpost113817: Re: GDB for powerpc-unknown-nto-qnx6.5.0
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.
---
AleksandarAleksandar Ristovski(deleted)2015-05-14T14:30:17Zpost113816: Re: GDB for powerpc-unknown-nto-qnx6.5.0
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".Maxim Kuzmin(deleted)2015-05-14T14:11:50Zpost113815: Re: GDB for powerpc-unknown-nto-qnx6.5.0
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,
AleksAleksandar Ristovski(deleted)2015-05-14T13:21:20Zpost113814: GDB for powerpc-unknown-nto-qnx6.5.0
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?Maxim Kuzmin(deleted)2015-05-14T09:28:49Zpost113438: Re: Linking issue with 4.8.3 under 650
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!Alexey Smirnov(deleted)2015-02-28T11:05:01Zpost113360: Re: QCC cross-compile neon error
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.Aaron Gawlik(deleted)2015-02-20T16:19:34Zpost113358: Re: QCC cross-compile neon error
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 MansfieldRyan Mansfield(deleted)2015-02-20T16:00:40Zpost113356: QCC cross-compile neon error
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.Aaron Gawlik(deleted)2015-02-20T15:54:35Zpost113269: Re: Mudflap library with backtrace
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.
>Elena Laskavaia2015-02-09T14:26:44Zpost113197: Mudflap library with backtrace
http://community.qnx.com/sf/go/post113197
Hello
How to enable printing backtrace in mudflap violations?
I use SDK 6.5.0
Dmitry Zhelobanov.Dmitry Zhelobanov(deleted)2015-02-03T07:40:40Zpost113109: Re: Verbosity of build process
http://community.qnx.com/sf/go/post113109
Thank you - that was exactly what I was looking for!
Best regards,
VincentVincent Wan(deleted)2015-01-27T21:58:57Zpost113086: Re: Verbosity of build process
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.comColin Burgess(deleted)2015-01-27T01:08:07Zpost113085: Verbosity of build process
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.Vincent Wan(deleted)2015-01-27T01:05:08Zpost112776: Re: realpath() on QNX.
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 );
> }Sean Boudreau(deleted)2014-12-24T00:51:22Zpost112759: realpath() on QNX.
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
-AkshatAkshat Gill(deleted)2014-12-22T12:48:42Zpost112756: readlink() error on QNX.
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
-AkshatAkshat Gill(deleted)2014-12-22T11:49:19Zpost112347: Include<boost/shared_ptr> doesn't compile with QNX 6.6 QCC and c++11
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,
AntonAnton Indrawan(deleted)2014-11-14T18:03:09Zpost112288: Re: complex.h 4.7.2
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] "Peter Luscher(deleted)2014-11-06T14:35:35Zpost112066: objdump problem with GCC 4.8.3 + QNX6.5.0
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 putsMario Charest2014-10-18T00:05:50Zpost112065: Re: RE: RE: Make builds excruciatingly slow -- sometimes
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.Kevin Schaffer(deleted)2014-10-17T19:45:52Zpost112045: Re: RE: RE: Make builds excruciatingly slow -- sometimes
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.Kevin Schaffer(deleted)2014-10-15T13:57:27Zpost112033: Re: boost::math::isnan doesn't compile with QNX 6.6 QCC
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,
AntonAnton Indrawan(deleted)2014-10-11T18:50:18Zpost112024: RE: RE: Make builds excruciatingly slow -- sometimes
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.comMario Charest2014-10-10T14:35:29Zpost112022: Re: RE: Make builds excruciatingly slow -- sometimes
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.Kevin Schaffer(deleted)2014-10-10T14:16:58Zpost112015: RE: Make builds excruciatingly slow -- sometimes
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.comMario Charest2014-10-09T22:03:50Zpost112014: Make builds excruciatingly slow -- sometimes
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?Kevin Schaffer(deleted)2014-10-09T21:24:50Zpost112000: Re: boost::math::isnan doesn't compile with QNX 6.6 QCC
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.htmlNiklas Angare2014-10-09T10:58:38Zpost111973: Re: mkifs corrupts io-hid, one binary before and one binary after
http://community.qnx.com/sf/go/post111973
Here is the build file I have been using.
Thanks
KevinKevin Stallard2014-10-04T22:18:40Zpost111972: Re: mkifs corrupts io-hid, one binary before and one binary after
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
> KevinKevin Stallard2014-10-04T22:13:47Zpost111970: Re: mkifs corrupts io-hid, one binary before and one binary after
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
KevinKevin Stallard2014-10-04T22:01:20Zpost111965: Re: mkifs corrupts io-hid, one binary before and one binary after
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?
--KevinKevin Stallard2014-10-03T07:34:57Zpost111964: mkifs corrupts io-hid, one binary before and one binary after
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...Kevin Stallard2014-10-03T03:42:32Zpost111957: Re: QNX SDP 6.6.0 on SUSE Linux
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.Vincent Wan(deleted)2014-10-02T16:44:16Zpost111950: Re: Corrupted File System detected when using mkqnx6fsimg
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.comKevin Stallard2014-10-01T19:45:43Zpost111939: Re: Corrupted File System detected when using mkqnx6fsimg
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:
ThomasThomas Haupt2014-10-01T06:39:54Zpost111928: Re: Corrupted File System detected when using mkqnx6fsimg
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!Kevin Stallard2014-09-30T12:06:42Zpost111925: Re: Corrupted File System detected when using mkqnx6fsimg
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
> KevinKevin Stallard2014-09-30T04:00:53Zpost111924: Corrupted File System detected when using mkqnx6fsimg
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
KevinKevin Stallard2014-09-30T03:54:54Zpost111923: Re: How do I create a file system image using 'mkqnx6fsimg', which is bootable?
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...
KevinKevin Stallard2014-09-30T03:40:55Zpost111902: RE: RE: QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target
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.comMario Charest2014-09-26T21:05:54Zpost111901: Re: RE: QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target
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,
AntonAnton Indrawan(deleted)2014-09-26T20:13:07Zpost111882: Re: RE: QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target
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.Mario Charest2014-09-25T17:04:34Zpost111881: Re: RE: QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target
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,
AntonAnton Indrawan(deleted)2014-09-25T16:52:38Zpost111880: Re: QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target
http://community.qnx.com/sf/go/post111880
Hi Ryan,
This works well. Thank you.
Best regards,
AntonAnton Indrawan(deleted)2014-09-25T16:50:34Zpost111858: Re: QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target
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 MansfieldRyan Mansfield(deleted)2014-09-24T01:27:15Zpost111831: RE: QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target
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.comMario Charest2014-09-22T21:53:46Zpost111830: Re: QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target
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,
AntonAnton Indrawan(deleted)2014-09-22T21:08:44Zpost111819: RE: QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target
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.comMario Charest2014-09-22T14:18:57Z