I am working on a product where its built in two steps:
Step 1:
openssl-0.9.8zf is added as includes for compiling the product, and uses ssleay32.dll and libeay32.dll (of the same version) for linking.
Step 2:
While packaging the product, the above mentioned dlls are replaced with openssl-0.9.8zg version's and openssl.exe file is also added to support another library which loads that in at run time.
However this method is causing problems on which I am not able to lay a finger on. It works perfectly when I use the same version in Step 1 and Step 2. Given that openssl-0.9.8zg is 100% compatible with openssl-0.9.8zf, and that they are dynamically loaded, are there any guesses on what can cause problems?
OpenSSL information on versions: http://abi-laboratory.pro/tracker/timeline/openssl/
Related
I have tried so many things. Literally taken me a week of trial and error. I managed to get the realtime firebase DB working but not the firestore as I can't call the command
composer require google/cloud-firestore
I have tried fresh installs 3 times for PHP and the other software. This really is not working. Why do I have to use this composer thing and them not just put a zip with all the relevant files inside?
With extension=php.dll in ini:
and changing to aboslute path surrounding extension, with and without .dll I have tried.
I've tried threadsafe and non threadsafe versions, and I also don't know what "1% is not a valid command" is. Also have tried x64 and x86 versions. The previous two images are x86 (which I assume to be 64 as my os is)
Here is an example of a x64 (I assume is 32bit) error. Procedure points cannot be found and it gives an error about entry points.
I have no idea what I did but I fixed it. To those reading this question just make sure in every place there is a php.ini they are the same directory!
I am trying to load libreadline.so. My code works fine if I give the version number explicitly as in "libreadline.so.6" but fails if I just give "libreadline.so", presumably its just trying to open the file name I give directly. To avoid a future failure when a new version appears, I call dlopen in a loop with the version number counting down to zero. This works and always picks up the latest version of libreadline.
My question is, is there a correct, or better, way of doing this?
I see libreadline.so.6 is a link to libreadline.so.6.3, its a pity they cant have a link from libreadline.so to the latest version.
What about opening the directory which contains all the different files and then comparing the extensions of all files?
I'm trying to handle all of User Interfaces (UI) dialogs in .msi installing pakage, with EmbeddedUIHandler to do this I have created a setupui.dll which contains three methods: InitializeEmbeddedUI, ShutdownEmbeddedUI, EmbeddedUIHandler, and put it inside of MsiEmbeddedUI table (using installshield) and it worked just fine.
The problem is when setupui.dll is dependent to other external DLLs, this time windows installer won't use my dll and it uses default ui, I have added other DLL dependencies with Installshield as follow:
I'm uncertain of what Windows Installer allows here. There are, however, three things that jump out at me as things to look into:
The MsiEmbeddedUI table's Attributes column should probably have a 3 for SetupUI.dll (as it does), and 0 for the rest. Per the docs, the 2 bit is ignored if the 1 bit isn't present, but all the other files are better described as "It may be a resource used by the user interface."
The verbose log: does it indicate what's going on? Does it show a failure loading SetupUI.dll that provides a useful error code (hint: file not found probably refers to a dependency)? Does it indicate it didn't even try to load your DLL? Look for lines with EEUI, at least in the successful case.
If Windows Installer does attempt to load SetupUI.dll, how far does it get? If it gets far enough for you to run some code and, say, show a message box, what files are already extracted at that point? If the dependencies are extracted, can you ensure that its directory is on the DLL path via SetDllDirectory or AddDllDirectory? If the dependencies are not extracted, are they present at a later point so approches like delay loading could help?
For the third point, Process Monitor may help you diagnose what's going on if you can't get a message box in there, but it will probably be less clear. Alternately, using Loader Snaps and Debug View might get you a related set of information, but it may be drowned in additional noise.
I have an application that was shoddily created which resulted in some very sensitive information ending up being potentially very visible within the App.exe.config file after an install. I am presently banging my head against the wall in a thus far futile attempt to delete and replace the .config file via an application update, but all attempts have, as previously stated, proved futile.
My employer is laboring under what I believe to be the delusion that removing the lines in the config file is as simple as writing something into the program that looks at the .config file and deletes them, however 1: I do not think it is that simple and 2: That the file is not being updated with the more recent is indicative of a larger problem that needs to be resolved.
I have tried (in the setup and deployment project) setting the "Remove Previous Versions" to true, and I've incremented both the installer version number and the application version number forward, but neither have worked.
Why is the installed applications app.exe.config not being removed/replaced/updated?
When incrementing your version number make sure you increment at least the third section which is the build number, the fourth section is the revision number which will not force a replacement of the older file. See this MSDN link http://msdn.microsoft.com/en-us/library/aa370859(v=vs.85).aspx
The format is Major.Minor.Build.Revision
From link:
Note that Windows Installer uses only the first three fields of the product version. If you include a fourth field in your product version, the installer ignores the fourth field.
In a Visual Studio 2010 solution, I have 2 projects:
Project A which is a dll project
Project B which is an executable project and depends on project A (configured through the solution project dependencies properties)
When I add new APIs in project A declared with __declspec(dllexport) specified and call them from project B.
If I simply "Build" the project B, it turns out that project A is built then project B but the linker does not find the new APIs and report them as unresolved external symbols.
Now if I "Rebuild" the project B, the solution is fully rebuilt and I do not have unresolved symbol linker errors.
Any idea what could cause the builder to not find the new symbols using a simple Build action and how to fix this?
Pretty hard to explain this with the info you provided. It clearly strongly suggests a build order problem, even though you documented that A gets built first.
You may have a problem with the parallel build feature available in VS. If it doesn't see any dependency between projects then it allows projects to build concurrently, taking advantage of your machine having multiple cpu cores. You can see A starting building but B starts building right away as well. Indicated with a numbered messages in the Output window, preceded with 1> and 2>.
If there actually is a dependency then it becomes a race. If B progresses to the link stage before A is done linking then it will certainly have trouble. But that is typically announced by it complaining it cannot find the import library for the DLL project. It finding an old version of A.lib that is missing some identifiers would be an unusual corner case. Things do however get interesting when it finds A.lib while it is being written. Which does explain what you observed.
Best thing to do is to ensure that VS knows there is a dependency without relying on it figuring it out by itself. It is not very good at figuring this out for C or C++ projects. Right-click your B project in the Solution explorer window and click "Project dependencies". Tick the A project. Now it will no longer build concurrently, B won't start building until A is done. Which is essentially what you did by hand to work around the problem.
If you still have trouble then you'll need to suspect other programs on your machine, the kind that mess with files. Anti-malware software is always on the top of the list of troublemakers like that. Avast is especially notorious for giving VS a hard time.
I have a question does it happens every time? It should not. Build command links, create binaries, find resources depending on the existing resource. No, if you change any resource like library, images form designs etc. Then you need to rebuild (clean+build).
To make a project build before another project build. You have to add dependency by this:
Right click to solution>properties.
Go to Project Dependencies > Select the project and tick the dependent project.
Finally right click to your project B select Set as StartUp Project.
This will force your project to build sequentially.