icc 13 + Xcode 4.6.2 Invalid object files, bug?

icc 13 + Xcode 4.6.2 Invalid object files, bug?

Hi All

I'm using ICC for OSX (m_ccompxe_2013.3.171.dmg) with Xcode 4.6.2 and I've a problem:

- if "Generate Debug Info" = on, then all is Ok. However, if off, then link fails. Looking undersolved symbols I've noticed that corresponded object file (.o) is invalid and always has length 152 bytes. Changing source I force recompiling and .o file becomes Ok, but the issue repeats at next rebuild. What am I doing wrong? Or it's a bug?

Thanks

7 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Could you post a linker output, please?

Hi, Sergey, thx for your input

The link output is in attached zip. There is also invalid (.o (bad)) file (size 152) that produces unresolvеd(s). When I check the source, then a normal file is compiled (.o (good)), and other link errors produced (with next invalid .o), When I clean prj and rebuild from scratch - all happens again, and other .o files are invalid. The problem disappear if I set "Generate Debug Information" = on

Attachments: 

AttachmentSize
Downloadapplication/zip icc-errorinfo.zip7.27 KB

Hi,

>>...Looking undersolved symbols I've noticed that corresponded object file (.o) is invalid and always has length 152 bytes.
>>Changing source I force recompiling and .o file becomes Ok, but the issue repeats at next rebuild. What am I doing
>>wrong? Or it's a bug?

I see that there are only linker errors, like:

...
Undefined symbols for architecture i386...
...

It is clear that a library, for some Camera API, is "missing" for i386 architecture during your 1st attempt to build an executable. I admit that something is wrong and please review project linker settings for that configuration.

>>...The problem disappear if I set "Generate Debug Information" = on...

That looks like some internal problem with a linker.

>> That looks like some internal problem with a linker.

IMO linker must fail if it receives corrupted .o files (junk in - junk out)

>>>> That looks like some internal problem with a linker.
>>
>>IMO linker must fail if it receives corrupted .o files (junk in - junk out)

Try to do a test:

- Create a simple C/C++ project that uses one library ( any )
- Write a simple code that calls at least one function from the library
- Corrupt the library ( in editor, for example )
- Try to build an executable
- Post an error message from a linker for review

Thanks in advance.

>> Try to do a test:

What is such test for? To prove that link fails with corrupted lib? I agreed 100% even without any test :-) Here I know why produced lib is incorrect - because some sources aren't compiled properly. Sorry if I've not explained this well.

Leave a Comment

Please sign in to add a comment. Not a member? Join today