Feed for discussion General in project Core Development Tools.

post122271: Re: Python script to debug my binary using gdb on QNX OS

Peter Nguyen — Fri, 19 May 2023 16:23:03 GMT

You can put those commands in the testscript.py

targetIP=xxx.xxx.xxx.xxx

binpath='D:/Project/develop/sample'

gdb.execute(f"target qnx {targetIP}:8000")

gdb.execute(f"file {binpath}")

In gdb console, use `source` command to execute the script.

(gdb) > source /path/to/testscript.py

To execute the script from outside gdb CLI:

# ntoaarch64-gdb --init-eval-command="source /path/to/testscript.py"

Bonus:

You can run an interactive python shell in the gdb session to test your commands first:

(gdb) > python-interactive

>>> gdb.execute("info inferiors")

>>> # For automation, it might be useful to store the gdb command result to a variable:

>>> pidlist = gdb.execute("info pidlist", to_string=True)

Refence:

- https://sourceware.org/gdb/onlinedocs/gdb/Basic-Python.html#Basic-Python

post122239: Re: Python script to debug my binary using gdb on QNX OS

Jim Sleeth — Fri, 28 Apr 2023 16:03:11 GMT

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.

post122124: Python script to debug my binary using gdb on QNX OS

Preethi Selvaraju — Wed, 01 Feb 2023 04:21:42 GMT

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?

post121942: Anyone compile and use GDB native to QNX on 7.1?

Tyler Bernhardt(deleted) — Mon, 26 Sep 2022 17:31:37 GMT

I have been able to compile and create an executable for gdb-9.2 for qnx 7.1 running on x86_64 architecture and whenever it runs it does not segfault but it also does not run properly. It exits after not recognizing x86_64 qnx as a supported gdb architecture.

Does anyone have any insight on what may need to be done in order to add support for a new gdb architecture specific for qnx?

It looks like there are others trying to do a similar thing based on some other posts as well: https://community.qnx.com/sf/discussion/do/listPosts/projects.toolchain/discussion.core_development_tools.topc28211

post121941: Re: GDB Native On QNX OS 7.1

Jim P — Mon, 26 Sep 2022 14:21:57 GMT

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?

post121905: Re: GDB On QNX OS

John Kearney — Fri, 26 Aug 2022 17:18:10 GMT

may also want to use dumper, so you can do postmortem debugging.

http://www.qnx.com/developers/docs/7.1/#com.qnx.doc.neutrino.utilities/topic/d/dumper.html

post121903: Re: GDB On QNX OS

Jim Sleeth — Fri, 26 Aug 2022 11:18:21 GMT

For SDP7.1 only remote debugging is supported. To do this you run an application called pdebug on your target and you run gdb on your Windows host.

http://www.qnx.com/developers/docs/7.1/com.qnx.doc.neutrino.utilities/topic/p/pdebug.html

http://www.qnx.com/developers/docs/7.1/#com.qnx.doc.neutrino.utilities/topic/g/gdb.html

post121902: GDB On QNX OS

Preethi Selvaraju — Thu, 25 Aug 2022 04:00:56 GMT

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.

post121620: Re: Rust for QNX 7

Florian Bartels — Mon, 11 Oct 2021 14:37:38 GMT

Hi Jim,

thanks for the answer and details about libc. Do you think there is a chance of fixing the linking issues by adapting the linker parameters, or will there be deeper issues like ABI incompatibilities (assuming Rust code only; I'm sure we would get them when trying to link against C++ code).

I was afraid that there was no progress with Rust. Are there plans to support it any time soon?

Using Rust would help us to stay competitive when implementing complex applications.

Kind regards, Florian

post121619: Re: Rust for QNX 7

Jim Sleeth — Fri, 08 Oct 2021 20:10:36 GMT

Hi Florian

First, I know of no successful Rust on QNX/NTO.

However; your first try won't work as there are too many differences between glibc and the NTO libc.

Yes Linux does, depending on your distribution, provide a lot of POSIX API(s), but for instance the POSIX threads are in a separate library pthread library on Linux, but contained within the NTO libc. This is where many of your missing symbols may have come from, the differences between library contents.

Jim

post121615: Rust for QNX 7

Florian Bartels — Wed, 06 Oct 2021 18:39:45 GMT

Hi,

I'm interested to know if anybody tried to compile a Rust application for QNX? I wasn't able to find any information about this.

(Cross) Compiling for Linux but linking using qcc for QNX fails due to a lot of missing symbols (I hoped this would work as both Linux and QNX use POSIX APIs).

Thanks and kind regards

post121128: gcc 4.8.3 and binutils 2.25 + QNX650

Pavel Kopylov(deleted) — Fri, 27 Nov 2020 20:49:50 GMT

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.

post120155: Use GCC 4.8.1 for QNX6.4.1

Danny Yen(deleted) — Thu, 16 Jan 2020 18:23:55 GMT

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.

post120086: Re: RE: Looking for debug symbols of libstdc++.so.6

Roberto Alejandro Flores Estrada — Tue, 26 Nov 2019 14:47:21 GMT

Sorry forgot to mention it is for aarch64le architectue.

post120085: Re: RE: Looking for debug symbols of libstdc++.so.6

Roberto Alejandro Flores Estrada — Tue, 26 Nov 2019 14:46:13 GMT

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.

post120002: Where can i get the BSP for Raspberry Pi 3 board?

Dharani kumar Srinivasan(deleted) — Fri, 27 Sep 2019 11:24:47 GMT

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.

post119979: Thread Sanitizer

Aaron Husz — Tue, 24 Sep 2019 22:00:05 GMT

Hello,

Is there any support for the -fsanitize-thread flag for QNX 7.0? I tried to compile with the flag this afternoon, but it looks like libtsan might be missing. Is there a way to build the thread sanitizer library if it is missing or not officially supported?

Thanks,

Aaron

post119754: where i can find a guide to develop CAN bus driver

Chris Liang(deleted) — Tue, 11 Jun 2019 20:17:30 GMT

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.

post119753: Re: How to use just compiled gcc to build programs for a target (in Momentics)

fn ln(deleted) — Mon, 10 Jun 2019 22:39:57 GMT

> 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"

post119752: How to use just compiled gcc to build programs for a target (in Momentics)

fn ln(deleted) — Mon, 10 Jun 2019 21:08:16 GMT

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?

post119744: PCI program is crashing

Anand Shastry(deleted) — Fri, 07 Jun 2019 12:47:11 GMT

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 ()

post119734: Re: Building gcc 8 for QNX 6.6

fn ln(deleted) — Thu, 06 Jun 2019 20:27:43 GMT

*Can you run the new compiler with qcc?

post119733: Re: Building gcc 8 for QNX 6.6

fn ln(deleted) — Thu, 06 Jun 2019 20:26:29 GMT

Hi Kevin Stallard! Have you succeed with creating config files for qcc? Can you run the compiler with new qcc?

post119722: Re: RE: Qcc and spaces in arguments

Tom Rouillard(deleted) — Mon, 03 Jun 2019 08:42:56 GMT

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.

post119721: RE: Qcc and spaces in arguments

John Kearney — Fri, 31 May 2019 19:48:26 GMT

What version of qcc.
This works for me.
qcc -DTYPE="unsigned int" test.c

as a W/A you could try

qcc -Wc,-DTYPE="unsigned int" test.c
________________________________________
From: Tom Rouillard [community-noreply@qnx.com]
Sent: Wednesday, May 29, 2019 09:35
To: general-toolchain
Subject: Qcc and spaces in arguments

Hello,

I'm trying to manually invoke qcc with some -D options which has some spaces in it:
qcc -DTYPE="unsigned int" main.c

This works fine using gcc, but fails with the following message with qcc:
cc1: fatal error: "-DTYPE=unsigned int": Invalid argument

This is the same kind of error that appears when trying to use spaces in paths.
Am I missing something or is there a workaround?

Cheers,
Tom

_______________________________________________

General
http://community.qnx.com/sf/go/post119715
To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com

post119715: Qcc and spaces in arguments

Tom Rouillard(deleted) — Wed, 29 May 2019 07:35:06 GMT

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

post119586: Re: Integrating QNX toolchain into Bitbake/OpenEmbedded/Yocto as a foreign (external) tool-chain

bernardo araujo rodrigues(deleted) — Sat, 16 Mar 2019 17:48:12 GMT

hey this seems quite interesting.

any progress so far?

I'd love to contribute.

post119538: Re: Building gcc 8 for QNX 6.6

Kevin Stallard(deleted) — Sun, 24 Feb 2019 07:27:32 GMT

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.

post119537: Re: Uncertain header file inclusions in gcc build

Kevin Stallard(deleted) — Sun, 24 Feb 2019 06:55:52 GMT

I have a solution to this in my previous post for this problem and a myriad of others that I was having. Turns out there are headerfiles missing from the libstdc++-v3/include/c folder.

Thanks

Kevin

post119536: Re: Building gcc 8 for QNX 6.6

Kevin Stallard(deleted) — Sun, 24 Feb 2019 06:54:07 GMT

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.

post119535: Re: Uncertain header file inclusions in gcc build

Kevin Stallard(deleted) — Fri, 22 Feb 2019 10:12:53 GMT

Sure is quiet around here these days....

post119525: Uncertain header file inclusions in gcc build

Kevin Stallard(deleted) — Fri, 15 Feb 2019 19:32:30 GMT

This seems to apply for both the 660_release and the gcc_8_2 builds.

It appears gcc is being built correctly and the build process steps into building libstdc++-v3 libraries.  What appears to be happening is when cmath is being included, it is trying to include math.h.

Well, as you know there are numerous versions of math.h sprinkled about in the gcc_8_2 build directory, the /opt/qnx660/target/qnx6/user/include directory and the /usr/include directory of the host OS (linux in this case).

What I am trying to understand is which math.h should be included when this library is being built?  I suspect this also may apply to other header files found in the /opt/qnx660/target/qnx6/usr/include directory.

The build instructions as posted on this site appear to be incomplete.  I did modify the build_hooks file to ensure that it was using qnx660, but it seems there may be other things that need updating to get the proper math.h to be included with the build.

Any help, suggestions or any other direction is greatly appreciated.

Thank you!

Kevin

post119524: Re: Building gcc 8 for QNX 6.6

Kevin Stallard(deleted) — Fri, 15 Feb 2019 18:44:24 GMT

Clearly I am doing something wrong, but I am not sure what it is.

I tried building the 660_release and I am running into the same header file inclusion issues.

It seems that xgcc when building the libraries is also including the headers from the /usr/include directory of the qnx660 target, and that this is messing things up.

The question I need answered is: When building libstdc++-v3 using xgcc, should xgcc be including headers from the qnx660 installation or from some other source?

Thanks

Kevin

post119514: Re: Building gcc 8 for QNX 6.6

Kevin Stallard(deleted) — Wed, 13 Feb 2019 20:28:54 GMT

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....

post119513: Re: Building gcc 8 for QNX 6.6

Kevin Stallard(deleted) — Wed, 13 Feb 2019 19:30:41 GMT

I think I have this issue sorted, bin utils needed an update, now using 2.30.

However, there is one other issue I seem to be having. The include paths for building the gcc libraries is not including c_compatibility. This is preventing inclusions of header files such as math.h.

Any feed back on this is appreciated.

Thanks

Kevin

post119506: Building gcc 8 for QNX 6.6

Kevin Stallard(deleted) — Wed, 13 Feb 2019 07:15:32 GMT

Things seem to generally build well until I get to the point of building libgcc using xgcc. It tries to build unwind-dw2.c using position independent code and the assembler chokes on the resulting assembly file.

/tmp/cciOo4Io.s: Assembler messages:

/tmp/cciOo4Io.s:67: Error: invalid operands (.text and .text.unlikely sections) for `-'

/tmp/cciOo4Io.s:68: Error: invalid operands (.text and .text.unlikely sections) for `-'

/tmp/cciOo4Io.s:69: Error: invalid operands (.text and .text.unlikely sections) for `-'

/tmp/cciOo4Io.s:70: Error: invalid operands (.text and .text.unlikely sections) for `-'

/tmp/cciOo4Io.s:1566: Error: invalid operands (.text and .text.unlikely sections) for `-'

/tmp/cciOo4Io.s:1567: Error: invalid operands (.text and .text.unlikely sections) for `-'

/tmp/cciOo4Io.s:1568: Error: invalid operands (.text and .text.unlikely sections) for `-'

/tmp/cciOo4Io.s:1569: Error: invalid operands (.text and .text.unlikely sections) for `-'

/tmp/cciOo4Io.s:1570: Error: invalid operands (.text and .text.unlikely sections) for `-'

/tmp/cciOo4Io.s:1571: Error: invalid operands (.text and .text.unlikely sections) for `-'

/tmp/cciOo4Io.s:1572: Error: invalid operands (.text and .text.unlikely sections) for `-'

/tmp/cciOo4Io.s:1573: Error: invalid operands (.text and .text.unlikely sections) for `-'

/tmp/cciOo4Io.s:1574: Error: invalid operands (.text and .text.unlikely sections) for `-'

/tmp/cciOo4Io.s:1575: Error: invalid operands (.text and .text.unlikely sections) for `-'

/tmp/cciOo4Io.s:1576: Error: invalid operands (.text and .text.unlikely sections) for `-'

/tmp/cciOo4Io.s:1577: Error: invalid operands (.text and .text.unlikely sections) for `-'

/tmp/cciOo4Io.s:1578: Error: invalid operands (.text and .text.unlikely sections) for `-'

/tmp/cciOo4Io.s:1579: Error: invalid operands (.text and .text.unlikely sections) for `-'

/tmp/cciOo4Io.s:1580: Error: invalid operands (.text and .text.unlikely sections) for `-'

/tmp/cciOo4Io.s:1581: Error: invalid operands (.text and .text.unlikely sections) for `-'

/tmp/cciOo4Io.s:1582: Error: invalid operands (.text and .text.unlikely sections) for `-'

/tmp/cciOo4Io.s:1583: Error: invalid operands (.text and .text.unlikely sections) for `-'

/tmp/cciOo4Io.s:1584: Error: invalid operands (.text and .text.unlikely sections) for `-'

/tmp/cciOo4Io.s:1585: Error: invalid operands (.text and .text.unlikely sections) for `-'

/tmp/cciOo4Io.s:1586: Error: invalid operands (.text and .text.unlikely sections) for `-'

/tmp/cciOo4Io.s:1587: Error: invalid operands (.text and .text.unlikely sections) for `-'

Some of the lines in the resulting assembly that this errors out on are:

.long _GLOBAL_OFFSET_TABLE_+[.-.L7]

.long _GLOBAL_OFFSET_TABLE_+[.-.L18]

.long _GLOBAL_OFFSET_TABLE_+[.-.L12]

.long _GLOBAL_OFFSET_TABLE_+[.-.L7]

.long _GLOBAL_OFFSET_TABLE_+[.-.L5]

.long _GLOBAL_OFFSET_TABLE_+[.-.L4]

.long _GLOBAL_OFFSET_TABLE_+[.-.L4]

.long _GLOBAL_OFFSET_TABLE_+[.-.L4]

.long _GLOBAL_OFFSET_TABLE_+[.-.L4]

.long _GLOBAL_OFFSET_TABLE_+[.-.L19]

.long _GLOBAL_OFFSET_TABLE_+[.-.L8]

.long _GLOBAL_OFFSET_TABLE_+[.-.L7]

.long _GLOBAL_OFFSET_TABLE_+[.-.L5]

Ideas?

Thanks

Kevin

post119375: What is the POSIX version of QNX SDP 7.0

Vijay Chinimilli — Thu, 27 Dec 2018 10:24:00 GMT

Hi

What is the POSIX version of QNX SDP 7.0.

When I try to compile some of the open source projects like Flutter, Boring SSL etc using QNX Tool chain some of the POSIX API's are not visible to the compiler though the header files are included.

For ex:

File operations like open,read,

Some of the thread Interfaces like pthread_rwlock_t are not visible to the compiler, when I open the pthread.h from QNX SDK the structure is defined under POSIX version Macro, EXT_POSIX_200112 and other interfaces are defined under different POSIX version macros.

Observed similar kind of declarations in signal.h as well.

If I try to enable the macro the compiler ends up in error message saying Posix threads need 1003.1b 1993 or later.

I would like to know what is the POSIX version supported by QNX 7.0 and How to access such API's declared under old POSIX version MACROS.

Regards,

Vijay

post119371: RE: Clang support inn QNX

John Kearney — Wed, 19 Dec 2018 12:57:57 GMT

Not officially, some work was done to support it, but we don't provide a toolchain for it or support it.

so you will find __clang in some of our public headers.
e.g.
${QNX_TARGET}/usr/include/_packpop.h:27: #if defined(__PRAGMA_PACK_PUSH_POP__) || defined(__clang__)

________________________________________
From: Vijay Chinimilli [community-noreply@qnx.com]
Sent: Wednesday, December 19, 2018 13:42
To: general-toolchain
Subject: Clang support inn QNX

Hello,
Is there any support of clang in QNX?

_______________________________________________

General
http://community.qnx.com/sf/go/post119370
To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com

post119370: Clang support inn QNX

Vijay Chinimilli — Wed, 19 Dec 2018 12:42:47 GMT

Hello,

Is there any support of clang in QNX?

post119120: Re: GCC 4.8.3 instalation

Elena Laskavaia — Mon, 17 Sep 2018 17:53:52 GMT

Why did you do that?

4) Renamed /opt/qnx650sp1-gcc483/host/linux/x86/etc/qcc/gcc/4.4.2 to /opt/qnx650sp1-gcc483/host/linux/x86/etc/qcc/gcc/4.8.3

