How do I install the AMPL gjh solver using conda on Windows?
I am trying to install this to conduct sensitivity analysis on Pyomo. Ultimately, I am trying to conduct parameter estimation on Pyomo and get the least squares' sensitivities on the parameters themselves.
The difficulty is that the parameters themselves do not appear in the objective function explicitly. The parameters only affect the predictions indirectly via the DAE that describes my system of interest. This means symbolic differentiation is probably not an option.
Related
I developed a C program requiring some dynamic libraries, most notably libmysqlclient.so, which I intent to run on some remote-hosts. It seems like I have the following Options for distribution:
Compile the program static.
Install the required dependencies on the remote host
Distribute the dependencies with the program.
The first option is problematic as I need glibc-version at runtime anyway (since I use glibc and libnss for now).
I'm not sure about the second option: Is there a mechanism which checks if a installed library-version is sufficient for a program to run (beside libxyz.so.VERSION). Can I somehow check ABI-compatibility at startup?
Regarding the last Option: would I distribute ALL shared-libraries with the binary, or just the one which are presumably not installed (e.g libmysqlclient, but not libm).
Apart form this, am I likely to encounter ABI-compatibility problems if I use a different compiler for the binary then the one the dependencies were build with (e.g binary clang, libraries gcc)?
Version checking is distribution-specific. Usually, you would package your application in a .deb or .rpm file using the target distribution's packaging tools, and ship that to users. This means that you have to build your application once for each supported distribution, but there really is no way around that anyway because different distributions have slightly different versions of libmysqlclient. These distribution build tools generate some dependency version information automatically, and in other cases, some manual help is needed.
As a starting point, it's a good idea to look at the distribution packaging for something that relies on the MySQL/MariaDB client library and copy that. Maybe inspircd in Debian is a good example.
You can reduce the amount of builds you need to create and test somewhat by building on the oldest distribution versions you want to support. But some caveats apply; distributions vary in the degree of backwards compatibility they provide.
Distributing dependencies with the program is very problematic because popular libraries such as libmysqlclient are also provided by the base operating system, and if you use LD_LIBRARY_PATH to inject your own version, this could unintentionally extend to other programs as well (e.g., those you launch from your own program). The latter risk is still present even if you use DT_RUNPATH (via the -rpath linker option), although it is somewhat reduced.
A different option is to link just application-specific support libraries statically, and link base operating system libraries dynamically. (This is what some software collections do.) This does not seem to be such a great choice for libmysqlclient, though, because there might be an expectation that its feature set is identical to the distribution (regarding the TLS library and available configuration options), and with static linking, this is difficult to achieve.
I am currently looking for ways to expose the location of a shared library on Linux such that it can be picked up easily by any program installed separately. I want to make this location configurable so it can point to different possible installations of the same library. Examples of similar cases I can think of would be Qt5 and Java.
To make a long story short, I am developing FreeRDS, a FreeRDP-based Remote Desktop Services stack. Server-side RDS-aware applications link to libwinpr-wtsapi, a stub library that exposes the Microsoft Windows Terminal Services API interface, but does not implement it. This enables applications to link to libwinpr-wtsapi without having to link directly to a specific RDS implementation. On the first call to any of the WTSAPI functions, the real implementation is loaded dynamically by libwinpr-wtsapi. However, the location of the dynamic library implementing the WTSAPI (here, FreeRDS) needs to be known.
Right now, I am achieving this by setting an environment variable with the full path to the library:
export WTSAPI_LIBRARY=/opt/freerds/lib/x86_64-linux-gnu/libfreerds-fdsapi.so
However, this is not very practical, as this environment variable would need to be set for every program using the WTSAPI. In this case, I have my installation of FreeRDS in /opt/freerds.
I am thinking I could probably simplify this by using a single environment variable to expose the installation prefix of FreeRDS on the system, with something similar to JAVA_HOME:
export FREERDS_HOME=/opt/freerds
However, I then need to know the proper library subdirectory. It is also important to know that it would be possible in the future to offer both a 32-bit and a 64-bit version of the library offering the FreeRDS WTSAPI. This library basically performs RPC with the FreeRDS session manager, so that would be definitely possible.
Let's say we have FREERDS_HOME properly set, or that FreeRDS is installed in the default installation prefix of the system, which files would be "standard" to offer some additional installation configuration information? Here I'm thinking I could have an equivalent of Qt5's qt.conf that would specific installation subdirectories, like the 64-bit installation subdir, the 32-bit installation subdir, etc. However, I don't know where I should be putting that file. Should it be in <prefix>/etc/freerds/freerds.conf?
Ideas, anyone? Thank you!
some (many? all?) Linux distributions today include environment-modules, which aim is exactly to make available many different versions of the same software by customizing the environment (and eventually, shell aliases/functions) with easy front-end commands.
You can find all the needed information here.
Thanks for the multiple answers, here is the solution I finally opted for that satisfies my needs:
As explained earlier, there could be more than one installation of FreeRDS on the same system, but only one of them running at once. We can also assume FreeRDS is supposed to be running before we can attempt to interact with it. Knowing this, I modified FreeRDS to write a simple configuration file in /var/run/freerds.instance with the install prefix and installation subdirectories. This is very similar to having a .pid file, except we're exposing installation paths.
The freerds.instance file is using the .ini format, which is fairly common in configuration files. All that libwinpr-wtsapi has to do is parse /var/run/freerds.instance to find the installation prefix of the current FreeRDS instance, along with the library subdir, so we can find the correct libfreerds-fdsapi.so.
Here is what a sample freerds.instance file looks like:
[FreeRDS]
prefix="/opt/freerds"
bindir="bin"
sbindir="sbin"
libdir="lib/x86_64-linux-gnu"
datarootdir="share"
localstatedir="var"
sysconfdir="etc"
I prefer this solution because it requires literally no special configuration, setting of environment variables, etc. No matter what, we always find the proper FreeRDS installation wherever it is on the system.
You can add a $ORIGIN rpath to your executable, that makes it load libraries relative to the directory the executable is in. (See "ld: Using -rpath,$ORIGIN inside a shared library (recursive)"). This probably applies to dlopen() too.?
$ gcc ... -Wl,-rpath,'$ORIGIN/../lib/dir' -lsomething
I've also found you can run the dynamic linker directly to get some debug facility:
$ /lib/ld-linux.so.2
Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
...
--list list all dependencies and how they are resolved
export LD_LIBRARY_PATH=/yourso.so
I downloaded library from http://sourceforge.net/projects/xsock/.
In INSTALL file are steps to run this libs.
I changed location to xsock/libxsock and type in terminal ./configure
Nothing happend... How to solve this?
cd' to the directory containing the package's source code and type
./configure' to configure the package for your system. If you're
using csh' on an old version of System V, you might need to type
sh ./configure' instead to prevent csh' from trying to execute
configure' itself.
Running `configure' takes a while. While running, it prints some
messages telling which features it is checking for.
Type `make' to compile the package.
...
4...
The library is broken, and cannot be built as distributed. A number of autoconf/automake files are missing from the archive.
Given that the library appears to have been primarily developed on Windows systems, it seems likely to me that the UNIX parts of the build process for this library have not been maintained, or may never have worked at all. My recommendation is that you find another library — this one seems to be largely unmaintained, and the code quality seems rather low.
I am developing a tool in C which takes in a file as a input. I need to compute the SHA1 sum for the file. This tool needs to be platform compatible with Linux, Mac and windows. The files are huge in size ranging from 150MB to 2G. I need the tool to be able to compute the SHA at least as fast as the sha1sum Linux utility.
Any suggestions how I could go about incorporating SHA1? I am wary about using the openssl interface, since the clients for the tool would not necessary have openssl installed.
OpenSSL is the de facto standard in C. It needn't be installed since you can supply the library along with your program (or even statically compile it).
OpenSSL is BSD-style licensed, so you can even use just their SHA1 code directly in your program (giving credit), though it may be tricky to decouple it from the library.
My digest package for R includes short standalone C sources for md5, sha1, sha256, ... which were written by Christophe Devine. It is nice code, and it includes a few tests replicating the reference results from the specifications.
I believe his site no longer exists, but when I eg checked Google Code Search for it, the same functions seem to have been included in a number of other open source projects. You can easily extract these sources from my tarballs or even directly from the SVN directory at R-Forge's digest repo.
I'm trying to generate C code from a Matlab-Simulink simple model (eg.: sine wave generator with a DAC at the output). This code must be executed with Code Composer Studio
for TMS320C6748 DSP (Texas Instrument C6748). Specifically, for the development board OMAP-L138 ZOOM ™EVM DEVELOPMENT KIT.
For this, I am using the following versions:
Simulink (Version 7.7 - R2011a)
Embedded Coder (Version 6.0 - R2011a)
Code Composer Studio v3.3
I tried several options (with generic modules in Simulink and programming the C6748 timers, configuring a module "Target Preferences" with "OMAP_L138/C6748 EVM"...) but it isn't working.
Is it possible to implement this idea? Is there an example working?
Thanks
Code generation for OMAP-L138 EVM / C6748EVM is supported in Simulink in R2011a. Before opening the Target Preferences block, import the processor definitions from DSP/BIOS. On the MATLAB command line, type the following:
getDspBiosFolder % This returns which DSP/BIOS MATLAB is seeing. If the value returned matches your installation of MATLAB, then you are OK. Otherwise, you need to use setDspBiosFolder to set the installation folder for DSP/BIOS (i.e. setDspbiosFolder('C:\CCStudio_v3.3\bios_5_33_06') on MATLAB command line).
importDspbiosConfig('proc', 'all')
importDspbiosConfig('board', 'all')
After these steps, you should be able to open the Target Preferences block and examine the settings. Before proceeding with code generation, run checkEnvSetup() utility to make sure that you installed all TI software required for code generation:
checkEnvSetup('ccs', 'omapl138evm', 'list')
The command above gives you a list of what you need to install. After making sure you have all of the software installed above with correct version numbers, execute the following:
checkEnvSetup('ccs', 'omapl138evm')
This sets all environment variables needed for code generation. MATLAB sees the location of the tools through environment variables created this way.
After these steps you should be able to generate code.
Code generation for OMAP-L138 EVM and C6748 EVM is not supported for older versions than Matlab 2011a.
For the release 2011a, the setup process is not trivial and it is not well documented. But Matlab has a patch for this version supports and works with certain specific requirements.
The release 2011b has improvements (hyperlinks required for products of thirds work with CCStudio v4 for this processor) and supports code generation for OMAP-L138 EVM and C6748 EVM.
For the release 2012a, Matlab has considered adding specific sections in the documentation for configuration and automatic code generation with these processors.