I have instaled Cygwin after running MinGW for a while now. But when I try to compile the console gives me:
/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/cc1.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory
What does this mean?
I have the same problem and I found the solution.
According to the FAQ of Cygwin
Q: Why is C:\cygwin\usr\bin invisible from windows?
A: Because it does not really exist. In cygwin, /usr/bin is just a link to /bin.
So trying to add "C:\cygwin\usr\bin" to PATH will be in vain.
Add "C:\cygwin64\bin" to PATH instead. Hope this helps :)
You are missing a library, please run cygcheck /usr/lib/gcc/x86_64-pc-cygwin/4.9.2/cc1.exe or ldd /usr/lib/gcc/x86_64-pc-cygwin/4.9.2/cc1.exe to see what is the missing library.
(I'd rather ask a question in the comments first, but I don't have enough reputation yet.)
Your cc1 is unable to load some DLLs it needs to start. Looking at the Cygwin source code, this can be either a library specified in LD_PRELOAD, or -- more probably -- a library the executable depends on. The ? in the error message seems to be the default return value of find_first_notloaded_dll (hookapi.cc), in case the function can't determine what library is missing.
To diagnose the issue, I suggest checking your PATH variable (or even clearing it of any non-Cygwin paths and trying the compilation again) and/or using Dependency Walker to find the missing DLLs (start it from a Cygwin shell, so it can see the same PATH). ldd (included with Cygwin) may also give some clues, but I wouldn't bet on it.
It's possible a clean re-install of Cygwin will be necessary to solve the issue.
Most likely, you are simply missing /usr/bin in the PATH variable.
Adding 'export PATH=/usr/bin:$PATH' to your .bashrc file will solve the issue.
Adding some background info. I had the same problem when building my own program and linking it against graphviz cgraph.dll. Turns out this is related to where windows searches for DLLs (see here: https://msdn.microsoft.com/en-us/library/7d83bc18.aspx) So adding the path of your missing library to PATH should fix the problem.
It is unfortunate that the message doesn't include the name of the library. Luckily cmd.exe DOES give you this name (so it's good for something after all;)
Are you including the path to your lib directory?
Looks like you are not
I'm not very familiar with Cygwin, I mainly use MinGW, but I think the error message speaks for itself
I also came this error on windows machine while executing .exe file generated by scilab2C i.e toolbox for Scilab
For Windows 32 bit Add the environment variable path as follow :
C:\cygwin\usr\i686-pc-cygwin\bin
Hope so this will solve your issue.
Just had this problem trying to compile a package with make and it wanted some cygguile dll file that was just installed along with make.
My solution was I had not only migrated my cygwin64 directory across drives because the sector sizes were mismatched for some reason even though the drivers were both under 2TB and should have been using 512 byte sector sizes.. So I had to install a new system and move files over there, might have had weird permissions on them.
Also had to patch cygwin1.dll end of Jan 2020 because of a recent input problem in ConEmu with Windows 10 1903 build, but just did it again with this working so that doesn't seem to be the issue.
Reinstalling cygwin by deleting that entire directory, taking ownership of it first.., seemed to work now...
Related
I have installed gprbuild, xmlada, and gnatcoll. I am now attempting to install gnatcoll_postgres. Which I have downladed from here: https://github.com/AdaCore/gnatcoll-db/
Within the Postgres folder is a Makefile, which I execute like so...
[parallels#localhost postgres]$ ls
gnatcoll_postgres.gpr gnatcoll-sql-postgres-gnade.ads
gnatcoll-sql-postgres.adb gnatcoll-sql-ranges.adb
gnatcoll-sql-postgres.ads gnatcoll-sql-ranges.ads
gnatcoll-sql-postgres-builder.adb Makefile
gnatcoll-sql-postgres-builder.ads postgres_support.c
gnatcoll-sql-postgres-gnade.adb README.md
[parallels#localhost postgres]$ make Makefile
which: no gnatls in (/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/var/lib/snapd/snap/bin:/home/parallels/.local/bin:/home/parallels/bin)
make: Nothing to be done for `Makefile'.
[parallels#localhost postgres]$
Would anybody please be able to tell me what this means...
which: no gnatls in (/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/var/lib/snapd/snap/bin:/home/parallels/.local/bin:/home/parallels/bin)
make: Nothing to be done for `Makefile'.
Any help would be greatly appreciated.
Please see the xmlada and gnatcoll in my project below, does this look like it's installed correctly? I'm presuming this isn't correct...
Thanks,
Lloyd
It means that your GNAT installation binaries aren’t on your PATH.
The README.txt from the adacore.com site says, in part,
To start using the tools in command-line mode, you will need to add
{install_prefix}/bin
to your PATH environment variable. Alternatively, you can simply launch
{install_prefix}/bin/gps
and GPS will automatically add itself to the PATH - it will also find the
cross compiler, if you have installed everything in the default locations.
Note that GPS will add this at the end of the PATH, meaning that it will find first any other GNAT installations that you have in your PATH.
I strongly suspect that you’ve been doing the latter, so that GPS adds itself (actually, of course, its own location) to the PATH, so that when it launches the compiler it finds the correct one.
When you run make from the terminal, the compiler isn’t on the PATH, so neither are gnatls, gprconfig, gprbuild and the rest of the GNAT tools.
What you need to do is to take the first choice from the README, and add /home/parallel/opt/GNAT/2019/bin to (the front of) your default PATH. How you do that depends on your shell.
You will find xmlada, gnatcoll already installed.
I am trying to build NetCDF4 from source on MacOSX. When I run ./configure I get the error:
checking for library containing H5Fflush... no
configure: error: Can't find or link to the hdf5 library. Use --disable-netcdf-4, or see config.log for errors.
I installed hdf5 before, and set the environment variables as:
LDFLAGS=-L/opt/local/lib
CPPFLAGS=-I/opt/local/include
In /opt/local/lib I have these files:
libhdf5.8.dylib
libhdf5.a
libhdf5.dylib
libhdf5.settings
libhdf5_cpp.8.dylib
libhdf5_cpp.a
libhdf5_cpp.dylib
libhdf5_hl.8.dylib
libhdf5_hl.a
libhdf5_hl.dylib
libhdf5_hl_cpp.8.dylib
libhdf5_hl_cpp.a
libhdf5_hl_cpp.dylib
And in /opt/local/include I have:
hdf5.h hdf5_hl.h
Why doesn't the configure script find the hdf5 library? I am happy to provide more information if needed!
EDIT:
My ultimate goal is to install netcdf4 for use as a Fortran module. I have tried installing everything through MacPorts, and it seemed to work, but when I tried to use it, the compiler told me that there was no netcdf.mod file, and sure enough there wasn't one to be found anywhere.
It turns out that just typing:
sudo port install netcdf-fortran
only installs the library files, but doesn't create a .mod file, which I guess is needed. So I found out that other people had the same problem, and the advice given was to install it with gcc44, which did create a .mod file, but then my compiler told me that the .mod file was built with a different version of gfortran and it couldn't be used, so that's why I am trying to build it from scratch, but if someone has a faster option, I would be more than happy to try it!
Ok, I finally figured it out.
I reinstalled netcdf-fortran with macports, then the .mod file suddenly appeared, I then had the problem, however, that when running gfortran, it would tell me that netcdf.mod was compiled with a different version of fortran than the one I am using. (Macports uses 4.8), so got gcc48 from macports and am using gfortran-mp-4.8 to compile now and it works.
Still don't know how to build all these things from scratch, but it works now at least!!!
Typically, I see this when there is a downstream dependency that cannot be fulfilled. The test program created by configure is finding libhdf5, but compilation is still failing because it cannot find something like libz or libszip, depending on how your libhdf5 was compiled.
If you check your config.log file and look for the error, it will probably tell you something along the lines of 'unresolved symbol'. This will give a clue as to which library is missing. If it is linking against the statically-built libhdf5, you may need to add the appropriate library usingLDFLAGS.
If you post the relevant portion of your config.log file, we may be able to help sort out what exactly is going wrong.
Sometimes it doesn't work in the configure parameters like
./configure --enable-shared --enable-fortran --enable-netcdf-4
CPPFLAGS=-I$home/apps2/include LDFALGS=-L$home/apps2/lib --prefix=$home/apps2
or doesn't work when export CPPFLAGS=-I$home/apps2/include in the open SHELL.
Maybe you can set the env vars CPPFLAGS and LDFLAGS in the .bashrc file (prior to the first two ways).
(Note: names of the binary and binary and library below are obfuscated to protect the innocent. ;-) The app is proprietary under NDA but the behavior may not depend on it.)
I have a Linux binary which prints the following error when run:
binary: error while loading shared libraries: libshared.so: cannot open shared object file: No such file or directory
Which is confusing on its own since libshared.so is in the LD_LIBRARY_PATH. However,
The library is found correctly when running ldd binary (i.e., the ldd output points to the file location)
The library is found correctly when running strace binary, so that the program manages to print its usage information!
I have never seen an application which behaves differently when run on its own vs in strace, but I figure maybe someone else has seen this happen before? Any ideas how to resolve this?
I don't have the source so I can't rebuild. Running the app in production under strace is probably a non-starter. The OS is RHEL 6.2.
(Old question, but hopefully this will help somebody else)
Under new Linux installations, LD_LIBRARY_PATH is not used by the standard system runtime linker for programs with SUID set. It appears that strace, gdb and friends work differently, and do use LD_LIBRARY_PATH.
For suid programs, all libraries must be found in the system library cache. Check (as root) whether your "missing" library is present using
ldconfig -p | grep <my_library_name>
and, if anything's missing, add it to a new file in /etc/ld.so.conf or ld.so.conf.d/ as appropriate, and then rebuild using
ldconfig -v
Or remove the SUID bit if it's not required, of course.
This really helped me a lot!
I was having a similar problem where libraries were not being picked up properly from the LD_LIBRARY_PATH, even when the ldd command showed all libraries were satisfied. However, when troubleshooting using strace, it was working. In my case, however, the problem was that SGID (set group ID sticky bit being on). When the files were installed, the sysadmin did a recursive chmod that set it on all files (including the executables). Once the SGID was removed on the executables, the libraries were now found without strace and everything worked as it should using the LD_LIBRARY_PATH.
Whenever I try to run my .exe cobol file, i get this error..
fileName.exe Entry Point Not Found
The procedure entry point_impure_ptr could not be located in the dynamic link library cygwin1.dll
I am using OpenCObol and cygwin ver1.7.15.thanks
You'll need to specify the proper path for the command below, but Cygwin seems pretty persnickety with entry point addresses and updates, The system includes a rebaseall command to help fix this problem. Most times I've witnessed it is after a setup.exe pass, while the Cygwin system was still active (and perhaps only in the background and not visible).
C:\Users\btiffin\cygwin\bin\dash -c '/usr/bin/rebaseall'
Run that from a Windows CMD shell (while Cygwin isn't active, say after a clean boot and before running the Cygwin shell. Basically cygwin1.dll can't be open). You'll need to use the proper Windows path to dash for your particular install. Google Cygwin rebase for detailed articles.
I had a similar error message after upgrading from cygwin version 1.5 to 1.7. I solved it by completely removing and reinstalling 1.7 from scratch. I was told there might have been a problem with multiple versions of dlls.
when trying to install cygwin, I keep getting this error message:
the entry point
rl_filename_rewrite_hook could not be
located in the dynamic link library
cygreadline7.dll
Has anyone seen this before ?
Thanks
I had the same error with cygwin1.dll. I checked in c:\cygwin\bin and noticed there were two files, cygwin1.dll and cygwin1.dll.new (possibly from a failed or aborted setup run?). The ".new" version was in fact newer (and slightly larger) than the existing cygwin1.dll, so I replaced cygwin1.dll with cygwin1.dll.new, and ran setup again. It completed with no errors.
First idea is to try reinstalling libreadline7 (or similarly named package) using the cygwin installer. Use the search field to enter readline to make it easier to find the right package.
Another option is that in the cygwin installer, change form Curr to Prev in order to switch to the previous-stable release. This means lots and lots of downloading and reinstalling. I anctually did manage to provoke my error into becoming a libreadline7 error, and switching to Prev at least got rid of the error messages. (Yay! Now bash, ssh server and git is working again! Back to work here then...)
Please check your path in WINDOWS (advanced system properties) environment. I found that C:\WinAVR\bin was coming before my cygwin path, so I moved that to the end, fixed my issue.
If you have multiple CYGWIN1.DLL files in your system, it definitely causes headaches if you're not careful.