I'm trying to install GNAT Compiler for Ada programing, but when I launch it I get the following error: "Cannot create config directory C:/users/##$%##%##/.gps/ Exiting...".
Somebody knows the solution?
I try all kind of things, nothing helped.
Thanks
I have Cygwin installed on Windows XP, with GPS from GNAT GPL 2012.
If I have %HOME% set to C:\cygwin\users\%USERNAME% and start GPS for the first time, GPS says that it created the configuration directory C:\cygwin\users\simon\.gps. If I don't set %HOME%, GPS creates the configuration directory C:\Documents and Settings\Simon, which appears to be %HOMEPATH%. Note that GPS isn't aware of Cygwin, it's a Windows application and uses your Windows environment variables.
I wonder whether you have %HOME% (or perhaps %HOMEPATH%?) set to a nonexistent directory? GPS doesn't seem to be able to create intermediate directories.
I am not an Ada wiz but I remember that I tried to install Gnat GPS with Cygwin as well and had all sorts of problems. One of the biggest was the 64/32 bit incompatibility since Gnat on Windows is only available in the 32 bit version and Cygwin is probably in the 64 bit version on your machine
In the end my solution was to remove Cygwin completely and install Mingw32, which is the system Ada uses.
Related
How do I avoid installing same programming languages both in WSL and Windows10?
I am thinking about using WSL as a dev workspace. However, I realized I will need to install Node.js, Python, create-react-app, and so on in WSL even though my windows 10 already have them installed.
It would be helpful if you could spare me some advice.
Thanks.
To some degree, it depends on what type of development you are doing. Given your example languages/tools, I'm going to assume that most of your development is platform agnostic, web-development, etc.
My recommendation is to go all-in on WSL and install the Linux versions of the tools you use (with some notable exceptions covered below).
Uninstalling the Windows versions is recommended, but not strictly necessary. I recommend uninstalling because I continue to see a number of questions across the Stack sites where it becomes apparent that the Windows version of Node or Python is getting called from inside WSL. It's likely that some tool, such as nvm or equivalent, attempted to prepend the Windows Node or Python location to the Linux path.
This causes problems, as the Windows versions Node and Python understand Windows paths and processes. When you call them from the Linux shell in WSL, the shell/OS uses, of course, the Linux versions. And Windows Python just won't understand something like /mnt/c/Projects. It needs C:\Projects. You can work around this with utilities such as wslpath (automatically installed in some WSL distributions, installable in all others), or you could just manually adjust the path. But ... why go through the hassle if you don't need to.
Just use the Linux versions, with the corresponding Linux paths and instructions. Most development tools, tutorials, instructions, etc. are going to "default" to the Linux doc. It will typically be more complete, more up-to-date, etc.
And, of course, the Linux command-line experience is (subjectively, sure) far-and-above better than PowerShell. Don't get me wrong, I like PowerShell, but I like PowerShell even better when I call it through WSL (powershell.exe or pwsh.exe), since I can take advantage of Linux niceties like less (or bat), jq, and many others.
Not to say there aren't WSL caveats that you have to get used to. Be prepared to run into a few snags here and there (lack of Systemd support, permissions, filesystems, inotify), but most everything has a workaround that you'll typically find here on Stack (Stack Overflow, Ask Ubuntu, Unix & Linux, and/or Super User) if you search.
And for those "notable exceptions" I mentioned, I recommend installing:
Windows Terminal (available in the Microsoft Store), which will provide an upgraded terminal experience for WSL.
The Windows version of Visual Studio Code -- I've seen a question from someone here who tried to install the Linux version. It's just not necessary. Microsoft has done a great job of integrating the Windows version of VSCode with WSL. Just install the "Remote Development" extension pack, which includes the "Remote - WSL" extension.
I have created a c# application in ubuntu using monodevelop. It is running well in ubuntu.
I tried to run that application(firstgtk.exe file created after running in ubuntu)in windows.But it showing error message.How can i make to portable in both linux and windows?
The error message is:
when i click the firstgtk.exe file, a command prompt has come.It is blank. At the same moment microsoft message(send Error report or don't send):
firstgtk has encountered a problem and needs to close.
When i click don't send button, command prompt and message box are gone.
Mono compiles down to CIL code and is completely portable to .NET or Mono on other platforms. I can compile my C# code on a Mac and run the resulting EXE on Linux or Windows under either .NET or Mono.
Without the actual error message we can only guess the issue here. That said, in my experience, the most common reasons an application written in Mono on Linux/UNIX would create an error on Windows are pathnames with platform specific path separators or case sensitivity issues. The Windows file system is not case sensitive but they are on Linux/UNIX.
Another possibility is that you are using Mono on one platform and trying to run it on .NET on the other. Mono ships with a number of libraries that are not present in .NET on Windows.
Actually, I guess a final possibility is that GTK# is a common way to produce GUI code on Mono. GTK# relies on the GTK+ C library being present which is very common on Linux but unlikely on Windows unless it has been explicitly installed.
We really need to know what the error message was.
If you're using Gtk#, your app is portable between Windows and Linux. My guess is that you don't have Gtk# installed correctly (or at all?) on Windows. You can download from here. As of this time the latest version is 2.12.10.
Your code should be portable between Linux and Windows. Alas, the binaries are not. ...
Edit: As commenters have pointed out, Mono does produce and use PE executables, though other issues may limit portability.
Has anyone had a problem running Clojure Box in Windows 7?
I am trying to run a fresh install of Clojure Box on a fresh install of Windows 7 Professional (64 bit). Java version on system is 1.6.0_16.
emacs starts up but produces the following error messages:
Warning (initialization): An error occurred while loading `~/.emacs':
File error: Searching for program, no such file or directory, java
As a newbie at emacs, slime, swank, paredit, Clojure and Clojure Box, I'm not even sure where to start. I can't even find `~/.emacs'
Thanks for any help you can provide.
Is the directory you installed Java to on your PATH?
I also got the same error by not having Java installed at all prior to installing Clojure Box. It'd be nice if the installer checked for Java's presence and PATH-belonging. Once Java was installed, Clojure Box was working correctly.
You may create .emacs file yourself. See this answer.
One gotcha is that there is a emulation of the 32 bit process on the 64 bit version of Windows so you need to add java files to C:\Windows\SysWOW64 even if you have it in C:\Windows\System32 folder.
Seems like there wouldn't be, but it would help us out if there was. I wish to pull the source down to a windows server and compile it and have it be the same as if I had pulled the source code down to a mac machine and used xcode on it. Any Ideas?
Reasons: Release Engineering and IT are much more familiar and comfortable on windows, so it would be easier on us, and LaunchD sucks.
Your original question had less detail... I think you are creating more problems than you are solving buy not using a Mac. Is it really that hard to learn to compile under Xcode or type make in the console?
Anyway...
Apple uses a modified version of the GCC C/C++/Objective C compiler with a proprietary runtime library... You could develop using a port of this code to Windows. See GNUStep.Org. This is not binary compatible though but it isn't impossible that you could rebuild it to cross compile to something that was Mac OS X compatible.
Another idea would be to develop using c# .NET and then move the binaries across to Mac OS X and run the binaries using Mono....
None of these options are robust enough to allow you to do this blind without a Macintosh to test and get up and running in the first place.
You can compile cross app with Cocotron but only on Mac
Why do you need launchd? cron works just as well on Mac as it does on Linux, just have a cronjob that does (Extremely simplified version ahead):
cd /my/source/dir
git pull # You are using Git, right?
xcodebuild MyCoolProject.xcodeproj
cp -r build/MyApp.app /the/distribution/folder
I know that MAC OS X 10.5 comes with Apache installed but I would like to install the latest Apache without touching the OS Defaults incase it causes problems in the future with other udpates. So I have used the details located at: http://diymacserver.com/installing-apache/compiling-apache-on-leopard/ But I'm unsure how to make this the 64 Bit version of Apache as it seems to still install the 32 bit version.
Any help is appreciated
Cheers
Add this to your ~/.bash_profile which means that your architecture is 64-bit ant you’d like to compile Universal binaries.
export CFLAGS="-arch x86_64"
This page claims that a flag for gcc (maix64) should do the trick. Give it a whirl, and if you need any more help, post back here.
Be aware that you may run into issues with your apache modules. If they are compiled in 32-bit mode, then you will not be able to load them into a 64-bit apache.
I had this issue with mod_python, took a bit of thinking to figure out this was the reason.
Don't export CFLAGS from your .bash_profile or any other dot file. Your home directory could live on for decades, the system you're currently using is transient.
There's a guide on Apple's web site, Porting UNIX/Linux Applications to Mac OS X, that talks specifically about how to make autoconf and make and other similar build systems fit into the Mac OS X Universal Binary scheme. If you're going to build cross-Unix applications on Mac OS X, you need to read and understand this guide.
That said, I strongly question why you want to build Apache 64-bit. Just because Leopard can run 64-bit software doesn't mean you want all software on your system to be 64-bit. (It's not Linux.) In fact, virtually none of the software that ships with Leopard runs 64-bit by default, and most of the applications included with Leopard only ship 32-bit.
Unless you have a pressing need to run Apache 64-bit, I wouldn't bother trying to build it that way.
If you would have read a bit further on the same site there is some information on compiling Apache in 64 bits mode!
http://diymacserver.com/2008/10/04/update-on-64-bits-compilation/