I'm trying to install and use oracle_fdw in postgresql 9.6, however I keep receiving the same issue every time that I run the following command:
create extension oracle_fdw;
ERROR: could not load library "D:/PostgreSQL/pg96/../pg96/lib/postgresql/oracle_fdw.dll":
The specified module could not be found.
Two things are very strange here:
the folder that it's looking for the dll, has a ".." in the middle, so it seems it should look into D:\PostgreSQL\pg96\lib only, but I do have the folder D:\PostgreSQL\pg96\lib\postgresql as well.
I set the following variables in the system, but it seems not to reflect in the command:
Path: D:\PostgreSQL\pg96\lib\;C:\Program Files\Oracle Instant Client\instantclient_12_2;
D:\PostgreSQL\pg96\lib\postgresql
Are you guys able to help me? I really need specific instructions on how to make it work.
Tks!
This looks like an issue with the Postgres distribution you are using rather than oracle_fdw itself. It might be a better idea to reach out to the distribution packagers.
Looking at the paths in your errors I am assuming you are using the Bigsql distribution. You can try posting the question on their feedback page, they are generally quite responsive.
The .. in your path is strange, but should not be a problem. What is the value of the parameter dynamic_library_path?
Is oracle_fdw.dll in D:/PostgreSQL/pg96/lib/postgresql?
I assume that oci.dll is in C:\Program Files\Oracle Instant Client\instantclient_12_2.
Did you check that all programs involved (PostgreSQL, oracle_fdw and Oracle) are either all 32-bit or 64-bit?
If all that is ok, the problem must be that oci.dll is not on the shared library search path of the PostgreSQL server.
Are you sure that the PostgreSQL service has got the PATH setting you show? Did you restart PostgreSQL after you changed the PATH environment variable?
Many are running into this issue and I got it resoved in most cases.
Oracle Client libraries are compiled using specific version of Visual C++. So we need to have Visual C++ redistributable package of that particular version of Visual Studio is required in the system.
Second dependancy is coming from oracle_fdw.dll. Lastest community version of oracle_fdw.dll is prepared using Visual C++ 2013. So we need to have Visual C++ 2013 Redistributable package to be present in the system.
Once all such dependanices are solved, it works.
Alaternatively, you can use oracle_fdw.dll prepared by BigSQL project. Since the project is built using MSYS2, there is no dependancies to Visual C++. However the dependancy created by Oracle client libraries cannot be avoided.
Related
I am new in Point Cloud Library and I would like to know how can I install it on my computer. I have already installed PCL 1.6.0 and Microsoft Visual Studio 2010 but I can't manage to use PCL. I understand that I am supposed to set references at some point but I am totally clueless as how and when I should do it.
I have been trying to follow the instructions at http://unanancyowen.com/?p=1255&lang=en but when I get to :
Set the environment variable for PCL and 3rdParty.
Variable Name Variable Value
PCL_ROOT C:\Program Files\PCL 1.7.2(or C:\Program Files (x86)\PCL 1.7.2)
Path ;%PCL_ROOT%\bin
;%PCL_ROOT%\3rdParty\FLANN\bin
;%PCL_ROOT%\3rdParty\VTK\bin
I am totally lost...
I have never used neither Visual Studio nor PCL before.
I am using windows7 64bits
If you could hint me in the right direction or direct me to a tutorial that I could understand, that would be very helpfull !!
Thanks in advance!
Your PCL version is not right...I use PCL 1.7.2 and VS2012 on Win8.1, and it's the same on win7.
Look at this tutorial(It's in chinese and you can use google translate, I follow it and succeed to run PCL1.7.2 on my VS2012):
I used the website you mentioned to install pcl in my computer. And it works just fine. And quite detailed compared to other tutorials. From your question, I understand that you have trouble adding the path to the environment variables. If thats not what you are having trouble with, let me know.
The environment variable helps the visual studio compiler to find the paths to PCL libraries during run time. So, after installing PCL, we need to tell the computer where we have installed pcl and pcl bin files and the supporting 3rd party libraries. You do that by editing the path.
As for how to set the environment variable, go through this tutorial: http://www.computerhope.com/issues/ch000549.htm
I have a problem with our executable. I'm running this C++ 32-bit executable on my Windows 7 64-bit development box that also has all those Microsoft applications (Visual Studio 2008 + 2010, TFS, SDK, Microsoft Office)...
And it's still running just fine.
Now I got the client installation of the very same program and was asked to test it with a clean Windows 7 installation. Thus I got one Windows 7 64-bit VMware and updated it to Windows 7 SP 1 (the very same version my developer box is tuning).
But while on my developer box everything is fine the program does not work with the VMware (30 days trial) box.
The x86 Dependency Walker is telling me that the following DLL files are missing:
API-MS-WIN-CORE-COM-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
DCOMP.DLL
GPSVC.DLL
IESHIMS.DLL
I googled for those API-MS-WIN-... DLL files and found they should actually already be part of Windows 7 (some sites claiming the belong to Windows 8 and Windows Server 2012 though).
I already tried the suggested fixes I found, which are:
running 'sfc /scannow'
installing Visual Studio 2008 SP1 runtime executables
But that didn't solve anything. :-(
Side note: My development box does not have them either, and does not seem to need them. For example, the user32.dll on my box does not link against one of those, while the installation on the VMware does.
Any idea on how to fix this issue?
I tried to find a suitable download / fix on the Microsoft pages, but I failed.
After solving my issue I wanted to report what I found out, and I can't post this as an answer because the question has been closed.
Actually all the DLL files reported missing by the Dependency Walker tool, namely those
* API-MS-WIN-CORE-...
type DLL files were not part of the actual problem.
In my case the registration of three OCX files was missing and after that everything was just fine, BUT Dependency Walker tool still listed all the very same DLL files as before even when the program was just running fine now.
The gist of it: As someone elsewhere stated, the tool is a bit dated by now and does not always work properly with a newer OS. Thus keep an eye open and don't get mislead by missing 'API-MS-WIN-CORE-COM-L1-1-0.DLL', ... the problem probably lies entirely elsewhere.
This problem is related to missing the Visual Studio "redistributable package." It is not obvious which one is missing based on the dependency walk, but I would try the one that corresponds with your compiler version first and see if things run properly:
Visual Studio 2015
Visual Studio 2013
Visual Studio 2010
Visual Studio 2008
I ran into this problem because I am using the Visual Studio compilers, but not the full Visual Studio environment.
Going to dare to inject a new link here: The latest supported Visual C++ downloads. Stein Åsmul, 29.11.2018.
I just resolved the same problem with C++ Qt 5 and Windows 7 64 bits with MSCVC 2012.
In the beginning I thought it was a MSVC/Windows DLL file problem, but as BorisP said, the problem was in my project dependencies. The key is "How to know your project dependencies in Qt 5?".
As I didn't find any clear way to know it (Dependency Walker didn't help me a lot...), I followed next the "inverse procedure" that takes no more than 5 minutes and avoid a lot of headaches with DLL file dependencies:
Compile your project and take the executable file to an empty folder: myproject.exe
Try to execute it, It will retrieve an error (missing DLL files...).
Now, copy all the DLL files from Qt (in my case they were in C:\Qt\Qt5.1.1\5.1.1\msvc2012_64_opengl\bin) to this folder.
Try to execute again, it will probably works fine.
Start to delete progressively and try every time your executable still works, trying to leave the minimum necessary DLL files.
When you have all the DLL files in the same folder it is easier to find which of them are not valid (XML, WebKit, ... whatever..), and consequently this method doesn't take more than five minutes.
I just resolved the same problem.
Dependency Walker is misleading in this case and caused me to lose time. So, the list of "missing" DLL files from the first post is not helpful, and you can probably ignore it.
The solution is to find which references your project is calling and check if they are really installed on the server.
#Ben Brammer, it is not important which three .ocx files are missing, because they are missing only for Leo T Abraham's project. Your project probably calls other DLL files.
In my case, it was not three .ocx files, but missing MySQL connector DLL file. After installing of MySQL Connector for .NET on server, the problem disappeared.
So, in short, the solution is: check if all your project references are there.
As mentioned, DCOMP is part of the VC++ redistributables (implementing the OpenMP runtime) and is the only truly missing component. All the rest are false reports.
Specifically API-MS-WIN-XXXX.DLL are API-sets - essentially, an extra level of call indirection introduced gradually since Windows 7. Dependency Walker development seemingly halted long before that, and it can't handle API sets properly.
So there is nothing to worry about there. You're not missing anything more.
A better alternative to find the truly needed DLL files that are missing (if that is indeed the problem) is to run Process Monitor and step backwards from the failure, searching for sequences of failed probes for a specific DLL file in all the system path.
I also ran into this problem, but the solution that seems to be a common thread here, and I saw elsewhere on the web, is "[re]install the redistributable package". However, for me that does not work, as the problem arose when running the installer for our product (which installs the redistributable package) to test our shiny new Visual Studio 2015 builds.
The issue came up because the DLL files listed are not located in the Visual Studio install path (for example, C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\redist) and thus had not been added to the install. These api-ms-win-* dlls get installed to a Windows 10 SDK install path as part of the Visual Studio 2015 install (e.g. C:\Program Files (x86)\Windows Kits\10\Redist).
Installing on Windows 10 worked fine, but installing on Windows 7 required adding these DLL files to our product install. For more information, see Update for Universal C Runtime in Windows which describes the addition of these dependencies caused by Visual Studio 2015 and provides downloads for various Windows platforms; also see Introducing the Universal CRT which describes the redesign of the CRT libraries. Of particular interest is item 6 under the section titled Distributing Software that uses the Universal CRT:
Updated September 11, 2015: App-local deployment of the Universal CRT is supported. To obtain the binaries for app-local deployment, install the Windows Software Development Kit (SDK) for Windows 10. The binaries will be installed to C:\Program Files (x86)\Windows Kits\10\Redist\ucrt. You will need to copy all of the DLLs with your app (note that the set of DLL files are necessary is different on different versions of Windows, so you must include all of the DLL files in order for your program to run on all supported versions of Windows).
This contribution does not really answer the initial question, but taking into account the hit-rate of this thread I assume that there are quite a few people dealing with the problem that API-MS-WIN-CORE- libraries cannot be found.
I was able to solve a problem where my application refused to start with the error message that API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL is not found by simply updating Visual Studio.
I don't think that my build environment (Windows 7 Pro SP1, Visual Studio Ultimate 2012) was messed up completely, it worked fine for most of my projects. But under some very specific circumstances I got the error message (see below).
After updating Visual Studio 11 from the initial CD-Version (I forgot to look up the version number) to version 11.0.61030.00 Update 4 also the broken project was running again.
This solved the issue for me:
Uninstall the Visual Studio 2010 redistributable package if you have it installed already, and then install Microsoft Windows 7 SDK.
I solved the problem. When I registered the OCX files, I ran it with the Command Window that had been executed as an administrator.
For anybody who came here, but with a Photoshop problem: my solution was to uninstall the MS VC++ redistributable first x86 and 64 both. Then install one appropriate to the Windows version and architecture (86 or 64).
Installation of SQL Server Management Studio 2014 on a freshly installed Windows 7 resolved this problem at our client after a two-day ridiculous battle.
I came here with this problem occurring, after trying a fresh Windows 7 OEM install, upgrading to Windows 10.
After some searching of Microsoft forums and such I found the following solution which worked for me:
Replace C:\Windows10Upgrade\wimgapi.dll with the one from C:\Windows\System32\wimgapi.dll
I suggest also checking how much memory is currently being used.
It turns out that the inability to find these DLL files was the first symptom exhibited when trying to run a program (either run or debug) in Visual Studio.
After over a half hour with much head scratching, searching the web, running Process Monitor, and Task Manager, and depends, a completely different program that had been running since the beginning of time reported that "memory is low; try stopping some programs" or some such. After killing Firefox, Thunderbird, Process Monitor, and depends, everything worked again.
I had the same problem. After spending hours searching on the web, I found a solution for me.
I copied the file combase.dll file (C:\Windows\System32) to the release folder, and it resolved the problem.
Just to confirm answers here, my resolution was to copy the DLL that was not loading AND the ocx file that accompanied it to the system32 folder, that resolved my issue.
Just installed WebMatrix and upgraded Visual Studio 2012 to Version 4.5.50709 SP1Rel. Now when I open my webapplication I get a bunch of errors of this type:
'IIf' is not declared. It may be inaccessible due to its protection level.
'IsNothing' is not declared. It may be inaccessible due to its protection level.
'IsNumeric' is not declared. It may be inaccessible due to its protection level.
I get so many errors that I even get this:
Error 104 Maximum number of errors has been exceeded.
It turned out that during WebMatrix installation or Visual Studio upgrade MySql Connector version 6.5.4.0 was also installed.
Somehow MySql Connector v. 5.1.5, which my project were referring was uninstalled in the process.
Reinstalling MySql connector 5.1.5 solved the issue. Changing the reference to the new MySql connector would probably also solve the issue.
I just ran into the same problem in VS 2012 when attempting to copy over an old version of a program I received from another colleague.
As muleskinner says, it is not a reference issue to Microsoft.VisualBasic...
When you try to add that as a reference it will tell you that it is already automatically referenced by the build system.
It turns out that even though Microsoft.VisualBasic is automatically referenced, the project didn't actually have the namespace imported.
You can add it by going to the properties of your project -> References -> And then make sure that Microsoft.VisualBasic is checked in the list of namespaces at the bottom.
At least that worked for me and cleared up all my errors. Wasn't relishing trying to change all my IIf statements into the more traditional format...
Source code that compiles fine on other peoples environments won't correctly work in my environment. When I do a rebuild the compile occurs but when visual studio goes to move the exe from /obj/debug/{solution} to /debug/{solution} it cannot find the exe in the /obj/debug/{solution}. To make this even more crazy even after I reinstall visual studio it doesn't work. On other people environments it works find. Please note that this is a windows mobile 6, compact framework 3.5 project, Visual C++ project.
EDIT: Visual Studio 2008 is being used.
EDIT2: After looking at the logs again come to find out it says it is compiling but it isn't really compiling. Interesting enough it doesn't throw any errors until it tries to link the code. When it goes to link the object files, they aren't there and it fails.
I got TWO Release folders: one in the solution folder and one in the project folder. The former contains the .exe file, the latter does not.
In the solution properties page, check whether the path you are expecting the exe to be is same as the one specified in Linker -> Output file.
Another obvious mistake could be, check what build configuration you are building. You might be doing a release build and expecting a debug executable file :) I have done this a few times.
Maybe VS creates the exe, and before it tries to move it to the final destination your virus scanner grabs it and removes it, or moves it to a save location.
I just wanted to chime in and ask: have you looked for the *.exe file name from the directories above? What I found in my case was it was writing to the directory right above the /release subdirectory. Not sure how I missed that detail, but I did! I suppose it never occurred to me earlier because I saw the buildlog.htm being written to the /release subdirectory, and the very existence of the directory itself. In my case it was compiling, linking, etc. I just wasn't able to see the *.exe in that /release subdirectory.
There are two subtly different paths. I was looking here, which doesn't exist:
C:\Users\james\source\repos\CppHelloWorld\Release\CppHelloWorld.exe
The actual exe is here - note the path contains the x64 platform that it was built for:
C:\Users\james\source\repos\CppHelloWorld\x64\Release\CppHelloWorld.exe
In general, the path seems to be:
$PROJECT_PATH\$PROJECT_NAME\$PLATFORM\$CONFIGURATION\$PROJECT_NAME.exe
If the exact same solution works on other machines, then it's an environment problem and no amount of looking at the project, linker, etc is going to resolve this. What is different about the environments? Are the same service packs and QFE's applied for not just Studio, but also the OS? Is there a difference in processors (64/32-bit)? Are your permissions the same? Do you have the same SDKs installed?
I'd agree with Shahi that just trying to build a "hello world" app against the same SDK and see if it will compile is valuable info.
I had exactly the same problem. Just close Visual Studio and reopen it again (basically restart it) and it should work.
In my case, my network security team released an unannounced security update that preventing me from creating any .exe files. I figured that out at midday after trying all the solutions (+ more) here.
Perhaps you do not have write permission to the output folder? If you are running on Vista/7, is your Visual Studio running as elevated?
I've found this to be random for myself in now VS2016. My work around has been to just create another project and copy the contents from the one with out the .exe to the new one. For some reason the new one normally will have the proper .exe and location needed. While this isn't a complete solution at least it's been working for me for the time being.
It happened with me today:
TL;DR; You might be using some C# code in your project who belong to a language version which is not supported by the .NET Framework version targeted by your project
Details:
I had two projects in my solution. One project was already existing. I added a new project targeting most recent .NET Framework v4.6.1 supported by Visual Studio(VS) 2017 class library project template. I used some C# language features which is present in C# v7.0. In such a case, VS can compile the project but can't create the output in bin directory.
Eventually I had to merge the new project code files into the existing old project which was targeting .NET Framework v4.5.1.
So I changed the target Framework version to the latest .NET Framework v4.6.1 for the existing projects also. Then the old project also started supporting my newly pasted C# language features.
In my case, the error appeared after I cloned my solution on a new machine.
I did not realise that the newly-cloned solution had AnyCPU set by default, when in reality my solution only supported x64. The compiler, however, did not return any error.
What pointed me in the right direction was the Output log, highlighted that of the 4 projects my solution was composed of, one of them was always skipped, i.e. only 3 were actually compiled. Scrolling up a bit the log, I noticed some message similar to MSIL mismatch between CPU versions.
Switching from AnyCPU to x64 solved the error for me.
(I then deleted the AnyCPU option from the Configuration Manager to avoid this issue in the future)
If you create a new "hello world" WM project, does it work?
If so, you can compare the solution files to check for differences that can cause this.
As far as I could tell, you need to "Save All" before building.
i have downloaded boost_1_42_0,zip but i'm not sure how to set it up. does http://www.boostpro.com/download/boost_1_42_setup.exe has to do something with it?
If you are only going to use header only libraries in Boost then all you need to do is extract the source archive and add an include path to your project to the Boost root location. There's a, possibly not up to date, list of which libs need to be compiled in the Getting Started docs (see Section #3). If you do need to compile things you can follow the instructions in the Getting Started (see 5.2 and/or 5.3). The BoostPro installer is done independently and hence isn't always up to date, although Dave A. And Daniel W. do try to keep it current. But since there's a limit to how many configurations they can account for it has limits as to having the kind of binary you will need, and of course it's only for Visual Studio.
IIRC, the boostpro setup is an alternative way to get Boost running on your system. It is smallish program that starts by asking you which libraries and configurations you want, and then downloads the necessary files on the fly. It is much easier and faster to get going this way than by building from source, but it isn't always up to date, particularly just after a new source release, and only supports Microsoft's compilers, AFAIK.
Boost Getting Started on Windows
How to use Boost in Visual Studio 2010
Boost linking, Visual Studio & version control
Using Boost on Windows (Visual Studio)
Including Relevant Boost Libraries with C++ Source (Using Visual Studio)