I'm writing an eCAP adapter (in C++) for Squid. I've seen that libtool is required in order to create a library and import it into Squid.
I started from the adapter_modifying example (that can be found here http://www.measurement-factory.com/tmp/ecap/ecap_adapter_sample-0.2.0.tar.gz) and added some features (encryption of JSON objects).
In order to do so, I'm using this library https://code.google.com/p/rapidjson/ and this OpenSSL wrapper https://github.com/shanet/Crypto-Example
After compiling and installing the adapter (it involves the creation of a library with libtool), I've run squid but the adapter crashes as soon as I instanciate an object of the OpenSSL wrapper.
My plugin stops running as soon as I instantiate the Crypto wrapper:
Crypto crypto;
If I don't execute the adaptation method and just buffer and forward the chunks, everything works fine. Do you see anything in the code of this library https://github.com/shanet/Crypto-Example that may cause this issue?
Do you know how I can access the error log (or standard error) of my plugin?
How can I correctly link these two libraries to my adapter? Which commands should I execute?
Related
I have seemingly 2 libraries that are interfering with each other in regards to their usage of SSL.
One is the Tuya SDK which is added via CocoaPods, and the other is a locally added library, for which I don't have the source code.
When the locally added library tries to use SSL, I get a 'EXC_BAD_ACCESS' error, so there is clearly a conflict. (When I run the local library in a separate isolated project on its own, the SSL works fine.)
Is there any way in Swift to specify to only use one of the SSL files? (So that both Tuya and the local library will use the same, single SSL file).
For example I think you can do this in Android with Gradle, using the FirstPick() Packaging Options{}?
We are using a Jenkins Shared Library to centralize some code for all our (scripted) pipelines. Now we factored out some Groovy code into a .jar library (written in Kotlin, compiled to be Java 8 compatible). We published this library to our in-house maven repo and now want to use it in our Shared Libary.
We are using #Grab to load our library and up until that point it works like a charm. However we are getting NoSuchMethodError's. We pinpointed it down a bit, we are using OkHttp in our Kotlin lib. OkHttp internally uses Okio. When we call methods that internally call OkHttp-Code from our pipeline, everything is fine. However when the OkHttp-Code call Okio internally, we get a NoSuchMethodError.
We already checked the published .jar file, it contains the classes with the methods that seem to be missing. Does anybody have an idea what the issue could be?
While we are at it, we can't access environment variables set on Jenkins in our Kotlin library, is there a way we can fix this?
We figured it out. The problem was, that a Jenkins plugin used an older version of okio internally. Because plugins and shared libraries somehow share the same classpath, okio did not get loaded and the version from the plugin got used, therefore the class was not present.
We fixed this by repackaging all dependencies in our .jar, so package names would not interfere and we can make sure that our specified dependencies are being used.
Looking the dependencies here you have a few problems:
OKHttp - seems to expect some Android libraries
okio - depends on the Kotlin runtime
Any calls to these will result in method not found errors unless you find a way to make them available without causing problems in Jenkins
I'm building a board game from ES6 modules using Electron 2 (for Chromium 61+) and the esm shim on the server side of things. This is the first time I've written isomorphic JavaScript, let alone ES6 modules; I intend to be able to run game logic on the client in single-player mode, and on the server in networked play mode. So far so good, I'm happy to report! And it's satisfying to not rely on any heavy transpilers.
Now, though, I have a problem: I intend to use types from Immutable JS on the client as well as the server, and I only know how to import them into the server code. Until now, all the import statements in the isomorphic code referred to other JS modules in the app, not to dependencies from npm. A module like the one below causes an "Uncaught TypeError: Failed to resolve module specifier 'immutable'" runtime error in the client when the app loads:
import Immutable from "immutable";
Immutable.List.of([]);
export { foo: {} };
In fact, I'm virtually certain that the import statement is failing because Chromium can't resolve "immutable" to a JS file. But how am I supposed to go about resolving it? And is there a way to resolve it that would work for any node module that is written to be isomorphic?
TL;DR - You can't without help of bundler like webpack as long as you're using npm modules.
Most of node.js package ecosystem is not ready for native module yet. About 99% of published package in npm currently using node.js's CommonJS module system, while there are very few module written to support esm (ES module syntax as well).
esm shim is intended to help latter - if module's written in esm and to be imported in current node.js version doesn't support it helps to resolve those modules. Opposite case doesn't work. Chromium can import your code directly which is written in native syntax, then try to resolve dependency module you specified and failed to resolve as 1. it doesn't know where to resolve (as it doesn't follow node.js's module resolution rules) 2. when it's available to resolve, actual import will fail cause module'll be cjs export instead of native.
Get back to TL;DR above - if the intention is achieving isomorphic code to run on both processes, use bundler accordingly.
RDP static library works fine if I comment out the code written for OPentok, if I try to work both together it gives BAD_Access Error at run time.
Its possible that there are incompatibilities between the SSL library versions used in each. OpenTok uses boringssl, which happens to export symbol names that are identical to those in openssl.
I'm working on porting a library onto AIX. It works on Solaris, Windows and Linux but AIX is giving me headaches. I'm at a point where it builds and runs but I have an issue with some of the libraries it's linking in. Ideally I want to be able to ship a library that just requires the c runtime to be available with no other dependencies. At the moment I'm having a problem with libpthread which I can see is a symlink to an AIX specific threading library.
My issue is this:
If I don't link pthread (I don't seem to need to on Solaris for the same code base) then I get undefined symbols. That's fine I am using pthreads. If I link it in then it works fine, except that any calling application also has to link to pthreads. I don't really understand is why does my calling app, which has no dependency on pthread, need to link against it just because it's calling a library which links to the shared object?
I'm on AIX 6.1 using gcc 4.2.4.
I'd be OK with shipping a library that requires pthreads to be present on the library path (ideally we'd get a static version) but I'm a bit unhappy about shipping a library that places linker rqeuirements on the client.
Any ideas on what I might be doing wrong?
I defeinitely seem to be going in circles. I removed the -shared flag on the linker to resolve an earlier problem and that, of course, makes the library static. So the behaviour is just normal behaviour in that if you depend on a dynamic library from a static one you have to link both into your app. So I've put the shared flag back and now half of my functions are no longer accessible. It does explain the problem I was seeing though.