?

There are configuration file in /etc folder that point to default versions of compilers and stuff, if you rename the file it will will brake these files. IDE uses these to find the right compiler.

Also if get new gcc it should be in the same host folder at the other one or you have to edit QNX_HOST var for IDE and command line

post119098: Re: GCC 4.8.3 instalation

Vasilij Yanikeev(deleted) — Fri, 14 Sep 2018 05:41:43 GMT

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.

post119097: Re: GCC 4.8.3 instalation

Vasilij Yanikeev(deleted) — Fri, 14 Sep 2018 05:41:42 GMT

post119096: Re: GCC 4.8.3 instalation

Vasilij Yanikeev(deleted) — Fri, 14 Sep 2018 05:41:41 GMT

post119095: Re: GCC 4.8.3 instalation

Bob Powell — Thu, 13 Sep 2018 15:49:54 GMT

Hi Vasilij,

It appears you have downloaded the tools for running on "self-hosted" NTO systems.

Please try the linux-gcc-4.8.3-qnx65x.tar.gz archive which contains

host\linux\x86\

Cheers,

Bob

post119094: GCC 4.8.3 instalation

Vasilij Yanikeev(deleted) — Thu, 13 Sep 2018 11:00:39 GMT

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?

post119093: GCC 4.8.3 instalation

Vasilij Yanikeev(deleted) — Thu, 13 Sep 2018 11:00:38 GMT

post119092: GCC 4.8.3 instalation

Vasilij Yanikeev(deleted) — Thu, 13 Sep 2018 11:00:36 GMT

post119043: Re: "Resource busy" error when try to collect tracelog

Steve Reid(deleted) — Wed, 08 Aug 2018 17:32:00 GMT

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.

post119042: Re: "Resource busy" error when try to collect tracelog

Ovidiu Zaharia — Wed, 08 Aug 2018 14:42:58 GMT

Hello all,

Is there nobody who can tell why the message

# tracelogger: tracelog_acquire: Resource busy #

is coming when trying to start the trace logger.using the command

# tracelogger -d1 -n 10 -f /root/data/all_classes.kev #

I suspect that a previous attempt to start the tracelogger failed but the access to the file (specified with -f) was not properly terminated.

Is there anyone who can confirm the above and / or suggest a way to solve this without having to restart the whole system?

Is there a way to terminate the tracelog_acquire session?

Regards

OZ

post118843: Re: Is there an easy way to print compiler information during a make?

Jim Sleeth — Wed, 23 May 2018 16:35:30 GMT

binscan link should be working if your maintenance contract is setup correctly.

qscan is an optional package through the QNX Software Center on SDP7.

post118842: Re: Is there an easy way to print compiler information during a make?

Eric Fossum(deleted) — Tue, 22 May 2018 22:02:08 GMT

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?

post118837: Re: Is there an easy way to print compiler information during a make?

Jim Sleeth — Sat, 19 May 2018 21:59:39 GMT

did you try http://community.qnx.com/sf/wiki/do/viewPage/projects.customer_ast_services/wiki/ToolsPage

For SDP7 there is also qscan.

post118820: QNX 6.6.0 with GCC 4.9.3 Requires Path?

Kevin Smith(deleted) — Wed, 16 May 2018 20:35:21 GMT

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?

post118815: Is there an easy way to print compiler information during a make?

Eric Fossum(deleted) — Tue, 15 May 2018 18:10:42 GMT

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?

post118786: Re: CLANG QNX650

Ivo Petkovic(deleted) — Tue, 24 Apr 2018 06:44:19 GMT

Thanks! It looks fairly easy. I would need this for clang (llvm actually) 5.0. I suppose the effort is similar to this one?

post118749: Re: CLANG QNX650

Mario Charest — Mon, 09 Apr 2018 13:31:25 GMT

Attached are the diff from todays clang trunk (7.0)

What I have not been able to build yet is libcxx

I used this cmake command to setup the project ( using Ninja )

cmake -G"Ninja" \

-DLLVM_TARGETS_TO_BUILD=X86 \

-DCMAKE_BUILD_TYPE=Release \

-DLLVM_DEFAULT_TARGET_TRIPLE=i386-pc-qnx650-gnu \

-DCOMPILER_RT_INCLUDE_TESTS=OFF \

-DLLVM_ENABLE_ASSERTIONS=OFF \

-DLLVM_ENABLE_LTO=ON \

-DLLVM_ENABLE_ZLIB=ON \

-DLLVM_BUILD_TEST=OFF \

-DLLVM_INCLUDE_TESTS=OFF \

-DLLVM_USE_LINKER=gold \

-DLLVM_ENABLE_WARNINGS=OFF \

../trunk

post118748: Re: CLANG QNX650

Ivo Petkovic(deleted) — Mon, 09 Apr 2018 07:39:20 GMT

Hi Mario,

Could you share the patches for clang?

post118420: Re: QNX 7/Momentics 4.7 C linker error: VFP Register arguments

Chris Buck(deleted) — Mon, 22 Jan 2018 13:56:22 GMT

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 :)

post118405: QNX 7/Momentics 4.7 C linker error: VFP Register arguments

Chris Buck(deleted) — Thu, 18 Jan 2018 22:27:16 GMT

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!

post118247: How can i rebase the QNX provided msys-1.0 dll

manas sahoo — Wed, 29 Nov 2017 08:50:01 GMT

Hi,

In Win 7 X64 machine, i am seeing the QNX compilation to fail due to the below error. Can i rebase the msys dll, so that the below error goes away? Please let me know the steps.

C:\QNX650\host\win32\x86\usr\bin\ksh.exe: *** fork: can't reserve memory for stack 0xA0000 - 0x2A0000, Win32 error 0

31075038 [main] ksh 8152 sync_with_child: child 23508(0x224) died before initialization with status code 0x1

31075609 [main] ksh 8152 sync_with_child: *** child state waiting for longjmp

C:/QNX650/host/win32/x86/usr/bin/qnx_cp[81]: cannot fork - try again

Regards,

Manas

post118198: uncaught_exception doesn't work with Dinkumware

Niklas Angare — Mon, 13 Nov 2017 19:30:31 GMT

The std::uncaught_exception() function seems to always return 0 when using the Dinkumware library on QNX 6.6.0. Attaching a code example from http://en.cppreference.com/w/cpp/error/uncaught_exception.

When compiled with the default Dinkumware library:

qcc -o uncaught_exception_test2.o "..\\uncaught_exception_test2.cpp" -V4.7.3,gcc_ntoarmv7le -w1 -c -O0 -g

qcc -o uncaught_exception_test2 uncaught_exception_test2.o -V4.7.3,gcc_ntoarmv7le -w1 -lang-c++ -g

The results are wrong:

Exception thrown

~Foo() called normally

Exception caught: test exception

~Foo() called normally

The problem exists on both x86 and armv7.

When compiled with GNU libstdc++:

qcc -o uncaught_exception_test2.o "..\\uncaught_exception_test2.cpp" -V4.7.3,gcc_ntoarmv7le_gpp -w1 -c -O0 -g

qcc -o uncaught_exception_test2 uncaught_exception_test2.o -V4.7.3,gcc_ntoarmv7le_gpp -w1 -lang-c++ -g

The results are correct:

Exception thrown

~Foo() called during stack unwinding

Exception caught: test exception

~Foo() called normally

post118192: CLANG QNX650

Mario Charest — Sat, 11 Nov 2017 00:28:39 GMT

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.

post118163: Re: linux-gcc-4.9.3-qnx660.tar.gz needs a qcc update

Kevin Stallard(deleted) — Tue, 31 Oct 2017 04:20:47 GMT

Just figured out that it was qcc complaining.

So I second the request, is there an updated qcc that will support these options (lto_cc, lto_support, lto_opt)?

Thanks

post118162: Re: "Ignoring unknown option" output when using 4.9,3 compiler

Kevin Stallard(deleted) — Tue, 31 Oct 2017 03:44:35 GMT

I second this request, moving to 4.9.3 is spitting out cc: ignoring unknown option 'lto_cc' (as well as others)?

Thanks

Kevin

post118151: Making nand memory (etfs filesystem) noexec

Dimitar Slavchev — Thu, 26 Oct 2017 13:32:38 GMT

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?

post118147: Re: hidden symbol `_Unwind_Resume' error with GCC 4.9.3 and QNX SDP 6.6.0

Raju A(deleted) — Wed, 25 Oct 2017 14:39:10 GMT

Hello,

I am working with QNX Momentics on Windows and using QNX SDP 7.0.0 and GCC 5.4.0. I am facing the same problem with the new GCC available here. Can you please help me in solving this error ?

Following is the error:

C:\tools\sdp\qnx700\host\win64\x86_64\usr\bin\i586-pc-nto-qnx7.0.0-ld: hcu: hidden symbol `_Unwind_Resume' in C:/tools/sdp/qnx700/host/win64/x86_64/usr/lib/gcc/i586-pc-nto-qnx7.0.0/5.4.0/pic/libgcc.a(unwind-dw2.o) is referenced by DSO

C:\tools\sdp\qnx700\host\win64\x86_64\usr\bin\i586-pc-nto-qnx7.0.0-ld: final link failed: Bad value

cc: C:/tools/sdp/qnx700/host/win64/x86_64/usr/bin/i586-pc-nto-qnx7.0.0-ld caught signal 1

Thanks,

Raju

post118089: Re: gdb disconnects from Armv7 target (AM335) on break point hit

Elena Laskavaia — Fri, 29 Sep 2017 17:10:01 GMT

Sorry kind of late to reply but this is gdb patch for stack issues (if using with IDE)

http://community.qnx.com/sf/frs/do/viewRelease/projects.toolchain/frs.gdb.gdb_7_6_r942_sdp6_6_0

post118022: Re: GOLD linker for QNX

Mario Charest — Fri, 08 Sep 2017 04:12:41 GMT

> Attached is a Linux x86_64 hosted bfd and gold ld for 6.5.0SP1. Let me know if

> you have any problems.

>

Hi,

Any hope of getting the lto 64 bit plugin, that goes along with gold ld ?

> Regards,

>

> Ryan Mansfield

post118018: QNX developper

Farshid Shadpey(deleted) — Wed, 06 Sep 2017 20:52:00 GMT

Hi,

I am working at Bombardier Aerospace. I am looking for Marion Charest a QNX developer who helped us with developing a QNX based system between 2000 to 2001. We have lost contact with him since then. I would like to get in touch with him for a potentil new development. I appreciate if anybody can help by passing the news to him.

Thanks

Farshid Shadpey

farshid.shadpey@aero.bombardier.com

post118017: qcc with higher gcc version

Martin Knotek(deleted) — Wed, 06 Sep 2017 11:19:51 GMT

Hello,

for my project, I need to run at least gcc version 6.2. In the QNX 7.0 there is gcc version 5.4.

Is there a way how to get a higher version?

Thank you

post117947: "Ignoring unknown option" output when using 4.9,3 compiler

Rodney Dowdall(deleted) — Tue, 08 Aug 2017 14:55:21 GMT

Hello

I am using the 4.9.3 GCC compiler on QNX 6.6.0.  I am getting the following out on every C++ file that I compile:

cc: ignoring unknown option 'lto_support'

cc: ignoring unknown option 'lto_opt'

cc: ignoring unknown option 'lto_cc'

cc: ignoring unknown option 'lto_support'

cc: ignoring unknown option 'lto_opt'

cc: ignoring unknown option 'lto_cc'

Is there a way to disable this?

Thanks,

Rodney

post117797: gdb disconnects from Armv7 target (AM335) on break point hit

Kevin Stallard(deleted) — Mon, 19 Jun 2017 23:46:50 GMT

Hi,

I am trying to debug an application that uses a thread pool. As long as the application is single threaded, debugging is great. Also, just noticed that if I use the flag POOL_FLAG_USE_SELF instead of POOL_FLAG_EXIT_SELF I also get good results. The stack doesn't show up when a break point is hit, but at least I can single step. Eventually the stack trace as well as the threads that are running show up as well, but not at the start.

So it has something to do with ripping the initial startup thread away from the debugger. It clearly has issues with that kind of behavior on my part.

BTW: I am using gdb version: GNU gdb (GDB) 7.6.1 qnx (rev. 863)

The target is a QNX 6.5 sp1 Arm v7

Anyway, we are moving forward again, but wanted to toss this in the mix...

Thanks

Kevin

post117737: RE: Looking for debug symbols of libstdc++.so.6

Max Feil — Tue, 16 May 2017 17:12:53 GMT

You'll need to specify the version of the library. The libstdc++.so.6 file is just a symbolic link that points to the actual versioned library, for example libstdc++.so.6.0.19.

-----Original Message-----

From: Claudia Choi [mailto:community-noreply@qnx.com]

Sent: Wednesday, May 10, 2017 4:33 PM

To: general-toolchain

Subject: Looking for debug symbols of libstdc++.so.6

I am looking for debug symbols for libstdc++.so.6 for ARMLE-V7 target. Anyone knows where I can download them?

_______________________________________________

General

http://community.qnx.com/sf/go/post117725

To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com

post117725: Looking for debug symbols of libstdc++.so.6

Claudia Choi — Wed, 10 May 2017 20:32:40 GMT

I am looking for debug symbols for libstdc++.so.6 for ARMLE-V7 target. Anyone knows where I can download them?

post117282: Mudflap Launch Error: executable must have DT_BIND_NOW or environment variable LD_BIND_NOW must be set

Murugaiyan Perumal(deleted) — Thu, 15 Dec 2016 09:51:52 GMT

