unable to access 'http://mibs.snmplabs.com/asn1/', any alternative to compile proprietary mibs.
Is snmpLabs down ?
Need to compile mibs from .mib to .py format compatible with pysnmp
As I am now taking over the PySNMP ecosystem, a new site https://mibs.pysnmp.com is created.
You'd better fully switch to *-lextudio packages at this time, as documented in https://github.com/etingof/pysnmp/issues/429
The old packages have snmplabs.com hard coded everywhere, so you cannot easily override all the URLs to pysnmp.com.
Related
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.
I am trying install OpenGL on VS2010.
I use this tutorial.
And I get the following error:
Unable to start program 'C:\Users\s151310\Tutorial 0.3.8\frameworkD.lib'.
The specified file is an unrecognized or unsupported binary format
How can I fix this?
Actually don't have to install anything at all to start OpenGL development with Visual Studio. As long as you limit yourself to OpenGL-1.1 and core Win32 APIs everything is already in place for you.
However to get modern OpenGL features one must use the so called extension mechanism to load pointers to functions of newer versions – a tedious and uninteresting process. Hence extension loader wrappers have been developed.
Also creating a window and setting up a matching OpenGL context is laborous as well. So you want to use some framework for that two.
Extension loader wrappers and frameworks are 3rd party libraries that need to be installed separately.
Unable to start program 'C:\Users\s151310\Tutorial 0.3.8\frameworkD.lib
Why are you trying to execute a library file? This is the framework library that's supposed to be linked into your executables. So this raises the question: How did you setup your project, specifically which build options did you configure. Without that I can't give better advice.
I am new to LISP, currently using LispWorks and ListBox IDE on window server 2008.
I want to know that, how can we compile and run LISP project, contain 350 LISP source file.
and what will be generate after compilation and how can i run it...?
and what's techniques are available to debug lisp project.
(it is old technology, so I cannot get much help from internet)
LispWorks comes with a lot of documentation. This documentation is also available on their website.
LispWorks can:
organize source code with a system management tool
save images with saved state
compile individual files to loadable machine code
create shared libraries
create stand-alone applications
Their Delivery User Guide describes how to generate applications.
The documentation of DEFSYSTEM describes how to organize source code and how to compile systems.
This post and this post says that with Visual Studio, the run time library can be static/dynamic, and it shouldn't be mixed. Even one can have debugging version/release version for the library. And there are four possibilities (static/dynamic and debug/release).
So, with Visual Studio, the library provider has to provide four different versions of the same library?
ADDED
I tried to link CppUnit test (debug) with release build library, and I got an error. So, I wondered normally library provider might need to provide all the possible combination of libraries.
depends..
under normal cicrcumstances you only provide a realease version. Then you have the option for static/dynamic. In the case of static, you don't have to provide anything since it's static: your lib already contains all functions from the crt it needs. In case of dynamic, it also depends: if you expect your clients to build applications using your lib, they already should have the required lib on their build machine. Else, yes, you can provide them with a crt installer for the dynamic release version (or just ship the corresponding dlls but that's considered rather bad practice)
Also if I remember correctly, you cannot redistribute the debug versions of VS's debug libraries, so in the end this would mean the library provider should only provide one version.
This is really the case with ANY C++ library (we have the same 4 options in our Unix side builds).
Please note that you only have to provide the debug versions if you intend them to be used by other developers, who will need them to debug - otherwise, for end users, you can only provide optimized ones.
I am working on a project which is built using autoconf, automake and libtool. The project is distributed in both binary and source form.
On Linux, by default the build script links to all libraries dynamically. This makes sense since Linux users can rely on their distribution’s package manager to handle dependencies.
On Windows, by default the build script links to all libraries statically using libtool’s -all-static option. This makes sense since none of the dependencies are provided with Windows, and it’s helpful to be able to distribute a single binary containing all dependencies rather than mucking about distributing tons of DLLs.
On OSX, some of the dependencies are provided by the OS, and some are not. Therefore it would be helpful to link to the OS-provided libraries dynamically and to the other libraries statically. Unfortunately libtool’s all-or-nothing -all-static option is not helpful here.
Is there a good way to get libtool to link to some libraries statically, but not all?
Note: I realise I could carefully compile the dependencies so that only static builds are available. However, I’d rather the build system for my project were robust in the common case of static and dynamic builds of dependencies being available.
Note: Of course, I am not concerned with really low level dependencies like the C/C++ runtime libraries, which are always linked dynamically on all three of the above platforms.
After some research I have answered my own question.
If you have static and dynamic builds of a library installed, and you link to that library using the -l parameter, libtool links by preference to the dynamic build. It links to a static build if there is no dynamic build available, or if you pass the -static or -all-static options.
libtool can be forced to link to the static library by giving the full path to that library in place of the -l option.