• Scott Michel <scottm aero.org> Nov 29 2005
• "Walter Bright" <newshound digitalmars.com> Nov 29 2005
• Scott Michel <scottm aero.org> Nov 29 2005
• "Walter Bright" <newshound digitalmars.com> Nov 29 2005
• "W³odzimierz Skiba" <abx abx.art.pl> Nov 30 2005

Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Walter:

I've tracked down a minor discrepency between DMC++ invoked from inside 
of the CodeBlocks IDDE and DMC++ invoked via smake in the cmd box. The 
object files generated via CodeBlocks end up with two extra bytes, which 
appears to make everything work. When compiled under smake/cmd, however, 
the two extra bytes don't show up (and this may be the cause of the 
optlink bug I posted earlier.) Same command line arguments to each 
invocation of the compiler.

Attached is a (slightly truncated) diff file that shows the problem. The 
two extra bytes ocur at offset 0x4ce -- the diffs following this are 
merely offset from each other by those two bytes. The "obj1" file is 
generated via CodeBlocks IDDE, the "obj2" file is generated via smake/cmd.

Hope this helps...


-scooter

"Scott Michel" <scottm aero.org> wrote in message
news:dmiljd$2bn7$1 digitaldaemon.com...
 Hope this helps...


Unfortunately, there's nothing I can do without a reproducible test case.

Walter Bright wrote:
 "Scott Michel" <scottm aero.org> wrote in message
 news:dmiljd$2bn7$1 digitaldaemon.com...
 
Hope this helps...


 
 Unfortunately, there's nothing I can do without a reproducible test case.


It's very reproducable on my laptop... :-)

All seriousness aside, I'm at a loss on how to reproduce the problem 
such that it makes sense to you to diagnose the compiler. The best I 
could do was to diff the output from dumpobj, in the vain hope that you 
might be able to map the object records back to their producer, 
specifically the PUB386 record that seems to be causing the problem.

If you're feeling up to it, the source I was compiling is the 
\dm\samples\win32\opengl\demos\stonehng code. The dumpobj output was 
produced from the atmosphe.cpp source (although, in some way, shape, and 
form the other object files are similarly afflicted.)

Alternatively, are there stale DLLs that might be causing the problem? 
Does smake do something strange to invoke dmc versus CodeBlocks, which 
doesn't do anything particularly special?

Frankly, it's kind of a show stopper for me and a frustrating one too.

"Scott Michel" <scottm aero.org> wrote in message
news:dmivtd$2jdj$1 digitaldaemon.com...
 All seriousness aside, I'm at a loss on how to reproduce the problem
 such that it makes sense to you to diagnose the compiler. The best I
 could do was to diff the output from dumpobj, in the vain hope that you
 might be able to map the object records back to their producer,
 specifically the PUB386 record that seems to be causing the problem.

 If you're feeling up to it, the source I was compiling is the
 \dm\samples\win32\opengl\demos\stonehng code. The dumpobj output was
 produced from the atmosphe.cpp source (although, in some way, shape, and
 form the other object files are similarly afflicted.)

 Alternatively, are there stale DLLs that might be causing the problem?
 Does smake do something strange to invoke dmc versus CodeBlocks, which
 doesn't do anything particularly special?


I have no idea what CodeBlocks is.

The thing to do, as always, is to take the source code and cut it down to
the minimum that reproduces the problem.

"Walter Bright" <newshound digitalmars.com> wrote in
news:dmjd6j$2s8d$1 digitaldaemon.com:
 I have no idea what CodeBlocks is.


It's IDE written with wxWidgets. Looks like main www.codeblocks.org site has 
bandwith problem so look at least at http://codeblocks.tigris.org/

ABX