Hi,I'm trying to run my application after enabled the mudflap tools. When I launch the binary from IDE, I got below error.

ldd:FATAL: Could not use _dl_alloc. We are either out of memory or application overrides this symbol and returns NULL. In that case, executable must have DT_BIND_NOW or environment variable LD_BIND_NOW must be set I tried to enable the LD_BIND_NOW to non zero(1) environment variable and re-launch the application, now I ended up with below error. ldd:FATAL: unable to create dlerror() key (Not enough memory) My application was using open source library ssl and crypto. Due to this error, I'm not able to run my application using mudflap tool.

Platform: x86Neutrino OS: 6.5IDE: 4.7.0

However, I am able to launch the other applications successfully using mudflap. But the successful application is not using any using any ssl and crypto library.

Thanks,Murugaiyan

post117092: Re: Building GCC

Michael Daniels — Mon, 07 Nov 2016 18:46:38 GMT

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.

post117032: Re: Building GCC

Alexey Smirnov(deleted) — Sun, 30 Oct 2016 07:33:01 GMT

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 :))

post116967: linux-gcc-4.9.3-qnx660.tar.gz needs a qcc update

Oleh Derevenko — Wed, 12 Oct 2016 21:14:57 GMT

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'

post116943: Missing options for mkqnx6fsimg

Sanna Haraginadoni(deleted) — Wed, 05 Oct 2016 17:32:09 GMT

Hi,

I am creating a image for the qnx 6 file system.

mkqnx6fsimg does not support the script attribute unlike the buildfile for mkifs, so what alternative do I have?

Thanks,

Sanna

post116932: Re: RE: New Guy here

Matthew Johnston(deleted) — Fri, 30 Sep 2016 16:08:59 GMT

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?

post116924: RE: New Guy here

Mario Charest — Fri, 30 Sep 2016 12:59:58 GMT

It actually did ;-)  The program ran on the target, its output piped to Momentics.  To see it on the VM command line interface you need to start the application manually from there and then attach the debugger to it. You can start the application with on -h so that it starts in help mode, that way when you attach the debugger to it, no code has run.

Maybe its possible to start an app from Momentic and redirects its input/output to a console (/dev/con1) but never done that myself.

QNX 6.6.0 is a strange beast. It's like trying to do cooking but instead of starting from nice ingredients and recipes, you are given seeds to first grow stuff you need, embryonic stuff to "grow" meat and then a book on chemical reaction to figure out all to mix it all.  The outcome can be very personalized, original and tasty, but it's not easy to get there.

I'm sorry I don't have any pointer to give you, maybe look at the Car stuff, but not sure it's available in the basic kit.

My perception is that QNX 6.6.0 was rushed out to please a certain market (notice that I did not say markets ) at the cost of making it harder for other.  Life is full of compromise ;-)

-----Message d'origine-----

De : Matthew Johnston [mailto:community-noreply@qnx.com]

Envoyé : 30 septembre 2016 08:34

À : general-toolchain <general-toolchain@community.qnx.com>

Objet : New Guy here

Hey, I just joined Foundry 27 and I'm trying out the QNX evaluation kit. I'm totally confused as to what to do next. I'm looking to emulate something along the lines of a car infotainment system or just get apps/bluetooth/internet browser running on my target QNX 6.6 Neutrino VM.

So far I followed the tutorial on creating a Hello world C/C++ project and linking it to my target. The output of my debug session just said Hello World on my momentics IDE. I was hoping it would open a pipe into the VM target and print it out on the VM command line interface. It didn't.

How would I get a more funciton RTOS running on the VM? It is way too bare bones now. Can't really do anything with it.

_______________________________________________

General

http://community.qnx.com/sf/go/post116923

To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com

post116923: New Guy here

Matthew Johnston(deleted) — Fri, 30 Sep 2016 12:33:30 GMT

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.

post116878: Re: about Intel Thread Building Block support on QNX

lei xing(deleted) — Sat, 24 Sep 2016 18:17:04 GMT

> On Sep 24, 2016, at 10:55 AM, Lei Xing <leixing2@gmail.com> wrote:

>

> Hi Everyone,

>   I am a new comer to the qnx community. I encounter one issue and hope to get help from the community.

>  When I build the Intel TBB in the qnx, I get the error that no platform function has been defined or declared, for example __TBB_Yield and so on.

>  I know the Intel TBB does not support QNX, but does anyone have a patch so that I can build it successfully? Could you send it to me?

>

>

> Thank you !!

>

> Best

> Lei

post116876: Re: Query in qnx

Ramanna M(deleted) — Sat, 24 Sep 2016 13:19:39 GMT

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

>

post116875: Re: Query in qnx

Michael Daniels — Sat, 24 Sep 2016 12:41:36 GMT

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.

post116874: Query in qnx

Ramanna M(deleted) — Sat, 24 Sep 2016 07:59:35 GMT

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.

post116812: Behaviour conflict with api screen_create_context(&screen_ctx, SCREEN_APPLICATION_CONTEXT);

Rupali Kotgire(deleted) — Mon, 19 Sep 2016 10:06:21 GMT

Hi experts,

Basically I need to take a screenshot from the QNX board. When I refer the program given on qnx site at :

http://www.qnx.com/developers/docs/660/index.jsp?topic=/com.qnx.doc.screen/topic/manual/cscreen_screenshot_disp_sample.html

I am able to get the screenshot, but in this program screen_create_context uses SCREEN_DISPLAY_MANAGER_CONTEXT., which obviously needs a root permission.

Whereas in my actual program I won't be a root user,but still i need to take a screenshot. For this i referred program at: http://www.qnx.com/developers/docs/660/index.jsp?topic=%2Fcom.qnx.doc.screen%2Ftopic%2Fmanual%2Fcscreen_screenshot_win_sample.html

Here it uses context as screen_create_context(&screen_ctx, SCREEN_APPLICATION_CONTEXT); but the screenshot is blank, with just a black image that I am not supposed to get.

Please let me know if there is an alternate way to do it !!!!!

Thanks in advance,

Rupali

post116664: Re: GCC 4.8.3 doesn't recognize C++11 mathematics functions

Michael Daniels — Wed, 17 Aug 2016 11:39:07 GMT

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); }

post116663: GCC 4.8.3 doesn't recognize C++11 mathematics functions

Denis Kimcherenko(deleted) — Wed, 17 Aug 2016 10:42:54 GMT

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?

post116661: Re: 4.8.3 (QNX650) and new to_string(), stoi() ...

Denis Kimcherenko(deleted) — Wed, 17 Aug 2016 07:52:36 GMT

See the solution in http://community.qnx.com/sf/discussion/do/listPosts/projects.toolchain/discussion.core_development_tools.topc26761?_pagenum=4

post116660: Re: GCC nor 4.8.3 neither 4.9.3 doesn't support to_string C++11 feature

Denis Kimcherenko(deleted) — Wed, 17 Aug 2016 07:51:00 GMT

Thanks. it works.

Just for other users, I put the attached header into <QNX_SDK_HOME>/target/qnx6/usr/include/c++/4.8.3/custom

post116658: Re: GCC nor 4.8.3 neither 4.9.3 doesn't support to_string C++11 feature

Mario Charest — Tue, 16 Aug 2016 17:12:24 GMT

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.

post116657: Re: GCC nor 4.8.3 neither 4.9.3 doesn't support to_string C++11 feature

Denis Kimcherenko(deleted) — Tue, 16 Aug 2016 16:10:36 GMT

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'

post116656: Re: GCC nor 4.8.3 neither 4.9.3 doesn't support to_string C++11 feature

Michael Daniels — Tue, 16 Aug 2016 15:52:50 GMT

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.

post116653: GCC nor 4.8.3 neither 4.9.3 doesn't support to_string C++11 feature

Denis Kimcherenko(deleted) — Mon, 15 Aug 2016 11:07:33 GMT

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?

post116652: Re: 4.8.3 (QNX650) and new to_string(), stoi() ...

Denis Kimcherenko(deleted) — Mon, 15 Aug 2016 10:51:53 GMT

Hi guys,

Did someone find a solution how to use to_string ?

post116629: Re: Building GCC

Mario Charest — Wed, 03 Aug 2016 13:32:14 GMT

> 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 ;-)

post116628: Re: Building GCC

Michael Daniels — Tue, 02 Aug 2016 21:53:31 GMT

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.

post116627: Re: Building GCC

Mario Charest — Tue, 02 Aug 2016 21:22:52 GMT

> For the most part, yes, there are some minor things you might run into, but

> should be pretty obvious once you hit them.

>

> 1) You may need to change the SDP version, as you found out already.

- Done

> 2) You may need to update 'basedir' for linux hosted cross compilers as it

> won't install into QNX_HOST like the other hosts.

Will do,.

> 3) You may need updated versions of GCC's prerequisites. GCC source includes a

>  script to grab them (./contrib/download_prerequisites), or we have recent

> versions in the source tree.

Forgot to mention it but I did that already.

First time I run it, it stops at:

mkdir 32

configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.

The second time it failes with :

make "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CFLAGS=-O2" "CXXFLAGS=-g -O2" "CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-g -O2" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS=-static-libstdc++ -static-libgcc -Wl,-s " "LIBCFLAGS=-O2" "LIBCFLAGS_FOR_TARGET=-g -O2" "MAKE=make" "MAKEINFO=/home2/neon-vendor/qnxgcc/gcc_4_8_branch/missing makeinfo --split-size=5000000 --split-size=5000000 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/bash" "EXPECT=expect" "RUNTEST=runtest" "RUNTESTFLAGS=" "exec_prefix=/opt/qnx650/host/linux/x86/usr" "infodir=/opt/qnx650/host/linux/x86/usr/share/info" "libdir=/opt/qnx650/host/linux/x86/usr/lib" "prefix=/opt/qnx650/host/linux/x86/usr" "tooldir=/opt/qnx650/host/linux/x86/usr/i486-pc-nto-qnx6.5.0" "AR=ar" "AS=as" "CC=gcc" "CXX=g++" "LD=ld" "LIBCFLAGS=-O2" "NM=nm" "PICFLAG=" "RANLIB=ranlib" "DESTDIR=" DO=all multi-do # make

make[4]: Entering directory `/home2/neon-vendor/qnxgcc/gcc_4_8_branch/linux-x86-o-ntox86/zlib'

if [ -z "32 x32" ]; then \

  true; \

else \

  rootpre=`${PWDCMD-pwd}`/; export rootpre; \

  srcrootpre=`cd ../../zlib; ${PWDCMD-pwd}`/; export srcrootpre; \

  lib=`echo "${rootpre}" | sed -e 's,^.*/$[^/][^/]*$/$,\1,'`; \

  compiler="gcc"; \

  for i in `${compiler} --print-multi-lib 2>/dev/null`; do \

    dir=`echo $i | sed -e 's/;.*$//'`; \

    if [ "${dir}" = "." ]; then \

      true; \

    else \

      if [ -d ../${dir}/${lib} ]; then \

flags=`echo $i | sed -e 's/^[^;]*;//' -e 's/@/ -/g'`; \

if (cd ../${dir}/${lib}; make  \

CFLAGS="-O2 ${flags}" \

CCASFLAGS=" ${flags}" \

FCFLAGS=" ${flags}" \

FFLAGS=" ${flags}" \

ADAFLAGS=" ${flags}" \

prefix="/opt/qnx650/host/linux/x86/usr" \

exec_prefix="/opt/qnx650/host/linux/x86/usr" \

GCJFLAGS=" ${flags}" \

GOCFLAGS=" ${flags}" \

CXXFLAGS="-g -O2 ${flags}" \

LIBCFLAGS="-O2 ${flags}" \

LIBCXXFLAGS="-g -O2 -fno-implicit-templates ${flags}" \

LDFLAGS="-static-libstdc++ -static-libgcc -Wl,-s  ${flags}" \

MULTIFLAGS="${flags}" \

DESTDIR="" \

INSTALL="/usr/bin/install -c" \

INSTALL_DATA="/usr/bin/install -c -m 644" \

INSTALL_PROGRAM="/usr/bin/install -c" \

INSTALL_SCRIPT="/usr/bin/install -c" \

all); then \

  true; \

else \

  exit 1; \

fi; \

      else true; \

      fi; \

    fi; \

  done; \

fi

make[5]: Entering directory `/home2/neon-vendor/qnxgcc/gcc_4_8_branch/linux-x86-o-ntox86/32/zlib'

make[5]: *** No rule to make target `all'.  Stop.

make[5]: Leaving directory `/home2/neon-vendor/qnxgcc/gcc_4_8_branch/linux-x86-o-ntox86/32/zlib'

make[4]: *** [multi-do] Error 1

make[4]: Leaving directory `/home2/neon-vendor/qnxgcc/gcc_4_8_branch/linux-x86-o-ntox86/zlib'

make[3]: *** [all-multi] Error 2

make[3]: Leaving directory `/home2/neon-vendor/qnxgcc/gcc_4_8_branch/linux-x86-o-ntox86/zlib'

make[2]: *** [all-zlib] Error 2

make[2]: Leaving directory `/home2/neon-vendor/qnxgcc/gcc_4_8_branch/linux-x86-o-ntox86'

make[1]: *** [all] Error 2

make[1]: Leaving directory `/home2/neon-vendor/qnxgcc/gcc_4_8_branch/linux-x86-o-ntox86'

make: *** [all] Error 2

post116626: Re: Building GCC

Michael Daniels — Tue, 02 Aug 2016 21:12:17 GMT

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.

post116625: Building GCC

Mario Charest — Tue, 02 Aug 2016 20:24:53 GMT

