I'm trying to compile a code that uses the fmemopen function in MinGW. I found out the there is no equivalent function in MinGW. Are the any alternative functions that I can use. In case if you have written an equivalent function for fmemopen please help me out.
My requirement is that, I cannot save the content into temporary files. The data has to remain within the application. So I'm not sure if the idea of creating a temp file and reading back will workout.
Thanks,
Sathish
Related
I am trying to run COPASI in commandline but there is very little documentation.
I have downloaded and unzipped binary, I am not sure how to proceed in order to do something as simple as import an SBML file?
Here is all the documentation I found:
http://copasi.org/Support/User_Manual/Model_Creation/Commandline_Version_and_Commandline_Options/
It doesn't say which command do I use to call COPASI?
The command line version of COPASI is CopasiSE, which you can install besides the GUI CopasiUI via any source here http://copasi.org/Download/.
For example, see https://github.com/ICB-DCM/solverstudy/blob/master/Bash_Scripts/install_copasi.sh, in which case the executable resides in a local folder.
Regarding usage, I am not sure whether extensive API documentation is available. It probably won't help much, but here's how we wrapped it in a study via Python to call an underlying CPS model file https://github.com/ICB-DCM/solverstudy/blob/master/Python_Scripts/simulation_wrapper_copasi.py#L77.
I've been writing a Python extension use the Python/C API to read data out of a .ROOT file and store it in a list of custom objects. The extension itself works just fine, however when I tried to use it on a different machine I ran into some problems.
The code depends upon several libraries written for the ROOT data manipulation program. The compiler is linking these libraries dynamically, which means I cannot use my extension on a machine that does not have ROOT installed.
Is there a set of flags that I can add to my compilation commands to make these libraries statically linked? Obviously this would make the file size much larger but that isn't much of an issue providing that the code runs at the same speed.
I did think about collating all of the ROOT libraries that I need into an 'archive' file. I'm not too familiar with this so I don't know if that's a good idea or not.
Any advice would be great, I've never really dealt with the static/dynamic library issue before.
Thanks, Sean.
newbie here.
Want to ask for any advice on how to Publish/Export, CodeBlocks Application made by using wxWidgets. After some research, i discovered that i should use DLL, or something like that, but since I am really new into it, I am missing the logic on how I should actually implement that. Since CodeBlocks offers wxWidgets and DLL as separate projects. So I am not really sure how to properly combine. Thanks in advance.
If you used wxWidgets as .dll, to get a self-standing package you have to distribute all the requested libraries. The simplest way is just to copy them from their source folder (in your case [wxWidgets root]\lib\gcc_dll) in the same folder as your executable. There could be many of them, but usually only two or three are needed. For simplicity you can copy them all, or you can try repeatedly to start the program, and add each time the library indicated in the error message.
Please note that to distribute your application you will probably want to compile it in Release mode, and consequently you should ship the Release .dlls (i.e. beginning with wx...28_ instead of wx...28d_).
I am using Visual C++ to build a dll with some open source projects, but when I got an error, it read:
How did the "f:\dd\vctools\crt_bld\self_x86\crt\src\vsprintf.c" come out? I even didn't have a "f" disk. I've searched around about my source code, and there is no such string.
Any idea about this?
The file path as #Dcoder says is not from your disk.
This message is from the CRT (C run time library) that you link with your programs. MSVCRT.DLL (or a version of it)
When Microsoft wrote their source code to create this library they built special code called Assertions into it. This code (when you link to debug version of the library) checks the parameters that you sent to a function in the library, and passes helpful messages to you.
In this case you've called a function like printf or sprintf etc, and that eventually went into a piece of Microsoft function that lives in a microsoft file called vsprintf.c.
This file when the library was compiled inside Microsoft, it was done on the F: drive INSIDE Microsoft . It doesn't live on your disk.
Edit: if you add your code to your question we can help you find where this occurred.
As others have indicated in comments, the path described in the assertion dialog is the path of the source file that threw the assertion. In this case, a CRT sprintf function threw an assert.
The 'f:...' path doesn't refer to a path on your own machine: it's the path to the source file on the machine that compiled the file into the CRT DLL.
This is a debug assertion failure - you apparently passed a NULL-value to a function of the sprintf-family.
You should check your source-code for any NULL-values you pass to such a function.
It's where the Common Run Time (CRT) framework is installed. vsprintf.c is part of the CRT and something in that DLL has called one of the sprintf() functions with a null format string.
Can any one of you help me in converting an windows dll file in a .so file.
You might try re-compiling the source code to the dll to a shared object. This may help you get started, after ensuring the code is indeed portable.
Edit:
Here is yet another link that can help guide you through the process of creating a shared library using GCC and other parts of the GNU tool chain. This link will help you to discover pitfalls that other people had when undertaking a project similar to this.
There is only so much help that can be provided for such a specific task, especially with so many unknowns. If you elect to provide more information in your question, please leave a comment.
NB: I'm pulling these links right out of Google.
If you don't have the source, or can't recompile, you may be able to run the code under Wine.
You need to recompile again into an .so file.