I recently downloaded and installed the Groovy-2.2.0 windows binary, configured my system, i.e., Java is installed and functioning properly, etc. My GROOVY_HOME variable is set to C:\groovy-2.2.0, my path is set to C:\groovy-2.2.0\bin and C:\groovy-2.2.0\lib. However, unlike Groovy 2.1.9, the groovysh command generates a flood of errors (too long to post here) about an inability to run groovystarter. I'm using a WinXP (sp3) machine with Groovy-2.2.0 installed. Oddly, I can compile and run groovy programs. It is only the groovy shell that isn't functioning.
Thanks to a few helpful individuals, i.e., Guillaume, Cédric, and Pascal, the posted issue has been solved. There was a subfolder in my root directory, C:\, named C:\jline. I copied its contents to an unused subdirectory (as a backup) then deleted the C:\jline folder. After doing so, the groovysh command worked perfectly. I felt compelled to post the solution in the event another programmer experienced the same or perhaps highly similar and related problem.
~Caitlin
Related
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...
I have a a problem sounds pretty wierd. I compiled a program in Qt and it ran successfully.
But when I navigated to the release folder in the konsole and ran the program (even with super user), it reported :
If 'HelloWorld' is not a typo you can use command-not-found to lookup the package that contains it, like this:
cnf HelloWorld
I checked the permissions, all users can read it.The path is right. I'm out of way.
Please help me!
Note: I use Qt 4.74 on OpenSuse 12.1. Just switched from windows few days ago
I think this ain't relate to the source code, since even a simple HelloWorld program can't run either
If the program is in the current directory, make sure you run it with a prefix indicating so:
./HelloWorld
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.
I'm using Netbeans on Linux (Ubuntu 9.04) to build a C project.
How do I pass in an environment variable so that's it's visible to the Makefile?
If I do a normal export MYVAR="xyz" and then run make from the command line this works fine of course.
But Netbeans doesn't seems to use the .bashrc environment, so if I click "build" in Netbeans, the make fails.
Interestingly, the problem doesn't seem to occur on MacOSX - I've added the variable to ~/.MacOSX/environment.plist, and that value is visible to Netbeans.
I found this post which suggested modifying ~/netbeans-6.8/etc/netbeans.conf. I've tried this, by adding -J-DMYVAR=xyz to the end of netbeans_default_options, ie:
netbeans_default_options="-J-client -J-Xverify:none -J-Xss2m -J-Xms32m -J-XX:PermSize=32m -J-XX:MaxPermSize=200m -J-Dapple.laf.useScreenMenuBar=true -J-Dsun.java2d.noddraw=true -J-DMYVAR=xyz"
But this didn't seem to work.
Edit:
This answer is possibly not valid for Unity-based flavours of Ubuntu.
The issue is actually nothing to do with NetBeans - it's related to the Ubuntu (ie Gnome) Launcher.
As this blog post explains, you need to add variables to the rather obscure ~/.gnomerc (No Mercy? :) file in order for them to be passed to applications started with Launcher!
So just edit ~/.gnomerc and add the variables as you would to ~/.bashrc, eg:
export MYVAR="xyz"
and logout/login.