[gme-users] Compiling issues (pt 2)

Mon Apr 30 09:39:48 CDT 2012

FPO is off by default in VS2010. It is the /Oy- flag. You can configure
it under C/C++>Optimization>Omit Frame Pointers

You should change the email address and remove the http url.

The Java support in GME requires the environment JAVA_HOME (mine is
C:\Program Files (x86)\Java\jdk1.6.0_18). The -v switch to build.py will
reveal the compiler error messages.

Kevin

From: gme-users-bounces at list.isis.vanderbilt.edu
[mailto:gme-users-bounces at list.isis.vanderbilt.edu] On Behalf Of Andrew
N
Sent: Saturday, April 28, 2012 8:01 PM
To: gme-users
Subject: Re: [gme-users] Compiling issues (pt 2)

Thanks a lot for your help so far guys. Do I need to configure a SMTP
server or will just changing the email suffice? To turn off
frame-pointer optimization, should I use the /Oy- flag? I found some
documentation suggesting that but it was pretty old. Finally I'm running
into the wall building the MSI w/ python. Again, apologies for the vague
error message.

Building GME version 12.4.28 x86
0. Check prerequisites (required tools, etc.) ...
Warning: SVN client cannot be found! You won't be able to check in & tag
release
s
1. Update version strings in source files ...
2. Compile GME core components ...
3. Compile MetaGME components ...
4. Compile Java component support (JBON) ...
!!! Build FAILED: step compile_JBON
Traceback (most recent call last):
  File "build.py", line 452, in <module>
    do_step(i, build_steps[i])
  File "build.py", line 321, in do_step
    step()
  File "build.py", line 173, in compile_JBON
    tools.build_VS( sln_file, "Release" )
  File "C:\GME-12.4.20_src\Install\Build\tools.py", line 133, in
build_VS
    subprocess.check_call(args, stdout=(sys.stdout if prefs['verbose']
else nulf
p), stderr=None, shell=True)
  File "C:\Python26\lib\subprocess.py", line 488, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['msbuild',
'C:\\GME-12.4.20_src\\SDK\\J
ava\\native\\JavaSupport.sln', '/t:Build', '/p:Configuration=Release']'
returned
 non-zero exit status 1

On Fri, Apr 27, 2012 at 10:27 PM, Kevin Smyth
<ksmyth at isis.vanderbilt.edu> wrote:

Good point Csaba. Debugging tools for windows has some handy utilities
for dealing with pdbs.

Re: debug versions: the CRT dlls are not redistributable. Compile
release versions without frame pointer optimization to be able to get
stack traces.

The crash reporting is controlled in gmeapp.cpp. You'll want to change
the http URL or use an email address.

Kevin

On Apr 27, 2012, at 9:05 PM, "Toth, Csaba" <csaba.toth at Vanderbilt.Edu>
wrote:

> What I'd also be sure is to include the debug symbol files for each
dll and exe you compile. This way the crashdump reporter can extract
more information at the time of the crash. This is true for both Debug
and Release version of the program. If you install Debug version then
the crash report much likely to be able to unfold the call stack of the
crash (Release often have too much optimization which affects the
stack). But for Debug version you need to include several dlls which are
not present on a non-developer environment.
> Kevin: I cannot remember if there's a registry switch to obtain crash
dump or how that goes now.
>
> You can also try remote debugging.
>
> My bet: You probably have some issue with some dlls or COM components,
if GME dies so soon.
>
> Csaba
> - former developer.
> ________________________________________
> From: gme-users-bounces at list.isis.vanderbilt.edu
[gme-users-bounces at list.isis.vanderbilt.edu] On Behalf Of Kevin Smyth
[ksmyth at isis.vanderbilt.edu]
> Sent: Friday, April 27, 2012 1:57 PM
> To: gme-users
> Subject: Re: [gme-users] Compiling issues (pt 2)
>
> For problems like these, I would use Process Monitor to try to see
what is failing.
>
> Here's my guess:
> GME depends on quite a few ActiveX dlls, which you wouldn't see in
Dependency Walker. GME uses the standard CoCreateInstance method to
create these, which depends on HKCR COM registration data. This
registration data is created by GME.sln (and MetaGME.sln et al) by
running regsvr32 on the various COM dlls. The registration data is
created by GME.msi for installed versions. If you didn't install GME.msi
on your VM, the VM would not have the registration data.
>
> Instead of zipping up anything, I'd use the Install\Build\build.py
build script to build a GME.msi and install that. (You'll need to
install Python 2.6 or 2.7 and WiX 3.5.) That will create all the COM
registration data you'll need (and also compile other required
components, like the MetaInterpreter and MetaDecorator). The msi also
provides uninstall.
>
> If using the msi doesn't help, let me know and I can list some
debugging breakpoints.
>
>
> Also note GME will silently exit on Windows Server Core.
>
> Kevin
>
> From: gme-users-bounces at list.isis.vanderbilt.edu
[mailto:gme-users-bounces at list.isis.vanderbilt.edu] On Behalf Of Andrew
N
> Sent: Thursday, April 26, 2012 7:07 PM
> To: gme-users
> Subject: [gme-users] Compiling issues (pt 2)
>
> I am running into a bit of a roadblock which I'm having difficulty
debugging. Apologies in advance for soliciting help with such a vague
description of the problem, but the reason the description of the
problem is so vague is the same reason I'm having difficulty finding a
solution.
>
> I added a few elements to the IDR_MAINFRAME resource file and compiled
successfully, ran the executable on my local machine and zipped it up to
send out for QA. I got a message saying that the binary, when double
clicked, did nothing. I fired up a brand new VM and saw the same error
happen. I double click the exe,see the hour glass for about 1/4th a
second,then nothing happens. I don't even know how/where to start
debugging it. I threw the bin into IDA to see if it could make heads or
tails out of it and it couldn't either. I tried Dependency Walker too to
no avail. Out of curiosity, I tried building a GME build fresh out of
the source zip file of 12.4.20 -- same problem. This is all being done
in elevated mode with the Release configuration.
>
> I'm guessing this is a compiler flag issue or something or perhaps
something is not being (statically?) linked properly. But I've no idea
as how to debug this issue, and less of an idea as how to fix it.
>
> Any help would be much appreciated.
>
> _______________________________________________
> gme-users mailing list
> gme-users at list.isis.vanderbilt.edu
> http://list.isis.vanderbilt.edu/mailman/listinfo/gme-users
_______________________________________________
gme-users mailing list
gme-users at list.isis.vanderbilt.edu
http://list.isis.vanderbilt.edu/mailman/listinfo/gme-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.isis.vanderbilt.edu/pipermail/gme-users/attachments/20120430/4849e77e/attachment.html 