Problem creating library using Momentics IDE

QNX USERS QNX6 - OS
1

Hi,

I’m newly trying to use the Momentic’s IDE workspace to edit and compile in after having used Photon/shell development for years but I’m having a problem building a library.

My system consists of:

Momentics IDE, SP2 installed on XP Pro
QNX 6.3 SP2 target machine.
The QNX drive mounted via Samba as a Windows drive so the IDE can see the makefile/source code which resides on the QNX machine.

Now when I go to photon from a shell I can run ‘make clean’ followed by ‘make’ and it builds my exe without any trouble (compiles, builds libraries and links).

However, from the IDE it fails. It does the ‘make clean’ fine and then compiles everything OK including doing all the recursive make calls, directory changes, file copies etc but fails to generate libraries and so it fails the link phase.

This is the line in the makefile that is being executed (I am building a library)

ar crv objects/common.a objects/Logger.o objects/Mutex.o objects/Thread.o objects/Timer.o

This is the error the IDE generates

invalid OMF record length 19525
invalid OMF record length 19525
invalid OMF record
invalid OMF record length 19525
invalid OMF record length 19525
invalid OMF record

repeated a few more times for each .o file.

So it looks to me like my .o files are being generated incorrectly by the Momentics IDE compiler (wrong format maybe???)

When I compiled under QNX and I do an ls -l on Logger.o I get a file size of 205392
When I compiled under Momentics IDE and I do an ls -l on Logger.o I get a file size of 206884

This looks like there is some kind of fundamental file format problem (the compiler version/options are specified in the Makefile itself as GCC 3.3.5 so unless Momentics adds something on it’s own to a standard ‘make all’ command I don’t know why they are different). This is troubling because it makes me think if later on I build 1/2 the files under Momentics IDE and 1/2 under QNX shell environment they may not link properly or may have other problems of different sizes of objects at run time (anyone know if this is true?).

My Make target under the IDE is just target name of ‘all’ and I use a make target of ‘all’ with the default setting.

Could it be because the ‘ar’ command is different under the Windows install of IDE than the native one on QNX 6.3?

I created my project under Momentics as a ‘standard Make C/C++ project’ since I already had existing code and make environment and then pointed the path to the code on the QNX drive.

My ‘Set QNX Build environment’ is GNU 3.3.5 compiler, C++ Dunkum with exceptions, x86 and I didn’t do anything with the environment settings (maybe something here?).

My makefile CC/CFLAGS like looks like:

CC = qcc -V3.3.5,gcc_ntox86_cpp
CFLAGS = -lang-c++ -D_PTHREADS=1 -g -w8 -Wall -Werror -Wno-deprecated -Wp,-MD

this gets read by the Momentics IDE and make on the QNX box (the both issue the exact same compile lines) and neither complains so it should be using the same compiler and header files etc which is why the size of the objects being different worries me…

Anyone else experienced anything like this trying to build a library under using the IDE?

TIA,

Tim

2

I solved the problem with the linker (ar).

It was pointed out to me that QNX uses ELF object files and not OMF files. So the ‘ar’ call in my Makefile was referencing Visual Studio’s ar command and not the QNX one. Once I changed my makefile to instead do

qcc -Vgcc_ntox86 -A

it compiled and built the libraries.

So if anyone else encounters this problem with using the IDE it will hopefully point them in the right direction.

HOWEVER,

the problem I reported of .o files being different sizes still remains. Ie.

When I compile under QNX and I do an ls -l on Logger.o I get a file size of 205392
When I compile under Momentics IDE and I do an ls -l on Logger.o I get a file size of 206884

Has anyone else ever tried compiling their code base using the IDE and native shell terminal and noticed this? It makes me very uneasy to think there could be some kind of internal structure/class differences that will only show up at run time or even worse, cause subtle errors if half a project is compiled with the IDE and another half (or even a few files) with a native shell terminal.

Tim

3

Hi,

yes, there are differences between Windows and native QNX compilations. I have one driver that I can compile under QNX and it works fine. If I compile under Windows, driver crashes!! However, I never bothered to find out why - just use native QNX shell.

Regards,
Albrecht

4

BTW, the differences in file size may be caused by different lengths of paths to the source files. These are sometime stored in the binaries. Don’t know if that is true for libraries.

AU

5

AU,

I thought of that. I was compiled with the optimize flag on to remove any potential paths or debug information being stored.

For example, doing a ‘strings’ on 2 .o files and comparing the differences (and yes, I know there can be many differences besides ASC inside the files but this at least shows any paths) I found:

Mutex::~Mutex()
Mutex::lock()
Mutex::tryLocking()
Mutex::unlock()
SELFUNLOCKINGMUTEX
SelfUnlockingMutex::lock()
SelfUnlockingMutex::unlock()
12a6
Mutex::~Mutex()
13a8
Mutex::lock()
15a11
Mutex::tryLocking()
16a13
Mutex::unlock()
18a16
SELFUNLOCKINGMUTEX
20a19,20
SelfUnlockingMutex::lock()
SelfUnlockingMutex::unlock()
30,31c30
.rodata.str1.1
.rodata.str1.32

.rodata

As you’ll notice, most of this is just the fact that the compilers tended to organize strings for various function names in my class in a different order inside the .o files. However there are some real differences here:

