1.1.1 Compiler not working correctly


#1

Hi,

Has anyone hit compiler issues with 1.1.1. I have a large project and I’m getting lots of stupid error messages that cannot possibly relate to the line referenced, also lots of “previous definition of ‘XXXXXXX’ was here” messages. These ones seen to be GCC issues. The pre-processed sources seem to look OK.

Has anyone got a large multi file project compiling with 1.1.1 ?

Regards,
Gavin.


#2

Maybe a path length issue with your M2M Studio install path and/or your project path?
GCC can behave quite randomly under Windows when handling paths lengths greater than 255 characters.
Did you compiled your project successfully with a previous M2M Studio version?
Thanks.


#3

That sounds like a big issue - because M2MStudio makes a habit of creating excessively long paths!! :open_mouth:

For example,

C:\OpenAT\OAS231\M2MStudio\1.1.0.200908120848\m2mstudio\dropins\com.wavecom.openat.ide.spm.lib.os.model.6.31.0.03\resources\doc

I have had problems with other tools that are overwhelmed by such path lengths!


#4

This issue exists since M2M Studio 1.0.0, and until today (if this thread is really concerned by this issue), we never got feedbacks about it.
So from our point of view this is obviously a limitation, but not many users seems to be concerned by it.

To be completely exhaustive, here are the configurations where you can have path length issues (only under Windows):

  • GCC and/or MinGW compiler root path exceeds 150 characters. This can be configured in Window > Preferences > M2M Studio > Tools paths. Since by default these compilers are unpacked in the “tools/{name}/{version}” sub-directory of M2M Studio, this means that you should have path length issues if your M2M Studio installation path exceeds 130 characters
  • You may have issues if you use include paths located in your workspace, if your workspace path is too long. It depends on your projects and relative include paths name lengths, but we can reasonably consider that 200 characters should be a maximum for the workspace path
  • Include paths are referenced also from the installed packages location. Considering the offset for a given package, the path to this installed package registry should not exceed 140 characters. By default, this path is the “dropins” sub-directory of M2M Studio; this gives almost the same limitation for M2M Studio installation path than for the compilers (see first point)

Please not that all proposed default paths for installation and workspaces are far below these limitations. You should only take care of the path length if you configure your own path.


#5

Hi,

It’s not a path length problem – the paths added are very short, and way below the limits suggested. I’ve also setup a completely virgin machine and installed a fresh 1.1.1 on it, and get the same problem.


#6

It seems to be a GCC bug, and it is mentioned (July 2008) – sort of – in the the GCC Bugzilla, but 4.0.1 (or 4) is so out of date it’s hard to tell. Is there any reason why the GCC version has to be so old ?


#7

Only kept for compatibility with legacy packages built with this version since 2 or 3 years. By the way, support of an additional new GCC is planned for next release.

To get back to your issue: do you have other GCC installs on your system which may disturb the M2M Studio’s one?
Do you have some GCC specific environment variables set (C_INCLUDE_PATH and others…)?


#8

I have never used GCC before on the two machines I’ve been testing on. Checked all install paths, env vars etc.

The error I get makes no sense, and looking at a preprocessed file doesn’t help – it all looks OK.

What I see is in two areas;

I see function calls where the error is flagged on the next line as “previous definition of ‘XXXXXXX’ was here” where XXXXXX is the function name.
The prototype in the header file is flagged with the same error message.

Example;

void setPort(wip_in_addr_t hash)
{ <<= error on this line
if (s_port == PORT_MIN)
… more code …
}

The header file prototype looks like;

#ifdef MAIN_FILE_TCPSERV
#define EXTERN
#else
#define EXTERN extern
#endif

EXTERN void setPort(wip_in_addr_t hash); <<= this line also flagged with the same error.

The header file has the usual mechanisms to stop repeated loading of it, however this problem occurs at the compiler level, not linker.

After about a dozen of these error messages the compiler loses it’s brain completely and every line after that point is an error – then it gives up

The source code is very sensitive, so sending it to you doesn’t work. I was getting some issues with 2.30, so decided to update, and I need to generate code for Q26 Extreme (not yet – this is for 2686 right now)

I’ve started with an empty project and am moving the source over small block at a time to see if I can spot what triggers this.


#9

Did you use the same compilation environment when your project was using 2.31?

Please keep us informed if you get the information… Cannot help without a piece of source code which reproduces the issue…


#10

It might help if I knew EXACTLY what “previous definition of ‘functionXXXXXXX’ was here” means, where the message is reported both on a function prototype and the function code itself, and the function is not mentioned anywhere else. GCC (poor at best) error message documentation seems very light on this one…

G.


#11

I usually get that message where the implementation doesn’t match the prototype.
Or where a function is referenced without being declared, so the compiler assumes it returns int (per standard) - and then the compiler finds a real definition which returns something other than int.

In the actual compiler output, these would appear in order - making it clear(er) what’s happening:

  • First, the “assumed int” message;
  • later, a “doesn’t match previous definition” message;
  • immediately after that, the “previous definition was here” message

But M2MStudio re-orders the messages in the ‘Problems’ view - so that related messages appear neither in order nor together!!
IMO, this is a really counter-productive feature! :angry:

If this is actually what’s happening for you, then you might find it more helpful to look at the actual compiler output in the ‘Console’ view…


#12

See: viewtopic.php?f=78&t=4284


#13

I was aware of this – after a while it becomes “obvious”, but even with --verbose on I’m not seeing sensible error messages. I’ll check more carefully…


#14

Found the little horror…

A mismatched “)” a 1000 lines after the mass of error messages started. As the total build generated 8000 lines of output before the compiler gave up, it was a little hard to find. Guess I’m not used to compilers that generate errors before the line with the actual error on it.

Thanks for all the help.