Are the instruction for building gcc found on the wiki still valid (http://community.qnx.com/sf/wiki/do/viewPage/projects.toolchain/wiki/Resources_GCC)

I had to edit build_hooks to replace reference to 8.0.0 for 6.5.0 but I'm still having strange issues. Wanted to check if it should work as per the instruction before diving into this.

- Mario

post116514: RE: hidden symbol `_Unwind_Resume' error with GCC 4.9.3 and QNX SDP 6.6.0

Mario Charest — Mon, 04 Jul 2016 15:40:52 GMT

Oh my bad I was looking at the creation date instead of last modified.

Thanks.

-----Message d'origine-----

De : Michael Daniels [mailto:community-noreply@qnx.com]

Envoyé : 4 juillet 2016 11:39

À : general-toolchain <general-toolchain@community.qnx.com>

Objet : Re: hidden symbol `_Unwind_Resume' error with GCC 4.9.3 and QNX SDP 6.6.0

Yup, updated the packages in the File Releases section:

http://community.qnx.com/sf/frs/do/viewRelease/projects.toolchain/frs.gcc.gcc_4_8

http://community.qnx.com/sf/frs/do/viewRelease/projects.toolchain/frs.gcc.gcc_4_9

_______________________________________________

General

http://community.qnx.com/sf/go/post116513

To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com

post116513: Re: hidden symbol `_Unwind_Resume' error with GCC 4.9.3 and QNX SDP 6.6.0

Michael Daniels — Mon, 04 Jul 2016 15:39:02 GMT

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

post116512: Re: hidden symbol `_Unwind_Resume' error with GCC 4.9.3 and QNX SDP 6.6.0

Mario Charest — Mon, 04 Jul 2016 13:29:46 GMT

> For what it's worth, the 4.8 and 4.9 packages have been updated.

Updated as in available somewhere for download ?

post116511: Re: hidden symbol `_Unwind_Resume' error with GCC 4.9.3 and QNX SDP 6.6.0

Michael Daniels — Mon, 04 Jul 2016 11:38:27 GMT

For what it's worth, the 4.8 and 4.9 packages have been updated.

post116488: Re: hidden symbol `_Unwind_Resume' error with GCC 4.9.3 and QNX SDP 6.6.0

Michael Daniels — Mon, 27 Jun 2016 13:53:16 GMT

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.

post116487: Re: hidden symbol `_Unwind_Resume' error with GCC 4.9.3 and QNX SDP 6.6.0

e zhong(deleted) — Mon, 27 Jun 2016 13:43:34 GMT

Ok I find out one difference on c++11 support between GCC 4.9 and 4.8 is <regex>.

post116486: Re: hidden symbol `_Unwind_Resume' error with GCC 4.9.3 and QNX SDP 6.6.0

e zhong(deleted) — Sun, 26 Jun 2016 03:05:50 GMT

Thank you Michael. Yes gcc4.8.3 works for me.

As I know gcc4.8.3 is not different to gcc4.9.3 regarding c++11 support. Is that correct?

Eric

post116483: Re: hidden symbol `_Unwind_Resume' error with GCC 4.9.3 and QNX SDP 6.6.0

Michael Daniels — Fri, 24 Jun 2016 20:22:38 GMT

This was fixed recently and is available in the 4.8.3 packages. The 4.9.3 packages have not yet been updated.

post116482: hidden symbol `_Unwind_Resume' error with GCC 4.9.3 and QNX SDP 6.6.0

e zhong(deleted) — Fri, 24 Jun 2016 20:14:00 GMT

HI Everyone,

I am trying to upgrade gcc in QNX 6.6.0 from 4.7.3 to 4.9.3. I downloaded the GCC and Binutils packages from

http://community.qnx.com/sf/frs/do/viewSummary/projects.toolchain/frs

I deployed the packages by copying files into qnx6.6.0's 'host' and 'target' folders, and setting compiler version 4.9.3 in C:\qnx660\host\win32\x86\etc\qcc\gcc\default.

Then when I tried to rebuild my application in Qt Creator I got an error as below -

C:\qnx660\host\win32\x86\usr\bin\i486-pc-nto-qnx6.6.0-ld: ../../bin/x86/Release/sxm17_app: hidden symbol `_Unwind_Resume' in C:/qnx660/host/win32/x86/usr/lib/gcc/i486-pc-nto-qnx6.6.0/4.9.3/libgcc.a(unwind-dw2.o) is referenced by DSO

C:\qnx660\host\win32\x86\usr\bin\i486-pc-nto-qnx6.6.0-ld: final link failed: Bad value

cc: C:/qnx660/host/win32/x86/usr/bin/i486-pc-nto-qnx6.6.0-ld caught signal 1

make[1]: *** [../../bin/x86/Release/sxm17_app] Error 1

Any idea what problem it might be and how to fix?

In my experiment I did see that if I replace the new libgcc.a with the old 4.7.3 version then the error goes away. But is it a good workaround or unsafe?

Thanks!

Eric

post116354: Re: Include doesn't compile with QNX 6.6 QCC and c++11

Will Miles — Fri, 27 May 2016 18:20:02 GMT

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

>

post116353: Re: Include doesn't compile with QNX 6.6 QCC and c++11

Michael Daniels — Fri, 27 May 2016 15:19:46 GMT

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.

post116346: Re: Include doesn't compile with QNX 6.6 QCC and c++11

Anton Indrawan(deleted) — Thu, 26 May 2016 20:15:45 GMT

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.

post116343: Re: Include doesn't compile with QNX 6.6 QCC and c++11

Alexander Fagrell(deleted) — Thu, 26 May 2016 11:40:18 GMT

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...

post116337: Re: Include doesn't compile with QNX 6.6 QCC and c++11

Michael Daniels — Wed, 25 May 2016 16:12:38 GMT

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.

post116332: Re: Include doesn't compile with QNX 6.6 QCC and c++11

Alexander Fagrell(deleted) — Wed, 25 May 2016 13:56:05 GMT

Thanks!

I can now "successfully" build the boost libraries. The reason I put the successfully in quotations is because some of the libraries doesn't seems to function as expected. When dynamically linking to for example the unit_test_framework, its fine to build, but when I run the app I get a "Library cannot be found".

Checking for dependency on for example /libboost_unit_test_framework.so (using ldd) results in:

libboost_unit_test_framework.so => /home/alex/qnx/660/bin/boost/libboost_unit_test_framework-qcc-mt-1_60.so.1.60.0 (0xb8200000)

ldd: Library cannot be found

It doesn't event say which library that couldn't be found... ?

I've cross-compiled boost using qcc 4.7.3.

Any thoughts? Thanks

post116307: Re: Include doesn't compile with QNX 6.6 QCC and c++11

Michael Daniels — Thu, 19 May 2016 16:17:39 GMT

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.

post116305: Re: Include doesn't compile with QNX 6.6 QCC and c++11

Alexander Fagrell(deleted) — Thu, 19 May 2016 16:01:15 GMT

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.

post116179: Re: python2.7 (gdb-prereq): missing _scruct module

Igor Rondarev(deleted) — Wed, 27 Apr 2016 12:31:40 GMT

Sorry, i've tested win32 gdb/prereq again, and they work fine, so there's no need to update.

post116135: Re: python2.7 (gdb-prereq): missing _scruct module

Michael Daniels — Sat, 23 Apr 2016 20:41:42 GMT

What's missing from the win32 package?

post116124: Re: std::mutex::lock fails when on same stack address as another mutex before

Mario Charest — Wed, 20 Apr 2016 14:35:56 GMT

Thank you!

post116123: Re: std::mutex::lock fails when on same stack address as another mutex before

Michael Daniels — Wed, 20 Apr 2016 14:33:29 GMT

Updated packages for 4.8 have been uploaded.

post115898: Re: How to use libcpp.so.4 instead of lincpp.so.5 in qnx SDP 6.6?

Michael Daniels — Thu, 03 Mar 2016 14:29:10 GMT

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.

post115896: How to use libcpp.so.4 instead of lincpp.so.5 in qnx SDP 6.6?

swapnil Belote(deleted) — Thu, 03 Mar 2016 06:40:14 GMT

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?

post115888: Re: python2.7 (gdb-prereq): missing _scruct module

Igor Rondarev(deleted) — Tue, 01 Mar 2016 09:51:44 GMT

Michael,

thank you, it works indeed. Could you please provide win32 build too?

post115873: Re: std::mutex::lock fails when on same stack address as another mutex before

Mario Charest — Fri, 26 Feb 2016 17:00:30 GMT

> I'll take a look when I get some time.

Doctor, any hope?

post115841: Re: Build problem when using 5.1 branch (possibly applies elsewhere)

Michael Daniels — Mon, 22 Feb 2016 21:06:35 GMT

I believe this was fixed when we merged 5.3 into trunk, along with many other bug fixes. I suggest using that branch.

post115832: Build problem when using 5.1 branch (possibly applies elsewhere)

Alex Khripin — Mon, 22 Feb 2016 16:10:43 GMT

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).

post115691: Re: python2.7 (gdb-prereq): missing _scruct module

Alexey Smirnov(deleted) — Mon, 08 Feb 2016 06:29:35 GMT

Now works just fine, thanks!

post115690: Re: python2.7 (gdb-prereq): missing _scruct module

Michael Daniels — Sat, 06 Feb 2016 17:52:27 GMT

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.

post115681: Re: python2.7 (gdb-prereq): missing _scruct module

Alexey Smirnov(deleted) — Fri, 05 Feb 2016 12:52:10 GMT

> 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?

post115673: Re: GOLD linker for QNX

Michael Daniels — Wed, 03 Feb 2016 23:30:33 GMT

Yup. It seems I didn't realize how old the thread was.

post115672: Re: GOLD linker for QNX

Mario Charest — Wed, 03 Feb 2016 23:28:14 GMT

> Try this. It's a local build of gdb-7.6 from the svn repo for a 64bit linux

> host.

I'm I right in assuming that's in regard to Rodney's post (From july), and NOT about the mkefs issue

post115671: Re: GOLD linker for QNX

Michael Daniels — Wed, 03 Feb 2016 23:16:24 GMT

Try this. It's a local build of gdb-7.6 from the svn repo for a 64bit linux host.

post115670: Re: GOLD linker for QNX

Michael Daniels — Wed, 03 Feb 2016 22:30:16 GMT

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.

post115669: Re: python2.7 (gdb-prereq): missing _scruct module

Michael Daniels — Wed, 03 Feb 2016 21:51:47 GMT

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.

post115637: Re: GOLD linker for QNX

Mario Charest — Sat, 30 Jan 2016 02:10:12 GMT

Last week I played with the gold linker, kind of making it the default by overwritting stuff (sound of mad scientist rubbing his/jher hand),  One of the target of my diabolical plan was ntox86-ld !  Seems to work fine for a week but today I was building images and some of them ended up being 130M instead of 2Meg.   Sound of ballon deflating.

  Offset   Size    Entry   Ramoff Target=Host

  400000    440        0      --- ./x86/boot/sys/bios.boot

  400440    100     ----      --- Startup-header

  400540  14960   404e38      --- /tmp/fileKgYDol  ########## It's this guy that was WAY to big. (here it's ok )

  414a60     5c     ----      --- Image-header

  414abc    e04     ----      --- Image-directory

  4158c0      0     ----      --- proc/boot/unlink_list=/tmp/f

post115606: python2.7 (gdb-prereq): missing _scruct module

Igor Rondarev(deleted) — Mon, 25 Jan 2016 15:44:26 GMT

Hello!

Seems than current python 2.7 build cannot work with gdb 7.x and Qt Creator IDE (Linux, at least with 3.2.0 and 3.5.1 versions of IDE).

Steps to reproduce:

- try to debug any Qt application using "Debug" button.

Result: Debug feature does not work, "Window-> Views-> Debugger Log" contains at least these error lines:

------------------------- cut ---------------------------

>&"Traceback (most recent call last):\n"

>&"  File \"<string>\", line 1, in <module>\n"

>&"  File \"/opt/qtcreator-3.2.0/share/qtcreator/debugger/gdbbridge.py\", line 14, in <module>\n"

>&"    import struct\n"

>&"  File \"/opt/650/host/linux/x86/usr/python27.svn/lib/python2.7/struct.py\", line 1, in <module>\n"

>&"    from _struct import *\n"

>&"ImportError: No module named _struct\n"

------------------------- cut ---------------------------

(full log is attached)

help('modules') command also fails:

------------------------- cut ---------------------------

Python 2.7.2 (default, Feb 22 2012, 13:21:29)

[GCC 4.1.0] on linux2

Type "help", "copyright", "credits" or "license" for more information.

>>> help('modules')

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

  File "/opt/650/host/linux/x86/usr/python27/lib/python2.7/site.py", line 466, in __call__

    import pydoc

  File "/opt/650/host/linux/x86/usr/python27/lib/python2.7/pydoc.py", line 55, in <module>

    import sys, imp, os, re, types, inspect, __builtin__, pkgutil

  File "/opt/650/host/linux/x86/usr/python27/lib/python2.7/inspect.py", line 41, in <module>

    from operator import attrgetter

ImportError: No module named operator

>>>

------------------------- cut ---------------------------

Is any additional information needed?

Regards,

Igor

post115589: Re: std::mutex::lock fails when on same stack address as another mutex before

Michael Daniels — Fri, 22 Jan 2016 13:06:41 GMT

I'll take a look when I get some time.

post115587: Re: std::mutex::lock fails when on same stack address as another mutex before

Mario Charest — Fri, 22 Jan 2016 03:46:35 GMT

> 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".

post115586: RE: QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target

Mario Charest — Thu, 21 Jan 2016 23:38:41 GMT

Ryan doesn't seem to be working for QNX anymore.

Currently using 2.24.

And yes C++11 works, mostly, as 4.8.3 is not fully compliant.

-----Message d'origine-----

De : John Hagen [mailto:community-noreply@qnx.com]

Envoyé : 21 janvier 2016 18:37

À : general-toolchain <general-toolchain@community.qnx.com>

Objet : Re: QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target

> Can't you just use 4.8.3 and the bin utils for 6.5.0 ?

>

> Thanks,

> Anton

@Mario/@Ryan,

What is the exact tag/release of bin utils that is required/recommended to use the 4.8.3 compiler targeting QNX 6.5?

And would this then support C++11 library?

Thanks,

John

_______________________________________________

General

http://community.qnx.com/sf/go/post115585

To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com

post115585: Re: QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target

John Hagen(deleted) — Thu, 21 Jan 2016 23:36:42 GMT

> 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

post115372: Re: RE: RE: Specifying the -gsplit-dwarf option

Rodney Dowdall(deleted) — Tue, 22 Dec 2015 01:15:24 GMT

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.

post115371: Re: RE: RE: Specifying the -gsplit-dwarf option

Rodney Dowdall(deleted) — Tue, 22 Dec 2015 00:10:15 GMT

Hello

Ah I see. So how do I invoke gcc directly? I tried running arm-unknown-nto-qnx6.6.0eabi-gcc on a simple test.c file, but the collect2 failed because it didn't recognize the -plugin option.

Thanks,

Rodney

post115370: RE: RE: Specifying the -gsplit-dwarf option

Michael Daniels — Mon, 21 Dec 2015 23:50:16 GMT

It will pass it to the compiler (cc1) directly, not through the compiler driver (gcc) that has the logic to handle the option. In order to support this, qcc would need to have some code added to handle the option in a similar fashion.
________________________________________
From: Rodney Dowdall [community-noreply@qnx.com]
Sent: Monday, December 21, 2015 6:41 PM
To: general-toolchain
Subject: Re: RE: Specifying the -gsplit-dwarf option

Hello

Thanks for the response Michael. Would the -Wc,-gsplit-dwarf option not pass it to the gcc compiler?

Thanks,
Rodney

_______________________________________________

General
http://community.qnx.com/sf/go/post115369
To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com

post115369: Re: RE: Specifying the -gsplit-dwarf option

Rodney Dowdall(deleted) — Mon, 21 Dec 2015 23:41:38 GMT

Hello

Thanks for the response Michael. Would the -Wc,-gsplit-dwarf option not pass it to the gcc compiler?

Thanks,

Rodney

post115368: RE: Specifying the -gsplit-dwarf option

Michael Daniels — Mon, 21 Dec 2015 23:03:12 GMT

This option is handled by the compiler driver, so using gcc directly will work but qcc doesn't currently handle it so it will essentially end up being silently ignored.
________________________________________
From: Rodney Dowdall [community-noreply@qnx.com]
Sent: Monday, December 21, 2015 2:37 PM
To: general-toolchain
Subject: Specifying the -gsplit-dwarf option

Hello

Does the 4.9.3 compiler support the -gsplit-dwarf option? I am using the gold linker, and I have specified this option using both the -Wc,-gsplit-dwarf and just -gsplit-dwarf, but I do not seem to get a dwo file generated.

Thanks,
Rodney

_______________________________________________

General
http://community.qnx.com/sf/go/post115366
To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com

post115366: Specifying the -gsplit-dwarf option

Rodney Dowdall(deleted) — Mon, 21 Dec 2015 19:37:20 GMT

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

post115294: Re: Undefined simple when compiling C++ for armv7le using 4.9.3

Rodney Dowdall(deleted) — Sat, 12 Dec 2015 23:34:35 GMT

Hello

I figured it out. I had installed the 4.8.3 compiler after the 4.9.3 compiler. This caused the stdc++ library to be linked to the older library.

Untarring the 4.9.3 compiler again solved the problem.

Thanks,

Rodney

post115293: Undefined simple when compiling C++ for armv7le using 4.9.3

Rodney Dowdall(deleted) — Sat, 12 Dec 2015 19:01:31 GMT

Hello

I am trying to compile a c++ application with the 4.9.3 compiler. Eveything compiles, but the link phase produces the following errors:

undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)'

Is there a command line option that needs to be specified in order to link in this symbol?

Thanks,

Rodney

post114584: GCC 4.9.3 error: hidden symbol `__aeabi_ldiv0'

Daniel Levin(deleted) — Fri, 02 Oct 2015 17:47:03 GMT

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.

post114545: Re: RE: Using the 4.8.1 Compiler

Sriram Sundararajan(deleted) — Tue, 29 Sep 2015 20:23:07 GMT

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.?

post114538: Re: std::mutex::lock fails when on same stack address as another mutex before

Matthias Gehre(deleted) — Tue, 29 Sep 2015 07:54:12 GMT

Thank you for the fix.

Will this be included in a new "File release" of this project?

post114516: Re: std::mutex::lock fails when on same stack address as another mutex before

Ryan Mansfield(deleted) — Thu, 24 Sep 2015 18:09:09 GMT

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

post114515: RE: std::mutex::lock fails when on same stack address as another mutex before

Mario Charest — Thu, 24 Sep 2015 18:04:10 GMT

Is the file ok to use with GCC 4.8.3 on 650? Or is it 660 only?

-----Message d'origine-----

De : Ryan Mansfield [mailto:community-noreply@qnx.com]

Envoyé : 24 septembre 2015 13:57

À : general-toolchain@community.qnx.com

Objet : Re: std::mutex::lock fails when on same stack address as another mutex before

Hi Matthias,

Thank you for your report and analysis. I've open issue #1328672 to track the resolution. Attached is a libstdc++.so.6.0.17 built with the defines added to os_defines.h. After your test case no longer throws the exception.

Regards,

Ryan Mansfield

_______________________________________________

General

http://community.qnx.com/sf/go/post114512

To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com

post114514: Re: std::mutex::lock fails when on same stack address as another mutex before

Mario Charest — Thu, 24 Sep 2015 18:02:12 GMT

Ryan,

Related: Check out case 00139008 and bug report (JIRA ID 812757)

- Cheers

post114512: Re: std::mutex::lock fails when on same stack address as another mutex before

Ryan Mansfield(deleted) — Thu, 24 Sep 2015 17:56:47 GMT

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

post114509: Re: std::mutex::lock fails when on same stack address as another mutex before

Matthias Gehre(deleted) — Thu, 24 Sep 2015 10:54:04 GMT

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?

post114507: Re: std::mutex::lock fails when on same stack address as another mutex before

Matthias Gehre(deleted) — Thu, 24 Sep 2015 08:26:49 GMT

The same problem also affects rwlock and condition variables, which need -D_GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC -D_GTHREAD_USE_COND_INIT_FUNC.

post114497: std::mutex::lock fails when on same stack address as another mutex before

Matthias Gehre(deleted) — Wed, 23 Sep 2015 13:49:27 GMT

Hello,

I ported our C++11 application to QNX, but occasionally I get failures when trying to lock a std::mutex which resides on the stack. I'm currently testing this on SDP 6.6, but I also need to support SDP 6.5. This is why we are using libstdc++ instead of libcpp.

I reduced the problem to the three minimal testcases (see attached).

The problem seems to be that std::mutex initializes its pthread_mutex by PTHREAD_MUTEX_INITIALIZER. This mutex can be on the stack, but PTHREAD_MUTEX_INITIALIZER is only allowed for static (non-stack) variables

See QNX_Neutrino_RTOS_C_Library_Reference.pdf (for SDP 6.6.0), p. 2317:

"You can initialize a _statically_ allocated mutex with the default attributes by assigning

to it the macro PTHREAD_MUTEX_INITIALIZER or

PTHREAD_RMUTEX_INITIALIZER (for recursive mutexes)."

Most modern OS have dropped the "statically" from the restrictons, thus libstdc++ uses PTHREAD_RMUTEX_INITIALIZER by default.

The workaround is to add -D_GTHREAD_USE_MUTEX_INIT_FUNC to the compile arguments. This should go

into os_defines.h for a real fix (that's how libstdc++ does it on mingw)

Test cases: (run on the QNX 6.6.0 vmware image)

Stock SDP 6.6.0:

qcc tst_func.cpp -o tst_func -V4.7.3,gcc_ntox86_gpp -std=gnu++11

qcc tst_loop.cpp -o tst_loop -V4.7.3,gcc_ntox86_gpp -std=gnu++11

Both print "std::mutex::lock caused std::system_error at i = 1 with code generic:22 meaning Invalid argument"

GCC 4.8.3 from linux-gcc-4.8.3-qnx660.tar.gz from this foundry27 project

qcc tst_func.cpp -o tst_func -V4.8.3,gcc_ntox86_gpp -std=gnu++11

qcc tst_loop.cpp -o tst_loop -V4.8.3,gcc_ntox86_gpp -std=gnu++11

Both print "std::mutex::lock caused std::system_error at i = 1 with code generic:22 meaning Invalid argument"

qcc tst_SyncMutexLock_r.cpp -o tst_SyncMutexLock_r

Both print "Second SyncMutexLock_r failed

Second SyncMutexUnlock_r failed"

Best wishes,

Matthias Gehre

post114253: Re: ARM hosted complier?

Dave Nickerson(deleted) — Tue, 11 Aug 2015 19:39:02 GMT

The compiler itself is only available for x86 hosts (Neutrino, Linux or Windows) for 6.5.0.

post114243: ARM hosted complier?

Zhiying Xiang(deleted) — Mon, 10 Aug 2015 07:04:25 GMT

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.

post114156: Re: GOLD linker for QNX

Rodney Dowdall(deleted) — Thu, 23 Jul 2015 14:05:14 GMT

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.

post114139: Re: GOLD linker for QNX

Ryan Mansfield(deleted) — Thu, 16 Jul 2015 18:14:01 GMT

-fuse-ld=gold wasn't supported in gcc 4.4. If you're using the 4.8

packages on foundry, it should support -fuse-ld=gold. You should be able

to check by doing -v and seeing which underlying linker is being invoked.

Regards,

Ryan Mansfield

post114136: Re: GOLD linker for QNX

Rodney Dowdall(deleted) — Thu, 16 Jul 2015 18:02:29 GMT

Hello Ryan

The 64 bit linker worked. I am not sure if the GOLD Linker worked. I wasn't sure how to tell qcc how to use the gold linker. I tried just linking i486-pc-nto-qnx6.5.0-ld to ntox86-ld.gold and rerunning my link command, but it still gave me the exhausted memory error. So either, it doesn't work, or I didn't set it up properly. I just copied the i486-pc-nto-qnx6.5.0-ld over top of the link to get it go with the 64 bit one.

Does the -fuse-ld=gold work with gcc?

Thanks,

Rodney

post114130: Re: GOLD linker for QNX

Rodney Dowdall(deleted) — Wed, 15 Jul 2015 13:59:43 GMT

Thanks Ryan. I'll give these a try and let you know how it goes.

post114129: Re: GOLD linker for QNX

Ryan Mansfield(deleted) — Wed, 15 Jul 2015 13:57:22 GMT

Attached is a Linux x86_64 hosted bfd and gold ld for 6.5.0SP1. Let me know if you have any problems.

Regards,

Ryan Mansfield

post114128: Re: GOLD linker for QNX

Ryan Mansfield(deleted) — Wed, 15 Jul 2015 13:25:56 GMT

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

>

post114127: Re: GOLD linker for QNX

Rodney Dowdall(deleted) — Wed, 15 Jul 2015 13:19:24 GMT

Hey Ryan

So if I build it, would it get around the 4 GB link limit that the default linker has?

Thanks,

Rodney

post114126: Re: GOLD linker for QNX

Ryan Mansfield(deleted) — Wed, 15 Jul 2015 13:16:10 GMT

Yes, it should work on 6.5.0SP1

Regards,

Ryan Mansfield

post114125: GOLD linker for QNX

Rodney Dowdall(deleted) — Wed, 15 Jul 2015 12:58:17 GMT

Hello

I noticed the gold linker is checked in to the binutils source tree. Is this something that could be compiled for QNX 6.5.0 SP1?

Thanks,

Rodney

post114033: Re: QNX650: qcc (4.8.3) gives error while loading shared libraries (libstdc++.so.6)

Jane McIllen(deleted) — Fri, 26 Jun 2015 19:28:20 GMT

.. 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.

post114031: Re: QNX650: qcc (4.8.3) gives error while loading shared libraries (libstdc++.so.6)

Ryan Mansfield(deleted) — Fri, 26 Jun 2015 19:08:56 GMT

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

>

post114030: QNX650: qcc (4.8.3) gives error while loading shared libraries (libstdc++.so.6)

Jane McIllen(deleted) — Fri, 26 Jun 2015 19:03:33 GMT

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?

post114001: Re: Can't find array include when using "4.8.3,gcc_ntox86_cpp-ne" variant

Rodney Dowdall(deleted) — Mon, 22 Jun 2015 13:13:12 GMT

So is there a way to turn off exceptions when using the -std=gnu++11 option? The -fno-exceptions causes a compilation error in one of the standard header files.

Not a big deal if they can't be turned off. Just thought I would ask.

Thanks,

Rodney

post113996: Re: GDB for powerpc-unknown-nto-qnx6.5.0

JAMES IGOU(deleted) — Sun, 21 Jun 2015 14:53:00 GMT

A very disturbing thread. I was hoping to use QNX to develop on a PPC platform, but no it seems pointless.

post113995: Re: Can't find array include when using "4.8.3,gcc_ntox86_cpp-ne" variant

Rodney Dowdall(deleted) — Sat, 20 Jun 2015 00:13:42 GMT

Thanks Ryan, that solved it.

post113993: Re: Can't find array include when using "4.8.3,gcc_ntox86_cpp-ne" variant

Ryan Mansfield(deleted) — Fri, 19 Jun 2015 23:26:23 GMT

Use -std=gnu++0x or -std=gnu++11.

Regards,

Ryan Mansfield

Original Message

From: Rodney Dowdall

Sent: Friday, June 19, 2015 7:20 PM

To: general-toolchain

Reply To: general-toolchain@community.qnx.com

Subject: Re: RE: Can't find array include when using "4.8.3,gcc_ntox86_cpp-ne" variant

So it looks like the following define in yvals.h is getting missed:

#if defined(__GNUC__) && (2 <= __GNUC__) && (!__STRICT_ANSI__)

If I specify -Wc,-std=c++11 when I compile the attached test app then the compilation will fail. If I take out that -Wc,-std=c++11 then we go in to that define in yvals.h and then the define #define _C99 1 happens and everything compiles.

So is _C99 supposed to be defined when you use -Wc,-std=c++11 or is there another problem?

Thanks,

Rodney

_______________________________________________

General

http://community.qnx.com/sf/go/post113992

To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com

post113992: Re: RE: Can't find array include when using "4.8.3,gcc_ntox86_cpp-ne" variant

Rodney Dowdall(deleted) — Fri, 19 Jun 2015 23:20:18 GMT

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

post113991: Re: RE: Can't find array include when using "4.8.3,gcc_ntox86_cpp-ne" variant

Rodney Dowdall(deleted) — Fri, 19 Jun 2015 19:57:16 GMT

I guess I was wrong about the gpp only being available for x86.  Seems there is a variant for other targets as well.  I'll see what the exception enablement does to the code size.

However, how does one use math functions when using C++11?  I have tried including cmath only and with math.h, and I have tried different orders.  I have tried undeffing the functions that I want to use, but to no avail.  If I want to use copysign in my code for example, how do I do it?

Calling std::copysign doesn't work, and neither does copysign.

Thanks,

Rodney

post113990: Re: RE: Can't find array include when using "4.8.3,gcc_ntox86_cpp-ne" variant

Rodney Dowdall(deleted) — Fri, 19 Jun 2015 18:26:46 GMT

> 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.

post113989: RE: Can't find array include when using "4.8.3,gcc_ntox86_cpp-ne" variant

Mario Charest — Fri, 19 Jun 2015 18:24:35 GMT

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

post113988: Re: Can't find array include when using "4.8.3,gcc_ntox86_cpp-ne" variant

Rodney Dowdall(deleted) — Fri, 19 Jun 2015 18:23:28 GMT

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

post113987: Re: Can't find array include when using "4.8.3,gcc_ntox86_cpp-ne" variant

Ryan Mansfield(deleted) — Fri, 19 Jun 2015 17:51:25 GMT

On 15-06-19 01:48 PM, Rodney Dowdall wrote:

>> <array> was only added in C++11, and the Dinkumware C++ library that

>> shipped with QNX 6.5.0 in 2010 was C++98. It's available in the GNU

>> libstdc++ in 6.5.0 as part of the experimental C++0x support.

>>

>> Regards,

>>

>> Ryan Mansfield

>

> So when I download the updates (i.e.: linux-gcc-4.8.3-qnx65x.tar.gz) from Foundary, that doesn't include updated Dinkum libraries? Does the "-Wc,-std=c++0x" not turn on that C++0x support? Or is it a different option?

Only the GNU libstdc++ updates are packaged with gcc packages on

foundry27. -Wc,-std=c++0x turns on the core language level but doesn't

add support in the C++ STL headers.

Regards,

Ryan Mansfield

post113986: Re: Can't find array include when using "4.8.3,gcc_ntox86_cpp-ne" variant

Rodney Dowdall(deleted) — Fri, 19 Jun 2015 17:48:54 GMT

> <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?

post113985: Re: Can't find array include when using "4.8.3,gcc_ntox86_cpp-ne" variant

Ryan Mansfield(deleted) — Fri, 19 Jun 2015 17:44:03 GMT

<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

post113984: Can't find array include when using "4.8.3,gcc_ntox86_cpp-ne" variant

Rodney Dowdall(deleted) — Fri, 19 Jun 2015 17:37:15 GMT

Hello

I am trying to build something using the "4.8.3,gcc_ntox86_cpp-ne" variant, but when a header file tries to include the array include file it says that it can't find it. Here is my compile line minus project specific defines:

home/rodney/tools/qnx650/host/linux/x86/usr/bin/qcc -lang-c++ -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D__QNXNTO__ -V4.8.3,gcc_ntox86_cpp-ne -Wc,-std=c++0x -lang-c++ -fno-rtti -Wformat -Wformat-security -Werror=format-security -Wl,--no-keep-memory -Wc,-std=c++11 -fno-exceptions -fno-strict-aliasing -fno-rtti -Wall -Wextra -Wcast-align -Wformat-security -Wmissing-format-attribute -Wpointer-arith -Wundef -Wwrite-strings -fPIC

The error I get is:

fatal error: array: No such file or directory

#include <array>

Thanks,

Rodney

post113972: Re: GCC for powerpc-unknown-nto-qnx6.5.0

Maxim Kuzmin(deleted) — Thu, 18 Jun 2015 09:21:53 GMT

Yes, I've reconfigured and rebuilt gcc.

post113964: Re: GCC for powerpc-unknown-nto-qnx6.5.0

Ryan Mansfield(deleted) — Wed, 17 Jun 2015 13:59:41 GMT

On 15-06-17 04:23 AM, Maxim Kuzmin wrote:

> I've successfully built binutils and updated /opt/qnx650/host/linux/x86/usr/bin/ntoppc-as, but unfortunately, I've got same error. This is output from gcc with "--verbose" flag:

>

> /opt/qnx650/host/linux/x86/usr/bin/ntoppc-as --gdwarf2 -v -I. -I. -I../.././gcc -I/home/max/gcc/gcc_4_6_branch/libgcc -I/home/max/gcc/gcc_4_6_branch/libgcc/. -I/home/max/gcc/gcc_4_6_branch/libgcc/../gcc -I/home/max/gcc/gcc_4_6_branch/libgcc/../include -mppc -many -V -Qy -mbig -o crtsavfpr.o /tmp/ccR7N05D.s

> GNU assembler version 2.25 (powerpc-unknown-nto-qnx6.5.0) using BFD version (GNU Binutils) 2.25

> ../.././gcc/crtsavfpr.S: Assembler messages:

> ../.././gcc/crtsavfpr.S:41: Error: unrecognized opcode: cfi_endproc'

> ../.././gcc/crtsavfpr.S:79: Error: unrecognized opcode: cfi_startproc'

>

> Am I need to update other executables from binutils?

Did you reconfigure and rebuild against the updated binutils?

i.e. config/rs6000/ppc-asm.h has

#ifdef HAVE_GAS_CFI_DIRECTIVE

# define CFI_STARTPROC                  .cfi_startproc

# define CFI_ENDPROC                    .cfi_endproc

# define CFI_OFFSET(reg, off)           .cfi_offset reg, off

# define CFI_DEF_CFA_REGISTER(reg)      .cfi_def_cfa_register reg

# define CFI_RESTORE(reg)               .cfi_restore reg

#else

# define CFI_STARTPROC

# define CFI_ENDPROC

# define CFI_OFFSET(reg, off)

# define CFI_DEF_CFA_REGISTER(reg)

# define CFI_RESTORE(reg)

#endif

and HAVE_HAS_CFI_DIRECTIVE will be defined by configure. The binutils

2.25 that you just build should support the .cfi directives.

Regards,

Ryan Mansfield

post113963: Re: GCC for powerpc-unknown-nto-qnx6.5.0

Maxim Kuzmin(deleted) — Wed, 17 Jun 2015 08:23:02 GMT

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?

post113959: Re: GCC for powerpc-unknown-nto-qnx6.5.0

Ryan Mansfield(deleted) — Tue, 16 Jun 2015 13:52:35 GMT

On 15-06-16 09:51 AM, Maxim Kuzmin wrote:

> OK, I've solved this problem, but I've got another one:

>

> make[2]: Entering directory `/home/max/gcc/build/powerpc-unknown-nto-qnx6.5.0/libgcc'

> # If this is the top-level multilib, build all the other

> # multilibs.

> powerpc-unknown-nto-qnx6.5.0-gcc -g -D__GNU_STDC_INLINE__ -O2 -g -D__GNU_STDC_INLINE__ -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fexceptions -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector -I. -I. -I../.././gcc -I/home/max/gcc/gcc_4_6_branch/libgcc -I/home/max/gcc/gcc_4_6_branch/libgcc/. -I/home/max/gcc/gcc_4_6_branch/libgcc/../gcc -I/home/max/gcc/gcc_4_6_branch/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o crtsavfpr.o -MT crtsavfpr.o -MD -MP -MF crtsavfpr.dep -c -xassembler-with-cpp ../.././gcc/crtsavfpr.S

> ../.././gcc/crtsavfpr.S: Assembler messages:

> ../.././gcc/crtsavfpr.S:41: Error: Unrecognized opcode: `cfi_startproc'

> ../.././gcc/crtsavfpr.S:79: Error: Unrecognized opcode: `cfi_endproc'

> make[2]: *** [crtsavfpr.o] Error 1

> make[2]: Leaving directory `/home/max/gcc/build/powerpc-unknown-nto-qnx6.5.0/libgcc'

> make[1]: *** [all-target-libgcc] Error 2

> make[1]: Leaving directory `/home/max/gcc/build'

> make: *** [all] Error 2

>

> How to fix it?

Your binutils are too old. Build the trunk binutils for ppc.

Regards,

Ryan Mansfield

post113958: Re: GCC for powerpc-unknown-nto-qnx6.5.0

Maxim Kuzmin(deleted) — Tue, 16 Jun 2015 13:51:13 GMT

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?

post113937: GCC for powerpc-unknown-nto-qnx6.5.0

Maxim Kuzmin(deleted) — Tue, 09 Jun 2015 10:35:49 GMT

Hello,

It's me again and now I'm trying to build GCC for powerpc-unknown-nto-qnx6.5.0 using cross-compilation tools for linux-x86 host. Compilation fails with message:

make[4]: Entering directory '/home/max/gcc/build/powerpc-unknown-nto-qnx6.5.0/pic/libgcc'

# If this is the top-level multilib, build all the other

# multilibs.

powerpc-unknown-nto-qnx6.5.0-gcc -g -O2 -fpic -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fexceptions -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fexceptions -I. -I. -I../../.././gcc -I/home/max/gcc/trunk/libgcc -I/home/max/gcc/trunk/libgcc/. -I/home/max/gcc/trunk/libgcc/../gcc -I/home/max/gcc/trunk/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /home/max/gcc/trunk/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS

cc1: error: unrecognized command line option -fbuilding-libgcc

Makefile:466: recipe for target '_muldi3.o' failed

make[4]: *** [_muldi3.o] Error 1

make[4]: Leaving directory '/home/max/gcc/build/powerpc-unknown-nto-qnx6.5.0/pic/libgcc'

Makefile:1154: recipe for target 'multi-do' failed

make[3]: *** [multi-do] Error 1

make[3]: Leaving directory '/home/max/gcc/build/powerpc-unknown-nto-qnx6.5.0/libgcc'

Makefile:117: recipe for target 'all-multi' failed

make[2]: *** [all-multi] Error 2

make[2]: Leaving directory '/home/max/gcc/build/powerpc-unknown-nto-qnx6.5.0/libgcc'

Makefile:12916: recipe for target 'all-target-libgcc' failed

make[1]: *** [all-target-libgcc] Error 2

make[1]: Leaving directory '/home/max/gcc/build'

Makefile:877: recipe for target 'all' failed

make: *** [all] Error 2

GCC 5.1, downloaded from f27svn.qnx.com/svn/repos/core-dev-tools

Configuration options:

--build=i686-pc-linux-gnu --host=powerpc-unknown-nto-qnx6.5.0 --target=powerpc-unknown-nto-qnx6.5.0 --with-bugurl=no --program-prefix=ntoppc- --enable-languages=c,c++ --verbose --without-expat --with-expat=no --with-python=no --disable-nls

post113890: Re: RE: API for unique thread-id in QNX

Mayank Jain(deleted) — Mon, 01 Jun 2015 16:36:33 GMT

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;

}

post113889: RE: API for unique thread-id in QNX

John Kearney — Mon, 01 Jun 2015 16:10:10 GMT

If this is related to the MIB3 logging requirements the closest we have is maybe to use.

volatile struct _thread_local_storage *tls = LIBC_TLS();

tls->__owner

which will give you a system wide unique id, but only for that instance, if processes or thread ends it can be reused. But then again you have the same issue for gettid.

So if you want runtime unique you'll need a custom solution for both linux and qnx, with a value larger than 32bit.

-----Original Message-----

From: Mayank Jain [mailto:community-noreply@qnx.com]

Sent: Montag, 1. Juni 2015 14:14

To: general-toolchain

Subject: API for unique thread-id in QNX

Is there any API to obtain *unique* thread-id at least at the process level (if not across processes) in the QNX? Like Linux and Android support gettid API/syscall which returns unique thread-id. Any help is highly appreciated.

Please note Id obtained by pthread_self() may be reused after a terminated thread has been joined, or a detached thread has terminated.

_______________________________________________

General

http://community.qnx.com/sf/go/post113881

To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com

post113882: RE: API for unique thread-id in QNX

Gervais Mulongoy — Mon, 01 Jun 2015 12:17:31 GMT

You could use a pthread key and store the value of a global counter which you could use as a unique id?

post113881: API for unique thread-id in QNX

Mayank Jain(deleted) — Mon, 01 Jun 2015 12:14:23 GMT

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.

post113828: Re: GDB for powerpc-unknown-nto-qnx6.5.0

Maxim Kuzmin(deleted) — Mon, 18 May 2015 08:52:09 GMT

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!

post113824: Re: GDB for powerpc-unknown-nto-qnx6.5.0

Aleksandar Ristovski(deleted) — Fri, 15 May 2015 14:23:34 GMT

Touch those files that want to get regenerated

E.g.

$ touch gdb-6.8/bfd/doc/bfd.info

post113822: Re: GDB for powerpc-unknown-nto-qnx6.5.0

Maxim Kuzmin(deleted) — Fri, 15 May 2015 08:13:58 GMT

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.

post113819: Re: GDB for powerpc-unknown-nto-qnx6.5.0

Aleksandar Ristovski(deleted) — Thu, 14 May 2015 14:37:47 GMT

On 2015-05-14, 10:35 AM, "Ryan Mansfield" <community-noreply@qnx.com>

wrote:

>On 15-05-14 10:30 AM, Aleksandar Ristovski wrote:

>> Not surprising. We do not support PPC in 6.6.0, and gdb 7.6 was not

>>really

>> meant to be used with 6.5.0. So I can't help you much more with that.

>>

>> However, if you do need gdb 7.6 for 6.5.0/ppc, I suggest you go through

>> QNX support.

>>

>> Or you can go back to our gdb 6.8 and try it, it should work better

>> (though, again, we never tested it self-hosted on ppc). Similar patch

>> would be needed as for 7.6.

>

>One quick thing to try is that gdb self hosted on ppc might be running

>out of stack (default of 512K), so he should try to use ldrel to set a

>fairly larger stack size on the gdb binary.

That is true.

In your build directory:

$ ldrel -L -S 4M gdb/gdb

post113818: Re: GDB for powerpc-unknown-nto-qnx6.5.0

Ryan Mansfield(deleted) — Thu, 14 May 2015 14:35:19 GMT

On 15-05-14 10:30 AM, Aleksandar Ristovski wrote:

> Not surprising. We do not support PPC in 6.6.0, and gdb 7.6 was not really

> meant to be used with 6.5.0. So I can't help you much more with that.

>

> However, if you do need gdb 7.6 for 6.5.0/ppc, I suggest you go through

> QNX support.

>

> Or you can go back to our gdb 6.8 and try it, it should work better

> (though, again, we never tested it self-hosted on ppc). Similar patch

> would be needed as for 7.6.

One quick thing to try is that gdb self hosted on ppc might be running

out of stack (default of 512K), so he should try to use ldrel to set a

fairly larger stack size on the gdb binary.

Regards,

Ryan Mansfield

post113817: Re: GDB for powerpc-unknown-nto-qnx6.5.0

Aleksandar Ristovski(deleted) — Thu, 14 May 2015 14:30:17 GMT

Not surprising. We do not support PPC in 6.6.0, and gdb 7.6 was not really

meant to be used with 6.5.0. So I can't help you much more with that.

However, if you do need gdb 7.6 for 6.5.0/ppc, I suggest you go through

QNX support.

Or you can go back to our gdb 6.8 and try it, it should work better

(though, again, we never tested it self-hosted on ppc). Similar patch

would be needed as for 7.6.

---

Aleksandar

post113816: Re: GDB for powerpc-unknown-nto-qnx6.5.0

Maxim Kuzmin(deleted) — Thu, 14 May 2015 14:11:50 GMT

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".

post113815: Re: GDB for powerpc-unknown-nto-qnx6.5.0

Aleksandar Ristovski(deleted) — Thu, 14 May 2015 13:21:20 GMT

We do not support ppc host. But if you really want to build it, apply the

following patch:

Index: gdb/config/powerpc/nto.mh

===================================================================

--- gdb/config/powerpc/nto.mh   (revision 0)

+++ gdb/config/powerpc/nto.mh   (working copy)

@@ -0,0 +1,4 @@

+# Host: Intel 386 running QNX.

+

+NATDEPFILES= nto-procfs.o

+NAT_FILE= config/nm-nto.h

Index: gdb/configure.host

===================================================================

--- gdb/configure.host  (revision 897)

+++ gdb/configure.host  (working copy)

@@ -134,6 +134,7 @@ powerpc-*-linux*)   gdb_host=linux ;;

powerpc-*-netbsd* | powerpc-*-knetbsd*-gnu)

            gdb_host=nbsd ;;

powerpc-*-openbsd*)    gdb_host=obsd ;;

+powerpc*-*-nto*)   gdb_host=nto ;;

powerpc64-*-linux*)     gdb_host=ppc64-linux

                         # Support 'pseudo-native' debugging on the Cell BE

Then:

$ mkdir build

$ cd build

$ ../configure --host=powerpc-unknown-nto-qnx6.5.0

--target=powerpc-unknown-nto-qnx6.5.0 --without-expat --with-bugurl=no

--with-python=no --program-prefix=ntoppc- --enable-gdbmi --disable-nls

--disable-tui --disable-sim --without-sim --with-expat=no --disable-werror

--verbose CFLAGS="-D__QNXTARGET__ -g0 -O -D_LARGEFILE64_SOURCE"

CPPFLAGS="-I/tmp/stage650/qnx6/usr/include -I${QNX_TARGET}/usr/include"

LDFLAGS="-L${QNX_TARGET}/ppc/lib -L${QNX_TARGET}/ppc/usr/lib"

$ make

You will need proper environment variables

(QNX_HOST,QNX_TARGET,MAKEFLAGS,PATH).

Good luck,

Aleks

post113814: GDB for powerpc-unknown-nto-qnx6.5.0

Maxim Kuzmin(deleted) — Thu, 14 May 2015 09:28:49 GMT

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?

post113438: Re: Linking issue with 4.8.3 under 650

Alexey Smirnov(deleted) — Sat, 28 Feb 2015 11:05:01 GMT

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!

post113360: Re: QCC cross-compile neon error

Aaron Gawlik(deleted) — Fri, 20 Feb 2015 16:19:34 GMT

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.

post113358: Re: QCC cross-compile neon error

Ryan Mansfield(deleted) — Fri, 20 Feb 2015 16:00:40 GMT

On 15-02-20 10:54 AM, Aaron Gawlik wrote:

> I am trying to cross-compile FFTW from build machine x86-64bit Ubuntu Linux to host machine armv7le QNX6.6 neutrino. When I build with neon option, the autoconf utility tests that the compiler accepts neon flag and fails because QCC uses the build compiler (x86 with no neon support), not the host compiler. Is there a flag setting I'm missing from below, or this an issue with autoconf tools? Other tests use the host (arm) compiler. Enabling threads has no effect on this error.

>

> Attached is the config.log.

>

> I've since commented out the ./configure lines associated with testing for -mfpu=neon and hardcode the flags in order to successfully compile with neon support.

>

> The configure setup is:

> ARM_CPU_TYPE=cortex-a9 \

> CFLAGS="$CFLAGS $MAKEFLAGS -V4.7.3,gcc_ntoarmv7le -w9 -march=armv7-a -mfpu=neon -mfloat-abi=softfp" \

> LDFLAGS="$LDFLAGS -V4.7.3,gcc_ntoarmv7le" \

> NM=ntoarmv7-nm AR=ntoarmv7-ar RANLIB=ntoarmv7-ranlib \

> STRIP=ntoarmv7-strip CC=qcc LD=qcc \

> ./configure --host=armv7-nto \

> --prefix=$HOME/fftw_test --enable-neon --enable-single \

> --enable-threads

It looks like CFLAGS aren't being passed down to the neon conftest to

specify -Vgcc_ntoarmv7le, and it's just invoking qcc which defaults to x86.

Have you tried using --host=arm-unknown-nto-qnx6.6.0eabi and using the

gcc driver, instead of using qcc or and setting qcc options with CFLAGS?

i.e

./configure --host=arm-unknown-nto-qnx6.6.0eabi --prefix=$HOME/fftw_test

--enable-neon --enable-singl --enable-threads

Regards,

Ryan Mansfield

post113356: QCC cross-compile neon error

Aaron Gawlik(deleted) — Fri, 20 Feb 2015 15:54:35 GMT

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.

post113269: Re: Mudflap library with backtrace

Elena Laskavaia — Mon, 09 Feb 2015 14:26:44 GMT

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.

>

post113197: Mudflap library with backtrace

Dmitry Zhelobanov(deleted) — Tue, 03 Feb 2015 07:40:40 GMT

Hello

How to enable printing backtrace in mudflap violations?

I use SDK 6.5.0

Dmitry Zhelobanov.

post113109: Re: Verbosity of build process

Vincent Wan(deleted) — Tue, 27 Jan 2015 21:58:57 GMT

Thank you - that was exactly what I was looking for!

Best regards,

Vincent

post113086: Re: Verbosity of build process

Colin Burgess — Tue, 27 Jan 2015 01:08:07 GMT

Hi Vincent,

You can try adding this to the end of your common.mk

# Quiet the build output so we can see the warnings

ifneq ($(V),1)

MAKE = @$(MAKE_COMMAND) --no-print-directory

RM_HOST := @$(RM_HOST)

ifeq ($(V),0)

CCPREF := @$(CCPREF)

ASPREF := @$(ASPREF)

LDPREF := @$(LDPREF)

ARPREF := @$(ARPREF) 2>/dev/null

UMPREF := @$(UMPREF)

MKASMOFF_HOST := @$(MKASMOFF_HOST)

else

QUIET_ROOT := $(PROJECT_ROOT)

#QUIET_ROOT := $(PRODUCT_ROOT)

CCPREF_CMD := $(CCPREF)

CCPREF = @echo "Compiling " $(<:$(QUIET_ROOT)/%=%) && $(CCPREF_CMD)

ASPREF_CMD := $(ASPREF)

ASPREF = @echo "Assembling" $(<:$(QUIET_ROOT)/%=%) && $(ASPREF_CMD)

LDPREF_CMD := $(LDPREF)

LDPREF = @echo "Linking   " $(@:$(QUIET_ROOT)/%=%) && $(LDPREF_CMD)

ARPREF_CMD := $(ARPREF) 2>/dev/null

ARPREF = @echo "Archiving " $(@:$(QUIET_ROOT)/%=%) && $(ARPREF_CMD)

UMPREF_CMD := $(UMPREF)

UMPREF = @echo "Usemsg     " $(@:$(QUIET_ROOT)/%=%) && $(UMPREF_CMD)

MKASMOFF_CMD := $(MKASMOFF_HOST)

MKASMOFF_HOST = @echo "Generating" $(CURDIR:$(QUIET_ROOT)/%=%)/$@ &&

$(MKASMOFF_CMD)

endif

endif

On 2015-01-26 8:05 PM, Vincent Wan wrote:

> I have noticed that when building a project, all qcc invocation command lines are printed out on the console, e.g.

>

> C:/qnx660/host/win32/x86/usr/bin/qcc -Vgcc_ntoarmv7 -c -Os -Wc,-Wall -DF3S_VER=3 -DMTD_VER=2 -DNDEBUG   -I. -IC:/Users/me/ide-5.0-workspace/bsp-TI-DRA72x-evm-SDP6.6_M2/src/hardware/flash/boards/ti_qspi/arm/le.v7 -IC:/Users/me/ide-5.0-workspace/bsp-TI-DRA72x-evm-SDP6.6_M2/src/hardware/flash/boards/ti_qspi/arm -IC:/Users/me/ide-5.0-workspace/bsp-TI-DRA72x-evm-SDP6.6_M2/src/hardware/flash/boards/ti_qspi -IC:/Users/me/ide-5.0-workspace/bsp-TI-DRA72x-evm-SDP6.6_M2/src/hardware/flash/boards -IC:/Users/me/ide-5.0-workspace/bsp-TI-DRA72x-evm-SDP6.6_M2/src/hardware/flash/mtd-flash/public -IC:/Users/me/ide-5.0-workspace/bsp-TI-DRA72x-evm-SDP6.6_M2/src/hardware/flash -IC:/Users/me/ide-5.0-workspace/bsp-TI-DRA72x-evm-SDP6.6_M2/src/hardware/flash/boards/../../../../install/usr/include -IC:/qnx660/target/qnx6/usr/include    -EL              -DVARIANT_le -DVARIANT_v7 -DVARIANT_ti_qspi -DBUILDENV_qss  C:/Users/me/ide-5.0-workspace/bsp-TI-DRA72x-evm-SDP6.6_M2/src/hardware/flash/boards/ti_qspi/f3s_qspi_erase.c

>

> Is there a way to reduce verbosity of the build process to hide these lines and other similar ones? This becomes excessively verbose when there is a long list of include paths.

>

> Thank you.

>

>

>

>

> _______________________________________________

>

> General

> http://community.qnx.com/sf/go/post113085

> To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com

post113085: Verbosity of build process

Vincent Wan(deleted) — Tue, 27 Jan 2015 01:05:08 GMT

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.

post112776: Re: realpath() on QNX.

Sean Boudreau(deleted) — Wed, 24 Dec 2014 00:51:22 GMT

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 );

> }

post112759: realpath() on QNX.

Akshat Gill(deleted) — Mon, 22 Dec 2014 12:48:42 GMT

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

post112756: readlink() error on QNX.

Akshat Gill(deleted) — Mon, 22 Dec 2014 11:49:19 GMT

Hello,

I am trying to run a sample program which uses

readlink("/proc/self/exefile",buf.PATH_MAX). It returns -1.

I am using QNX 6.6.0 32-bit.

Doing ls to /proc/self/exefile displays:-

-rw------- 1 root 0 14 Mar 09 06:32 /proc/self/exefile

I tried changing the permission using chmod.

Using the command :-

> chmod u+x /proc/self/exefile

gives result :-

chmod: changing permission of /proc/self/exefile : No such file or directory

Please assist.

I have attached the sample program.

Regards

-Akshat

post112347: Include doesn't compile with QNX 6.6 QCC and c++11

Anton Indrawan(deleted) — Fri, 14 Nov 2014 18:03:09 GMT

Hi QNX folks,

Using the std=c++11, QNX 6.6 QCC threw a compile error when I included boost/shared_ptr.

#include <boost/shared_ptr.hpp>

In file included from /home/test/qnx/ThirdParty/boost_1_55_0/boost/smart_ptr/detail/spinlock_sync.hpp:18:0,

                 from /home/test/qnx/ThirdParty/boost_1_55_0/boost/smart_ptr/detail/spinlock.hpp:41,

                 from /home/test/qnx/ThirdParty/boost_1_55_0/boost/smart_ptr/detail/spinlock_pool.hpp:25,

                 from /home/test/qnx/ThirdParty/boost_1_55_0/boost/smart_ptr/shared_ptr.hpp:38,

                 from /home/test/qnx/ThirdParty/boost_1_55_0/boost/shared_ptr.hpp:17,

                 from /home/test/qnx/TestProgram/math/math.cpp:5:

/home/test/qnx/ThirdParty/boost_1_55_0/boost/smart_ptr/detail/yield_k.hpp: In function 'void boost::detail::yield(unsigned int)':

/home/test/qnx/ThirdParty/boost_1_55_0/boost/smart_ptr/detail/yield_k.hpp:122:29: error: 'nanosleep' was not declared in this scope

cc: /opt/qnx660/host/linux/x86/usr/lib/gcc/arm-unknown-nto-qnx6.6.0eabi/4.7.3/cc1plus error 1

make[2]: *** [TestProgram/math/CMakeFiles/testapp.math.dir/math.cpp.o] Error 1

make[1]: *** [TestProgram/math/CMakeFiles/testapp.math.dir/all] Error 2

Is this a boost issue or the QNX 6.6 toolchain issue?

Best regards,

Anton

post112288: Re: complex.h 4.7.2

Peter Luscher(deleted) — Thu, 06 Nov 2014 14:35:35 GMT

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] "

post112066: objdump problem with GCC 4.8.3 + QNX6.5.0

Mario Charest — Sat, 18 Oct 2014 00:05:50 GMT

Using gcc 4.8.3 objdump-2.24 (or any other version I could try ) when used with -S and -d, to look at assembly code is giving an output that doesn't make any sense.

Example, output of objdump:

  0:   55                      push   %ebp

131:   89 e5 57 56 53 83 e4    movl   $0xe,0x4(%esp)

138:   f0

139:   81 ec 40 02 00 00 e8    movl   $0x0,(%esp)

140:   fc ff                   fmulp  %st,%st(1)

142:   ff ff 85 c0             fstpl  0x18(%esp)

146:   74 0c c7 04 24          call   147 <main+0x17>

14b:   00 00 00 00             fldl   0x18(%esp)

14f:   e8 fc ff                mov    %eax,(%esp)

152:   ff ff 0f 31             fstpl  0x4(%esp)

And same thing but using -S with gcc

pushl %ebp

.cfi_def_cfa_offset 8

.cfi_offset 5, -8

movl %esp, %ebp

.cfi_def_cfa_register 5

pushl %edi

pushl %esi

pushl %ebx

andl $-16, %esp

subl $576, %esp

.cfi_offset 7, -12

.cfi_offset 6, -16

.cfi_offset 3, -20

.LEHB0:

call _Z21FindCpuSpeedForPClockv

testl %eax, %eax

je .L2

movl $.LC0, (%esp)

call puts

post112065: Re: RE: RE: Make builds excruciatingly slow -- sometimes

Kevin Schaffer(deleted) — Fri, 17 Oct 2014 19:45:52 GMT

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.

post112045: Re: RE: RE: Make builds excruciatingly slow -- sometimes

Kevin Schaffer(deleted) — Wed, 15 Oct 2014 13:57:27 GMT

Still here, it just hasn't manifested as a problem the past few days, so can't test it.

post112033: Re: boost::math::isnan doesn't compile with QNX 6.6 QCC

Anton Indrawan(deleted) — Sat, 11 Oct 2014 18:50:18 GMT

> It's probably because isnan is a macro. Try with (boost::math::isnan)(5)

> instead. It's explained in the Boost documentation:

> http://www.boost.org/doc/libs/1_55_0/libs/math/doc/html/math_toolkit/fpclass.

> html

Hi Niklas,

My bad, I didn't read the boost doc first.

Thanks for the information, it compiles fine now.

Best regards,

Anton

post112024: RE: RE: Make builds excruciatingly slow -- sometimes

Mario Charest — Fri, 10 Oct 2014 14:35:29 GMT

You can try setting the LOGONSERVER variables to that of your PC within the éclos env. Have had some level of success with this.

________________________________________

From: Kevin Schaffer [community-noreply@qnx.com]

Sent: Friday, October 10, 2014 10:16 AM

To: general-toolchain

Subject: Re: RE: Make builds excruciatingly slow -- sometimes

Oh. My. God. I think you're right.

Looking at network activity with the process monitor, it does indeed seem to be doing something on the network. Our network is wireless and could be clogged at certain times of the day. It's morning and speedy now.

Next time massive slowdown occurs, I will check it again.

_______________________________________________

General

http://community.qnx.com/sf/go/post112022

To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com

post112022: Re: RE: Make builds excruciatingly slow -- sometimes

Kevin Schaffer(deleted) — Fri, 10 Oct 2014 14:16:58 GMT

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.

post112015: RE: Make builds excruciatingly slow -- sometimes

Mario Charest — Thu, 09 Oct 2014 22:03:50 GMT

If you are under a Windows Domain,  the shell (from MSYS I believe) will, every time it starts, contact the logon server, not nice.  It can get messy, if you logon the domain then disconnect from the network.

We have moved all our development under Linux which we run in a virtual machine under Windows ( we aren`t ready yet to use Linux natively on our development PC).  Our build time has gone down by an average of 25%, yep 25% faster on the same machine but in a virtual machine.  Only down side we have found so far is the Index seems to be slower, don`t know why.  There some issue with VMWare loosing cut and paste functionality between the guess and host, but overall the experience has been more then positive.

We can deploy a setup in minutes, move it from PC to PC very simply if the hardware is being upgrade.  I`m currently on the road and have move my VM from by main desktop machine to a laptop, make my live much simpler.  We can deploy upgrades by telling everyone to get a new image.

Everyone should use Momentic under Linux in my opinion. Virtual machine or not.  Even better yet, get Luna, and install the QNX stuff from a REPOS file.  The CDT is much better.  People at the office enjoy the dark theme very much ;-)

