I wanted to launch the process from firebreath,so I included "boost/process.hpp". Just including this header alone throws compile error.
could some one help?
FireBreath 1.6.1, FireBreath 1.7.0,windows 8
Error:
2>C:\Projects\plugin\FireBreath\src\3rdParty\boost\boost/process/detail/pipe.hpp(129): error C2665: 'boost::system::system_error::system_error' : none of the 7 overloads could convert all the argument types
2> C:\Projects\plugin\FireBreath\src\3rdParty\boost\boost/system/system_error.hpp(39): could be 'boost::system::system_error::system_error(int,const boost::system::error_category &,const std::string &)'
2> C:\Projects\plugin\FireBreath\src\3rdParty\boost\boost/system/system_error.hpp(43): or 'boost::system::system_error::system_error(int,const boost::system::error_category &,const char *)'
2> while trying to match the argument list '(DWORD, overloaded-function, const char [54])'
I faced same problem
boost: 1.47
OS: Windows XP (32 bit VM)
But not with FireBreath
I changed boost::system::system_category to boost::system::system_category() in pipe.hpp line 129
the boost::process library that was in FireBreath has compilation errors in them. I have fixed those errors and it now compiles for me, at least when including . I haven't actually tried to use it on windows yet, nor I suspect has anyone else.
Good luck, hope that helps.
Related
I'm building a package tested for CUDA 9,10 from source, trying to compile it for CUDA11.
I've already changed gencode=arch=compute_70 (was set on 30), and added
target_link_libraries(tsnecuda ${CUDA_cusparse_LIBRARY})
Unfortunately, I still get
tsne-cuda/src/util/math_utils.cu(153): error: identifier "cusparseScsr2csc" is undefined
tsne-cuda/src/util/math_utils.cu(165): error: identifier "cusparseXcsrgeamNnz" is undefined
tsne-cuda/src/util/math_utils.cu(195): error: identifier "cusparseScsrgeam" is undefined
3 errors detected in the compilation of "tsne-cuda/src/util/math_utils.cu".
CMake Error at tsnecuda_generated_math_utils.cu.o.cmake:276 (message):
Error generating file
tsne-cuda/build/CMakeFiles/tsnecuda.dir/src/util/./tsnecuda_generated_math_utils.cu.o
Is there a chance the build process somehow ignores my target_link_libraries? Should I add something else?
Undefined identifier is a compilation issue, not a linking issue.
At least part of the problem here is that CUDA deprecated and removed some functionality from cusparse, including cusparse<t>csr2csc(). The code would need to be rewritten to compile correctly under the latest versions of CUDA 11.x.
For example, for csr2csc, the call to cusparseScsr2csc might be refactored to use this function instead.
One example of deprecation/removal notice for cusparse<t>csr2csc is given here.
I am trying to use multicore-0.2.15 toolbox with Octave v3.6.4 on Windows7 64bit
( http://octave.sourceforge.net/multicore/ )
but even the demo script doesn't seem to work, it's not possible to create a pipe and I received an error message. So if I try to evaluate the following command in Octave
[read_fd, write_fd, err, msg] = pipe ()
I receive the following output:
read_fd = -1
write_fd = -1
err = -1
msg = pipe: not supported on this system
The fork function doesn't work either.
Does anyone have an idea what the problem might be?
Zoltan
The error message pipe: not supported on this system says it all. There is no support for pipe() in your system (Windows 7). You can:
Not use the multicore which you will notice is unmaintained (see the unmaintained section at the bottom of the package list). You could instead use the parallel package.
Try another build of Octave. Maybe the MinGW builds will work with pipes.
Try another version of Octave. Version 3.8.1 has already been released and if it is a problem on the side of Octave instead of Windows, maybe it has been fixed.
Change operating system (pipe() works fine in Debian)
So very strange issue. I only recently starting using auto loading in PHP 5.3+ and of course, this inevitably led to composer.
I did a really simple install with composer with only one package, php Image Workshop.
In addition to my own auto loader, I fire of the vendor/autoload.php
Then in my code:
use PHPImageWorkshop\ImageWorkshop;
$imagelayer = ImageWorkshop::initFromPath( $filename );
The namespace is valid and I get into the class which immediately throws an error.
PHP Fatal error: Call to undefined function PHPImageWorkshop\\imageCreateFromJPEG() in /var/www/html/vendor/sybio/image-workshop/src/PHPImageWorkshop/ImageWorkshop.php on line 55
imageCreateFromJPEG should be in the global namespace already, but the code in the class doesn't prefix it with a '\'.
Is this all right? I feel like I'm looking for a black cat in a dark room.
I guess the problem is GD is not available in your PHP instalation. Try to install php5-gd and it should work.
Good luck
I tried messing around with Win32 binaries lately (this is for a big project of mine).
So after some weeks of research, I now have a solid understanding of how Assembly works, how it is converted into binary code and how x86/x64 opcodes work.
The last piece to the puzzle is figuring out how to properly call Win32 API methods.
I actually asked a question on here in relation to this, and the answer I got was, I should try and compile an Assembly or C program that does this. So I went ahead and tried this in Assembly (I'm using FASM by the way):
format PE console
entry start
section '.idata' import data readable writable
include 'win32a.inc'
library kernel,'kernel32.dll'
import kernel,\
GetStdHandle,'GetStdHandle',\
WriteConsoleA,'WriteConsoleA'
section '.data' data readable writable
string db 'Hello!', 0h
output dd ?
section '.code' code readable executable
start: push -11
call GetStdHandle
pushd 0
pushd output
pushd 7
pushd string
pushd eax
call WriteConsoleA
This is one of the many versions of this code actually. The main problem is, when I call methods like "ExitProcess", generally other functions from the kernel32.dll library, things seem to work out. It's the IO functions that bug me...
I don't understand what's wrong with this code, I don't get any compile-time errors, though when I run it, it just crashes.
So my next idea was, since this didn't work, to try the same in C.
I'm using Cygwin as a compiler and linker...
#include <windows.h>
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {
MessageBox(NULL, "Hello, world!", "Test", MB_OK);
return 0;
}
This code yielded the same result, the application crashed.
Now, I am not looking for any C/C++ code. My original question of interest was to know how calling extern library function looks like in x86/x64 binary (assembled) code. But I would be very thankful for any resources regarding this topic.
Thank you in advance.
-Tom S.
Your problem is that you need to call ExitProcess at the end to properly end the process. Since you are not doing that, the code currently will continue executing and eventually segfaults because it attempts to execute junk bytes.
I have a nice fully functioning module (wrtten using tcl/cpp) it works fine.
I want to use ramdebugger to debug scripts using that module
When I enter
load mylib.so
command1_from_lib xx
command2_from lib yy
If (say) command2 returns an error then ramdebugger dies
[paul#paul-es5 ramdebugger7.7.1]$ ./ramdebugger
alloc: invalid block: 0x999c058: 0 0
Aborted
It dies here in libtcl / ResetObjResult
if ((objResultPtr->bytes != NULL)
&& (objResultPtr->bytes != tclEmptyStringRep)) {
ckfree((char *) objResultPtr->bytes);
}
My suspicion is there is confusion over the global tclEmptyStringRep. I think the starkitted(?) ramdebugger has one and the dynamically loaded libtcl has a different one - the bytes pointer should logically be pointing to an empty string but the value there does not match what gdb shows for the global
I am a tcl noob and need any help I can get. Alternatively a suggestion for a different debugger would work
edit: fixed
Use tclStub to defer the link between the extension and the tcl runtime.
This sounds very much like a bug to me, as opposed to a question which this site can answer. You should contact the ramdebugger people to see if they can help.
However, for general Tcl debugging you could also see if the tools produced by ActiveState help; IIRC you can get a free trial to see if they can make any headway. (Myself, I'm of the put-lots-of-printf-calls in school of debugging, so I'm nobody's poster child.)