One file has:

.rodata.str1.1
.rodata.str1.32

while the other has

.rodata

Now I am not sure what .rodata is or refers to (I have no variables by that name) but there is a clear difference here that I can’t explain.

Not sure how many non-ASC differences there on top of the ASC ones.

This is what has me concerned about compatibility or if I’m even running the same code if I use the IDE vs compiling directly under Photon/shell.

Tim

6

Hello Tim,

well, I’m not a guru regarding object file format. Maybe .rodata is a special tag inside the ELF format, you’ll have to look up specification for ELF.

As to IDE vs command line: If you build under Neutrino, then I’m relatively sure that IDE and command line yield the same result. It’s the difference between Windows and Neutrino host, if you ask me. Perhaps you can verify that by building on the command line under Windows, which is possible.

Regards,
Albrecht

7

Albrecht,

I didn’t know it was possible to build under the command line on Windows! Can you tell me what I need to do to accomplish this?

I don’t think .rodata is a special tag. I think it’s something else. Also, the difference I showed was just from doing a ‘strings’ diff, not a bitwise diff. The reality is that all the .o files generated with the IDE are 300-1100 bytes larger in size than those created from the command line under Neutrino (my object files are 5-70K in size).

My guess at this point is that there is something set by default in the IDE that I’m not aware of that is affecting compilation. This is why I am eager to do the build from the command line under Windows so that I know the IDE is out of the equation as much as possible.

Thanks,

Tim

8

Tim,

To build “command line” in Windows, just open a cygwin bash shell, cd to where your project root is, and type make (with the necessary arguments). In order to see what arguments you need to provide to make run a build from the IDE and see how it invokes make in the console window.

(and the command line stuff, simply specifies target CPU and variants, and project references, so it does not impact compiler flags at all).

9

Just one more thought about IDE vs command line: Although the IDE uses a similar directory structure to the one created by addvariant and friends they are not compatible. In order to build a project created by the IDE on the command line you have to pass all these PROJECT_ROOT_* etc constants on the command line - in fact the IDE creates a temporary Makefile from the common.mk and all these funny strings and invokes make on that - just watch the output in the console window inside the IDE. I do not know why QSSL did not obey their own rules set out in “Conventions for Makefiles and directories” - maybe it did not fit in the Eclipse framework well or it was too difficult to implement the nice GUIs to configure the build, but it is annoying all the same.

For instance, how can you set up your environmant to do automatic builds over night (in a shell) and use IDE for daily development work?

Of course, if one uses a custom Makefile and directory structure this is of no relevance.

Regards,
Albrecht

10

Yup, the PROJECT_ROOT stuff is for inter-project references, and you can simply make a script to launch make (I do this all the time). I usually have a script named build in my project dir (yes I have to manually update it, but it really isn’t a big deal) then when I want to build from the command line I just type “build”.

11

Albrecht,

I use a custom Makefile. I was not overly enamored with the setup that the IDE provides.

Furthermore, when I attended the IDE training classes at QNX it was highly recommended that for projects you write your own Makefile system (ie the project type you create is a standard C/C++ project) instead of using the IDE one. The only reason we were told that you would want to use the IDE Makefile system was if you are building for multiple CPU targets (ARM, x86 etc)

In any case, I tried typing ‘make’ from a DOS command prompt. Unfortunately it didn’t work because I also have Visual Studio installed and it’s using the VS make utility instead of the QNX IDE one. I looked in the help section and it said to check my ‘path’ and make sure I had a c:\cygwin\bin defined but I didn’t have it. I tried to just do a ‘c:\cygwin\bin\make’ command but there is no such directory. So I’m not sure how to directly invoke the IDE make utility from the command line when Visual Studio is also installed.

Tim

12

Albrecht,

I got tech support involved on this. There is indeed an issue with the Momentic’s IDE suite. Here is the Email I got back:

I’ve just been discussing your issue with one of our compiler
developers and after going over your project it appears that we have
identified a bug in our windows compiler. When building the compiler
on windows, one of the configuration parameters was set differently
than on self hosted versions. The resulting binaries on a
windows-compiled environment will, as a result, use a slightly
different mechanism in exception handling, and consequently the
binaries won’t be exactly the same size as self hosted compiled
binaries.

This is obviously a bug; we’ve entered a problem report describing the
issue so it can be resolved in a future release. From my discussion
with the developer it doesn’t sound like this change is likely to
result in any significant changes in behaviour in your application,
but it is possible that, if you experience problems in exception
handling, that problem might manifest differently on windows compiled
binaries than on self hosted compiled binaries. I don’t believe this
is likely, but it is a possibility.

If you would like, I can have our compiler team provide an updated
binary for windows which will bring that release fully in line with
the self hosted version. This would be an experimental binary,
however, until we can release a formal fix for this bug. Your sales
rep can also give you more information on what we can do to expedite a
fix for this problem if you have concerns about the integrity of your
build process due to this error.

So if your using C++ and doing exception handling (I am) you may encounter differing behavior.

You said you had a driver problem which means you likely aren’t using C++ (tho maybe you are).

Bottom line is there may be more differences that just the example code I sent them that led to this report.

Tim