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/
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'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.
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'm doing a little app that I want to distribute in different platforms, at least the 3 major ones.
Is it possible to use only Windows has the host OS to compile the binaries for Linux, Mac OS X and other supported platforms without resorting to virtual machines?
Or should I ask around in some community to help me compile on, well OS X, actually, since I can virtualize a Linux machine quite easy?
It is possible to compile from one plateform to another, it is called cross-compilation. You will find extensive informations at http://www.stack.nl/~marcov/buildfaq.pdf
The buildfaq above contains sample cross-compilation :
from Windows to Linux,
from FreeBSD to AMD64 Linux
The FPC download page contains :
the i386-win32 to x86_64-win64 cross-compiler
the i386-win32 to arm-wince cross-compiler
The FPC mailing lists are at http://www.freepascal.org/maillist.var
You will find more informations about FPC at http://www.freepascal.org/moreinfo.var
(I'm the author of the buildfaq document above)
There are some limitations. You can't target x86 from powerpc, because powerpc misses an "extended" type. But in generally it works.
I have generated a complete Lazarus for OS X on Windows.
I would virtualize Linux, as even if you can cross-compile, it means you're not testing the binaries on their native platforms. OS X is a trickier problem.
It is not possible to compile from one platform to another. We have a Mac and use FPC quite often. If you need some help with compiling on a mac, drop me a message.
Has anyone gotten VisualWorks running under OpenBSD? It's not an officially supported platform, but one of the Cincom guys was telling me that it should be able to run under a linux compatibility mode. How did you set it up?
I already have Squeak running without a problem, so I'm not looking for an alternative. I specifically need to run VisualWorks's Web Velocity for a project.
Thanks,
if you're wondering about setting up linux compatibility mode and you're running the GENERIC kernel:
# sysctl kern.emul.linux=1
to enable at boot uncomment the kern.emul.linux=1 line in /etc/sysctl.conf
See the OpenBSD FAQ, specifically section 9.4 - Running Linux Binaries on OpenBSD.
Typically there are more steps needed then just kern.emul.linux=1 unless you have statically linked (i.e. completely stand-alone) binaries. The good news is that packages exist that contain Linux libs, and they are easy to install. This is all detailed in the above link.