For Dymola linux users: I am using several libraries and I have to painfully load every one of them each time I start Dymola in Linux. In windows, I found some links to enable automatic loading by modifying .mos scripts. Is there any such method to load libraries during startup in in Linux?
Dymola should support the same methods for doing that on Linux as on Windows; see How to add load libraries, change directory, etc. on startup?
The only difference is that if you really use paths in scripts they are different, but normally you shouldn't use them directly.
Related
I have memory related problem in my application on solaris9 environment where Tcl_DeleteInterp() function calls lot of free() and mutex_unlock() functions. To debug the problem i followed the below steps to compile tcl on solaris server (with TCL_MEM_DEBUG flag) but still i couldn't use the 'memory' command in my interpreter.
Ran configure script on server (./configure –prefix=<directory needs to be installed> --enable-symbols=mem)
Make clean all
Make install (tcl libraries and tlcsh exe is copied to the path specified in step1)
Compilation generated two libraries (libtcl8.4g.so and libtclstub8.4g.a), I copied libtcl8.4g.so as libtcl8.4.so to my app
Copied tcl8.4 directory as well.
I also copied the tclsh8.4 to $PROVHOME/bin and created soft link as tclsh-> tclsh8.4.
From my application i linked the debug symbol enabled libraries to the place where exactly i created the Tcl interpreter.
Initialized the Tcl interpreter to using Tcl_InitMemory() function (so that the memory command will be registered in the supplied(arg) interpreter.
When i used the interpreter exe (tclsh) separately i could execute the memory command, but when i used the same exe on my application its not working. Can someone help me what could be the possible reason for this problem ?
Also help me how can i cross verify the libraries that they are compiled with TCL_MEM_DEBUG flag.
Will the Tcl source code tar file contain Solaris directory where i have to build the libraries or should i use the unix source code for solaris platform as well ?
Thanks
Are you using [mem] interactively (which does expansion of unambiguous short command names) and forgetting to use the full name ([memory]) in your scripts?
You're using Tcl embedded in your code? You need to call Tcl_InitMemory (passing in the handle to the interpreter where you want the memory command created) after creation of the interpreter and before you run user scripts, i.e., straight after the Tcl_CreateInterp gives you the handle (which should in turn come after the Tcl_FindExecutable call that initializes the shared parts of the library).
You must also make sure that everything is built with that flag set so that the correct memory allocation APIs are used in both your code when it integrates with Tcl, and you must make sure that you are linking against the debugging build. It's probably the linking that has gone wrong, but I've not done that level of development on Solaris for many years.
I think you'll find that “Getting a list of used libraries by a running process (unix)” is relevant to your problems.
I want to use CGI and Apache web server to give users access to run my compiled Matlab application (an exe file). I followed the instructions at this guide.
But, I received an error in the web server logs as:
[error] [client 127.0.0.1] Could not access the MCR component cache., referer: .../standalone.html
I am using Matlab 2012a. Is there anyway to control the MCR cache for applications compiled using Matlab 2012a? There is no more CTF file with the compilations of this Matlab release.
Thanks.
I believe that in recent versions of MATLAB Compiler the CTF archive is embedded in the .exe by default, but that you can change that back, either by selecting an option from within the deploytool settings, or by using the -C parameter with mcc.
The CTF archive would normally expand automatically the first time you run the component, but if you need to manually expand it (I believe there are reasons you need to when calling it from CGI, although I've never done it myself) there's a utility called extractCTF.exe in matlabroot\toolbox\compiler\arch, where arch is your OS type, such as win32 etc.
See here and here for more information.
Hope that helps!
I work part-time as a computer tech at the local high school. They needed a system to keep track of all the computers in the district (things like physical location of the machines and serial numbers for inventory), and told me to keep it on a budget. I sat down and wrote a little thousand-line script in Perl/Tk, which accesses a PostgreSQL database on the local server.
I also successfully wrote a launcher in C++ and compiled it with bcc32, so they can single-click the launcher executable to start the program without having to type anything into DOS. That works fine, and I can load this program myself by manually installing all the dependencies for it by hand.
I would like to build a setup program to automatically load the PostgreSQL application, Strawberry Perl, as well as the Tk, and DBD::Pg libraries, and finally, of course, the folder my application is stored in. It'd be nice to be able to create desktop shortcuts or start menu items too.
Has anyone had any success with software to generate .MSI files for Windows Installer on Windows XP and above? If so, what did you use, and did it cost any money? Alternatively, where do I need to begin reading in order to write my own setup program?
Nullsoft Scriptable Install System
I'm not sure if this will do everything you want, but have you looked at Win32::InstallShield?
I had developed a small program in netbeans using c++. I need to know how can i deploy/run the package on another linux system
Abdul Khaliq
I have seen your code, you probably missing XML files in the current folder... where the executable is located... paste then and then run as ./your-executable
I recommend that you use a makefile to recompile on your target machine which will ensure that your program is deployed properly.
You should use a makefile as suggested. I know that NetBeans can generate one, but it's been a while since I last did so. Maybe this can help: http://forums.netbeans.org/topic3071.html
Typically, once compiled, your executable will need several libraries. Chance is that those libraries will also be available on the target linux system.
Thus, you can simply copy your executable over to the other system. If you run ldd on your executable, you should see the list of libraries your executable is dynamically loading. Those libraries should be available on the target system as well.
In case your executable makes use of resources such as images and other binary files, you can use a resource system (e.g. Qt Resource System) and compile those binary files into your executable.
The easiest way to test is to do the copy, run
ldd yourExecutable
on the target system. It will tell you if you are missing any library. Install those libraries using the system package manager.
Of course, you also have the option to statically build all libraries into your executable. However, this is not recommended since it makes the executable too large and complicates matters.
What type of package is your netbeans compiler creating? deb,rpm? If you are moving the package to a different linux install you will need to use that distributions package type. Ubuntu - deb
Fedora/Redhat - rpm
etc...
I'm not sure how you change this in netbeans but I'm pretty sure it has the ability to. A google search could help you more.
I am currently writing a PowerShell snapin that has specific dependencies on mixed-mode assemblies (assemblies containing native code) that specifically target x64 or x86. I have both versions of the dependent assembly, but I am wondering how best to manage the build and deployment of this snapin, specifically:
Is it necessary to have two versions of the snapin, one x86 and one x64, and use the two different versions of installutil to install it, once for each architecture?
Assuming #1 is true, is it recommended to install the two different versions of the snapin in the different "Program Files" and "Program Files (x86)" directories?
What is the ideal (least hassle) way to structure a pair of projects that share everything but a single reference, in order to build for the two different architectures?
If the snapin is compiled as "AnyCpu", and the dependent dlls are both loaded into the GAC, will the runtime load the correct assembly from the GAC based on the architecture of the currently running PowerShell host?
Is there a slick way to dynamically, at run-time, choose which dependent dll to load (if it cannot, for various reasons, be installed in the GAC) without running into headaches with assembly load contexts?
Mark, we have this very situation with the PowerShell Community Extensions with 32-bit and 64-bit versions of 7zip.dll. You can pretty easily work around this by PInvoking to LoadLibrary early in your snapin startup (or before you need to call out to the native DLL). You can then test if you're a 32-bit or 64-bit process (IntPtr.Size) and then load manually the correct DLL using the LoadLibrary PInvoke. After that the, DllImport("YourNative.dll") will notice that the dll is already loaded and use that DLL.
Take a look at these two PSCX source code files:
http://pscx.codeplex.com/SourceControl/changeset/view/74794?ProjectName=Pscx#1358100
http://pscx.codeplex.com/SourceControl/changeset/view/74794?ProjectName=Pscx#1358102
I ended up creating a module (thanks, Richard!), but that didn't solve the problems related to processor architecture. In order to solve that, I put both versions of the dependent dll in the module directory, and in each cmdlet's constructor I put some initialization code (that only runs once) to load the appropriate version of the dependent dll.
Thanks, all, for the pointers.