I'm working with GT.M source code and read this information in mumps.hlp file :
ZCOMpile
The ZCOMPILE command invokes the GT.M compiler from within the GT.M
run-time environment.
Within GT.M itself, ZCOMPILE provides the functionality of the
mumps command, except for mumps -direct.
So...which compiler to be using in "mumps -direct" mode , which file store source code for this compiler ?
I mean that ,when you type :
GTM> SET ^FOO="BAR"
Which compiler responsible for compiling that command
Ryo,
It's compiled in memory. It's not stored in any file.
--Sam
Related
I'm trying to open a simple file open dialog in Tcl/Tk but whenever I run tk_getOpenFile I get the following error:
invalid command name "::tk::dialog::file::"
while executing
"::tk::dialog::file:: open {*}$args"
(procedure "tk_getOpenFile" line 5)
invoked from within
"tk_getOpenFile"
(procedure "open" line 2)
invoked from within
...
I'm running the latest version of Tcl/Tk, 8.6.9, from the Arch Linux repositories. What could be causing this?
It looks like a broken installation somehow. The procedure tk_getOpenFile in …/tk.tcl (where … is where Tk's library files are installed) delegates to the procedure ::tk::dialog::file:: in …/tkfbox.tcl (yes, an unusual procedure name), but that doesn't seem to be working in your case. Either the file is missing, or the tclIndex file in the same directory is broken. (That's using an old mechanism for auto-loading of code that doesn't really make sense for new code to use in… well, in this millennium. It's kept for backward compatibility.)
i am working on ns-allinone-2.35 . and i modified the aodv protocol that located on /ns-allinone-2.35/ns-2.35/aodv folder. i do make clean , then make, every thing is ok.
but i notice that no changing in the result.
and i notice that if i change all aodv code to comments, the TCL file will running even if delete the aodv.o.
can any one help to specify exactly where is the changing on ns-allinone-2.35? and from where the TCL file read the routing protocol?
»»
the TCL file will running even if delete the aodv.o
««
Files{.cc, .h, .o}, etc. in the ns-2.35/ folder are not used at simulation time. ( Exceptions : Some simulations can/will use some traffic files, e.g. from tcl/mobility/** ).
All functions from the c++ files (and tcl/lib/files*) are compiled into one file : 'ns'.
Files used by the executable 'ns' are the these only :
ns-allinone-2.35/{ lib/**, bin/tclsh8* }.
Changes : Be aware that ns2 speaks "otcl". And that all the (o)tcl functions in tcl/lib/ are also compiled into the executable 'ns'.
So may be your new function is missing in tcl/lib/{ files.tcl } ?
I have several versions of a project checkout out and compiled. If I spot an error, I compare the versions to narrow the problem down. Sometimes I enable sanitizers like the AddressSanitizer. If I re-use an executable, I don't remember whether it was compiled with the sanitizers or not. If the executable works fine, I am not sure whether the bug is not there or whether I did not include the sanitizer in this build. So I have to reconfigure and rebuild to make sure I have the sanitizer included.
Is there a way to check whether an executable has been compiled with a sanitizer?
Address sanitizer can also be compiled statically with the -static-libasan option in GCC. Statically compiling address sanitizer is the default mode in Clang.
If you compile address sanitizer statically then it is obviously not possible to use ldd to verify if your binary is sanitized or not. In this case I use nm and check if there are sanitizer symbols in the binary:
nm -an <executable> | grep asan
You need to use __has_feature(address_sanitizer), see http://clang.llvm.org/docs/AddressSanitizer.html (same for other sanitizers).
From man ldd:
ldd prints the shared libraries required by each program or shared library specified on the command line.
As long as address sanitizer requires to link with libasan.so library (actual implementation of sanitizer) you can assume:
If ldd won't print shared lib libasan.so it definitely means that address sanitizer is turned off.
If ldd will print shared lib libasan.so it means that your linker flags includes -lasan, otherwise you`ll get unresolved symbol error during linking. Highly likely that address sanitizer is enabled, unless you have a bug in building system.
Third option if you have bug in your building system. ldd will print libasan.so but address sanitizer will be turned off if you passed to linker -lasan , but didn't pass -fsanitize=address. It means that you linked your executable with address sanitizer but didn't include checks into your executable.
Or you can do objdump -p to see if libasan.so is needed in dymanic sections: NEEDED libasan.so.0. objdump could give the same(and more) information as ldd.
I am trying to access the WinRT sensors from a Win32 desktop application using C++/CX as mentioned here: https://software.intel.com/en-us/articles/using-winrt-apis-from-desktop-applications
When I include the C++/CX header file it causes an error when building the Win32 project.
Exact error text: "error C1190: managed targeted code requires a '/clr' option."
Since I am not using /clr code at all, this is a confusing error.
Any suggestions? Please educate me if there is a better way to do this.
The error you are getting is because you are compiling some files without /ZW option for compiler. Since you are able compile at least some files with WinRT extensions, but not others, your project configuration is inconsistent.
The option /ZW (enable WinRT extensions) has to be configured on the level of project (and not on the level of individual files). There are two ways to ensure your settings are consistent. First method is through UI in Visual Studio -- you have to go through all platforms/configurations on the project and ensure /ZW is enabled, then got through all indivudual .cpp files, and ensure they don't override project level settings. This is tedious and error prone. The easier method is to open .vcxproj in notepad and do the following:
Add this section at the beginnig of the file, under root Project node:
<ItemDefinitionGroup>
<ClCompile>
<CompileAsWinRT>true</CompileAsWinRT>
</ClCompile>
</ItemDefinitionGroup>
Search and remove any other places where <CompileAsWinRT> is defined.
In C there is no main program. Sure, C programmers begin with int main(int argc char *argv[]), but this only works because there is a routine that tells the compiler/IDE to run the function named main first.
I can't seem to find this routine in MinGW, though. Where is it defined? I just searched because I wanted to change it (only as a test) and play around with it a bit. Can someone link me to the correct file in the MinGW folders?
The ld linker will look for a match of one of several symbols to use as the entry point when linking a PE file:
entry point subsystem
--------------------- --------------
NtProcessStartup native
WinMainCRTStartup Windows GUI
mainCRTStartup Windows CUI (console)
__PosixProcessStartup POSIX CUI
WinMainCRTStartup WinCE GUI
mainCRTStartup Xbox
mainCRTStartup other
DllMainCRTStartup#12 (or possibly DllMainCRTStartup) for DLLs
MinGW will have an object file that gets automatically linked in that has the actual PE entry point. - you can see what object files are being automatically linked in by using gcc's -v option.
In a quick test using MinGW 4.6.1 building a console subsystem "hello world" program, the object file containing the entry point is crt2.o and it has a symbol mainCRTStartup that is picked up by the linker as the entry point.
The source file containing the entrypoint code is crtexe.c (or crtdll.c).
You can override the entry point using the --entry option to the linker (Wl,--entry=whatever when used on the gcc command line).