With QNX dropping features and product lines left and right, Momentics for Windows is one I wouldn`t mind they dropped ;-)

Back to work now.

-----Message d'origine-----

De : Kevin Schaffer [mailto:community-noreply@qnx.com]

Envoyé : Thursday, October 09, 2014 5:25 PM

À : general-toolchain

Objet : Make builds excruciatingly slow -- sometimes

All our machines have this problem, though some are different models.  Mine is Windows 7, 32gb, 8-core.

We start a make build of a project with dozens of folders and thousands of files.  Sometimes it is lightning fast.  Other times it is very slow, like 2-3s per processed line.

Turning on -d shows the bottleneck seems to be right after the CreateProcess(blah blah)/Live Child lines.

Then 2-3s pause

Then it does what the process should do (that line in a makefile)

Then Reaping winning child...

instant repeat.

This happens even on echo hello world type lines that do not even reference a variable (so there could be no permutational explosion of references as variables are resolvled.)

That makes no sense anyway because it sometimes is lightning fast and nothing else has changed.

The CPU is not busy at all during this (no process is above 1%, and none of the make/compiler things are even that.  A locked octo'th processor would be a process at 13%-ish.)

I've killed and restarted the command window, no change.  Sometimes it just "goes away" and it's fast again.

Any ideas?

_______________________________________________

General

http://community.qnx.com/sf/go/post112014

To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com

post112014: Make builds excruciatingly slow -- sometimes

Kevin Schaffer(deleted) — Thu, 09 Oct 2014 21:24:50 GMT

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?

post112000: Re: boost::math::isnan doesn't compile with QNX 6.6 QCC

Niklas Angare — Thu, 09 Oct 2014 10:58:38 GMT

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

post111973: Re: mkifs corrupts io-hid, one binary before and one binary after

Kevin Stallard — Sat, 04 Oct 2014 22:18:40 GMT

Here is the build file I have been using.

Thanks

Kevin

post111972: Re: mkifs corrupts io-hid, one binary before and one binary after

Kevin Stallard — Sat, 04 Oct 2014 22:13:47 GMT

> Okay, after several days of additional investigation and such here is where I

> am :

>

> 1.  I eliminated the possibility that it was the medium I was using to boot

> the x86 box.  I was using a USB stick formatted using mkqnx6fsimg in

> combination with the new diskimage utility.  If found a SATA to USB adapter,

> conencted a laptop harddisk to my Ubuntu host, and QNX 6.5 VM.  I used these

> hosts to format and load the harddisk with the images.  I both formatted the

> HD using the mkqnx6fs utility on QNX 6.5 and just copied the resulting image

> from disk image.  Results were the same.

>

> 2.  I then disconnected the harddisk from the SATA to USB adapter and

> connected the harddisk directly to the x86 box to boot it.

>

> The problem remains, there are always a handful of binaries that are corrupted

>

> QNX 6.6.0

>   6fa000   2c75  8049090      --- proc/boot/sloginfo=/opt/qnx660/target/qnx6/

> x86/bin/sloginfo

>   6fd000   a94a  804a024      --- proc/boot/devb-umass=/opt/qnx660/target/qnx6

> /x86/sbin/devb-umass

>   708000  2136d  804af94      --- proc/boot/io-usb=/opt/qnx660/target/qnx6/x86

> /sbin/io-usb

>

One other thing, any binaries after these locations (as well as before) are fine.

>

> Thanks

> Kevin

post111970: Re: mkifs corrupts io-hid, one binary before and one binary after

Kevin Stallard — Sat, 04 Oct 2014 22:01:20 GMT

Okay, after several days of additional investigation and such here is where I am :

1.  I eliminated the possibility that it was the medium I was using to boot the x86 box.  I was using a USB stick formatted using mkqnx6fsimg in combination with the new diskimage utility.  If found a SATA to USB adapter, conencted a laptop harddisk to my Ubuntu host, and QNX 6.5 VM.  I used these hosts to format and load the harddisk with the images.  I both formatted the HD using the mkqnx6fs utility on QNX 6.5 and just copied the resulting image from disk image.  Results were the same.

2.  I then disconnected the harddisk from the SATA to USB adapter and connected the harddisk directly to the x86 box to boot it.

The problem remains, there are always a handful of binaries that are corrupted.

3.  I then started to build using QNX 6.5 utilities.  While the corrupted files were different, the problem remained.

After a bunch of trial and error I found that the corrupt files always reside in the range of 6f9000 and  710000.  For example, the following files are corrupted:

QNX 6.5.0

  6f9000   1d0f  8048668      --- proc/boot/umount=/opt/qnx650/target/qnx6/x86/bin/umount

  6fb000   fc12  80492c8      --- proc/boot/pci-bios=/opt/qnx650/target/qnx6/x86/sbin/pci-bios

  70b000  657d1  8048a18      --- proc/boot/pci=/opt/qnx650/target/qnx6/x86/usr/sbin/pci

QNX 6.6.0

  6fa000   2c75  8049090      --- proc/boot/sloginfo=/opt/qnx660/target/qnx6/x86/bin/sloginfo

  6fd000   a94a  804a024      --- proc/boot/devb-umass=/opt/qnx660/target/qnx6/x86/sbin/devb-umass

  708000  2136d  804af94      --- proc/boot/io-usb=/opt/qnx660/target/qnx6/x86/sbin/io-usb

4.  This range of corruption is the same no matter what x86 box I boot.  I've tried several, all different motherboards and ram combinations, the problem is the same.

Any ideas on what I can do to fix this?

Thanks

Kevin

post111965: Re: mkifs corrupts io-hid, one binary before and one binary after

Kevin Stallard — Fri, 03 Oct 2014 07:34:57 GMT

Followup:

I checked my installation of QNX660 SDP, the binaries are fine.

If I change the order they are included in the build script, they work, and the ones that took their place don't.

I know this should tell me what is going on, but the only thing I can think of is that the image file system is being loaded into RAM, the checksum taken, it passes and then it is copied somewhere else where pot hole in memory exists thus the apparent dependency on location.....wait...isn't that a real-estate thing?

--Kevin

post111964: mkifs corrupts io-hid, one binary before and one binary after

Kevin Stallard — Fri, 03 Oct 2014 03:42:32 GMT

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...

post111957: Re: QNX SDP 6.6.0 on SUSE Linux

Vincent Wan(deleted) — Thu, 02 Oct 2014 16:44:16 GMT

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.

post111950: Re: Corrupted File System detected when using mkqnx6fsimg

Kevin Stallard — Wed, 01 Oct 2014 19:45:43 GMT

Interesting, thanks for the feedback on this.

I just changed the way I do this to sectors and it worked without modification.  I know it was one of the things I tried, not sure why it didn't work.

So, I guess I concur, we don't need the num_blocks functionality :)

Thanks Thomas,

Kevin

On Oct 1, 2014, at 12:39 AM, Thomas Haupt <community-noreply@qnx.com> wrote:

> Mea culpa, I think.

>

> You wrote:

>> 1.  The file size wasn't matching the C*H*S*sector_size, even though I

>> was using the right parameters in the blksize and num_blocks attributes.

>> An additional 15872 bytes were being added to the resulting image.  I

>> modified the attributes so that the block size was reduced that amount

>> and ti worked (reduced it by 32 blocks of blksize=512).

>

> When I originally implemented mkqnx6fsimg, I didn't realize that an explicit "num_blocks" attribute would, at best, be mostly useless and usually and up badly confusing or even irritating the user - which is definitely nothing a good tool should do. The problem with num_blocks is that, as you have indirectly noticed, the net size of a QNX6 file system is greater than just the combined sum of its (data) blocks. It also contains some metadata (a "boot" and two "super" blocks) that will alone take up ~16k . Upon realizing how intricate it actually was to create an image of defined size using this attribute, I first tried to account for this by better documenting the relation between block- and sector count, but by now I've come to believe it'll probably be best to completely remove the "num_blocks" attribute to avoid any further confusion.

>

> Instead, one should _always_ use the "num_sectors" attribute to define the file-system size. The relation between sector count and actually usable data space in the file system isn't much worse than for the block count, but num_sectors at allows you to tell exactly how many sectors the resulting image will take up. The tool will automatically account and adjust for "odd" sector counts, so you don't have to worry about sector counts that aren't exact multiples of the block size. Instead, just look at your target media's/partition's sector count and put that into the build file.

>

> Best regards, and my sincere apologies for wasting your time with this useless feature:

> Thomas

>

>

>

> _______________________________________________

>

> General

> http://community.qnx.com/sf/go/post111939

> To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com

post111939: Re: Corrupted File System detected when using mkqnx6fsimg

Thomas Haupt — Wed, 01 Oct 2014 06:39:54 GMT

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

post111928: Re: Corrupted File System detected when using mkqnx6fsimg

Kevin Stallard — Tue, 30 Sep 2014 12:06:42 GMT

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!

post111925: Re: Corrupted File System detected when using mkqnx6fsimg

Kevin Stallard — Tue, 30 Sep 2014 04:00:53 GMT

Well, shoot, this is addressed to all, not just the talented Northern CA FAE.....

> Hi Hasnat,

>

> I'm having trouble getting this utility to create a qnx file system that I can

>  mount.  I understand that the build script for the utility must specify the

> exact size of the partition it is going to be copied to, but as much as I've

> tried I get a corrupted file system error every time I try to nount it.

>

> The steps I take are:

>

> 1.  Partition a USB drive use fdisk under qnx

> 2.  Use the attached build script and run mkqnx6fsimg (in linux).

> 3.  DD the resulting file to my USB stick.

> 4.  In Qnx start devb-umass and mount -t qnx6 /dev/hd1t179 /fs/qnx6

> 5.  ls /fs/qnx6

>

> Result: Corupted file system detected.

>

> The USB Stick partition specifics are:

> Cyls: 975

> Heads: 255

> Sec/Trac: 63

>

> Partition starts on Cyl 1 and ends on Cyl 200

>

> Thanks

> Kevin

post111924: Corrupted File System detected when using mkqnx6fsimg

Kevin Stallard — Tue, 30 Sep 2014 03:54:54 GMT

Hi Hasnat,

I'm having trouble getting this utility to create a qnx file system that I can mount.  I understand that the build script for the utility must specify the exact size of the partition it is going to be copied to, but as much as I've tried I get a corrupted file system error every time I try to nount it.

The steps I take are:

1.  Partition a USB drive use fdisk under qnx

2.  Use the attached build script and run mkqnx6fsimg (in linux).

3.  DD the resulting file to my USB stick.

4.  In Qnx start devb-umass and mount -t qnx6 /dev/hd1t179 /fs/qnx6

5.  ls /fs/qnx6

Result: Corupted file system detected.

The USB Stick partition specifics are:

Cyls: 975

Heads: 255

Sec/Trac: 63

Partition starts on Cyl 1 and ends on Cyl 200

Thanks

Kevin

post111923: Re: How do I create a file system image using 'mkqnx6fsimg', which is bootable?

Kevin Stallard — Tue, 30 Sep 2014 03:40:55 GMT

In examining the output of the mkqnx6fsimg, it appears that the utility is including the boot loader.

Also if you map /.boot/some_image = some_image.img it doesn't complain.

However, I am having trouble getting the file system to mount...

Kevin

post111902: RE: RE: QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target

Mario Charest — Fri, 26 Sep 2014 21:05:54 GMT

Dinkum is not supply with 4.8.3, you must use gnu ( libstdc++.so ), sorry should have mentioned that.

QNX Support offered to build me a version of the Dinkum libs, but I declined, switching to libstdc++ turned out to be positive for us. Had I known I would have switch to it earlier.

-----Message d'origine-----

De : Anton Indrawan [mailto:community-noreply@qnx.com]

Envoyé : 26 septembre 2014 16:13

À : general-toolchain

Objet : Re: RE: QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target

Hi Mario,

Thanks for your information.

However, the libcpp.so under the GCC 4.8.3 seems to intentionally be pointing to a non-existent file. I am not sure if I can take it from the standard QNX 6.5 toolchain. I will give it a try later.

Best regards,

Anton

_______________________________________________

General

http://community.qnx.com/sf/go/post111901

To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com

post111901: Re: RE: QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target

Anton Indrawan(deleted) — Fri, 26 Sep 2014 20:13:07 GMT

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

post111882: Re: RE: QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target

Mario Charest — Thu, 25 Sep 2014 17:04:34 GMT

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.

post111881: Re: RE: QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target

Anton Indrawan(deleted) — Thu, 25 Sep 2014 16:52:38 GMT

Hi Mario,

Will this work on a standard QNX 6.5 target?

I don't make the target image, so I don't really know if this would work.

Best regards,

Anton

post111880: Re: QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target

Anton Indrawan(deleted) — Thu, 25 Sep 2014 16:50:34 GMT

Hi Ryan,

This works well. Thank you.

Best regards,

Anton

post111858: Re: QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target

Ryan Mansfield(deleted) — Wed, 24 Sep 2014 01:27:15 GMT

On 14-09-22 05:08 PM, Anton Indrawan wrote:

> @Ryan:

> Anton: I tried the following command

> QCC -Vgcc_ntoarmv7le -Bstatic -lcpp -Bdynamic helloworld.cpp

>

> but the resulting binary still contains a dependency to the shared libcpp library.

>

>    Tag        Type                         Name/Value

>   0x00000001 (NEEDED)                     Shared library: [libcpp.so.5]

>   0x00000001 (NEEDED)                     Shared library: [libc.so.3]

>

> I am not sure how I can just statically link to the static libcpp library.

> Could you also reproduce it?

When you link C++, qcc automatically links against libcpp. You should

specify -nostdlib++. e.g.

$ qcc  math.cpp -Bstatic -lcpp -lcxa -lm -Bdynamic -nostdlib++

$ ntox86-readelf -d a.out | grep NEEDED

  0x00000001 (NEEDED)                     Shared library: [libc.so.3]

One problem you might hit trying to get 6.6.0 binaries to run on 6.5.0,

is that everything is built is with -fstack-protector, which relies on

support in libc. This wasn't in the 6.5.0 libc but IIRC, 6.5.0SP1 added.

Regards,

Ryan Mansfield

post111831: RE: QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target

Mario Charest — Mon, 22 Sep 2014 21:53:46 GMT

-----Message d'origine-----

De : Anton Indrawan [mailto:community-noreply@qnx.com]

Envoyé : 22 septembre 2014 17:09

À : general-toolchain

Objet : Re: QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target

>@Mario: If I could use the QNX 6.6 toolchain for building binaries (at least with statically linked libcpp library)

>which can be deployed on a QNX 6.5 target, it would save me lots of linking time. In my case, linking my big app

> using the QNX 6.5's ld takes ~15-20 minutes or even more, while using QNX 6.6's ld is much faster.

> I am not sure how fast it is, but it won't take longer than 5 minutes.

Can't you just use 4.8.3 and the bin utils for 6.5.0 ?

Thanks,

Anton

_______________________________________________

General

http://community.qnx.com/sf/go/post111830

To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com

post111830: Re: QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target

Anton Indrawan(deleted) — Mon, 22 Sep 2014 21:08:44 GMT

> On 14-09-22 03:54 AM, Anton Indrawan wrote:

> > Hi guys,

> >

> > I understood that binaries produced by QNX 6.5 toolchain will work on QNX 6.

> 6 targets. I was wondering whether the other way around would work. So, I

> created a hello world application which basically does a printf, compiled with

>  QNX 6.6's QCC, deployed on a QNX 6.5 target and that worked. However, when I

> was using std::pow, it threw a memory fault.

>

> Running newer binaries on older versions of the OS might work, but it's

> not guaranteed to work so it's an unsupported use case.

>

Anton: Thanks for your reply. I will take that input into account.

> > Note: I statically linked the program against libcpp and libm using the -

> Bstatic option. Can somebody confirm that this is the right way to statically

> link to the static libcpp library.

>

> Yes, but leaving it without a -Bdynamic, means the -lc that the compiler

> drivers automatically link in will be statically linked as well. If you

> want to create a full static binary, then you should link with -static.

> If you still want dynamically linked program, you need to link against

> libc.so, in which case you should to do, -Bstatic -lcpp -Bdynamic

>

> Regards,

>

> Ryan Mansfield

>

@Ryan:

Anton: I tried the following command

QCC -Vgcc_ntoarmv7le -Bstatic -lcpp -Bdynamic helloworld.cpp

but the resulting binary still contains a dependency to the shared libcpp library.

  Tag        Type                         Name/Value

0x00000001 (NEEDED)                     Shared library: [libcpp.so.5]

0x00000001 (NEEDED)                     Shared library: [libc.so.3]

I am not sure how I can just statically link to the static libcpp library.

Could you also reproduce it?

@Mario: If I could use the QNX 6.6 toolchain for building binaries (at least with statically linked libcpp library) which can be deployed on a QNX 6.5 target, it would save me lots of linking time. In my case, linking my big app using the QNX 6.5's ld takes ~15-20 minutes or even more, while using QNX 6.6's ld is much faster. I am not sure how fast it is, but it won't take longer than 5 minutes.

Thanks,

Anton

post111819: RE: QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target

Mario Charest — Mon, 22 Sep 2014 14:18:57 GMT

Why would you want to do that ?

-----Message d'origine-----

De : Anton Indrawan [mailto:community-noreply@qnx.com]

Envoyé : 22 septembre 2014 03:55

À : general-toolchain

Objet : QNX SDP 6.6 binary compatibility on a QNX SDP 6.5 target

Hi guys,

I understood that binaries produced by QNX 6.5 toolchain will work on QNX 6.6 targets. I was wondering whether the other way around would work. So, I created a hello world application which basically does a printf, compiled with QNX 6.6's QCC, deployed on a QNX 6.5 target and that worked. However, when I was using std::pow, it threw a memory fault.

Here is the test code:

#include <stdio.h>

#include <math.h>

int main()

{

  double result = std::pow(2.0, 2);

  printf("Result: %lf\n", result);

  return 0;

}

Compile with: QCC -Vgcc_ntoarmv7le -Bstatic -lcpp math.cpp -lm.

Note: I statically linked the program against libcpp and libm using the -Bstatic option. Can somebody confirm that this is the right way to statically link to the static libcpp library.

Best regards,

Anton

_______________________________________________

General

http://community.qnx.com/sf/go/post111814

To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com