Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: Date: Fri, 1 Jul 2005 10:21:07 -0400 From: Tony Karakashian Reply-To: Tony Karakashian To: cygwin AT cygwin DOT com Subject: Re: Cygwin from Scratch? In-Reply-To: <42C464B0.C8D5A7AE@dessent.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <42C464B0 DOT C8D5A7AE AT dessent DOT net> X-IsSubscribed: yes Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id j61ELFPd023223 > Maybe a better question would be, "Why do you feel it would not be > possible?" Every Cygwin binary package is compiled from source by the > maintainer (obviously) and includes a -src package that should build > cleanly, else there's a packaging problem. So in that sense you can > build everything yourself, no question. I guess I misspoke. I'm sure it's possible, otherwise it wouldn't be here to begin with. :) What I meant was has anyone tried it, and/or documented it? > But I think the larger implication in your message is that you would > want to configure things differently, to perhaps use different > prefixes/paths or settings. That too should be possible given the build > scripts provided in the -src packages. But you will undoubtedly have to > do some minor tweaking, and know what you're doing. Well, there's that, but also to gain some knowledge and perhaps correct any issues. While combing through the list archives, I noticed that most of the time a package is submitted, it pretty much is tested by the maintainer and that's it. That's usually because it builds just fine for most people, but there may be some underlying issue that may not be noticed or linked to that one package. I can't think of any particular packages off hand, but the LFS team regularly passes patches back to the original authors of software when they find things like that. Most of the time, it's because the package doesn't follow standards (like the LSB or LHS) very well. Another nice feature of using an *FS system is you get exactly what you want, and nothing more, which comes in handy at times. The current Cygwin distribution is over 2G installed on my machine (I installed everything, since I don't know how things are setup). I know I don't need anywhere near that amount. Disk space being cheap, though, I'm not THAT concerned about that aspect. > However, it will never be like LFS, where you just download the upstream > tarballs and "./configure && make && make install" ad nauseam. Some > *nix software will build under Cygwin out of the box without patching, > but I would say it is the exception to the rule. Most of the changes > necessary are usually minor, but they still exist, and that is why using > the -src packages is your best bet. I know that part of the LFS > philosophy is to use unpatched upstream sources as much as possible, but > I don't think this is realistic with Cygwin just yet. Then you ain't built an LFS yet. :) Once you've got the base system installed, and perhaps some things from the BLFS (Beyond LFS), you might be able to do that dance, but it can take a long time to get there. Even on a pure and complete LFS build, though, "./configure && make && make install" is the exception rather than the rule. > In my experience the two most common changes you have to make when > porting are: a) adding -no-undefined to LDFLAGS (or -Wl,-no-undefined to > CFLAGS), and b) adding missing $(EXEEXT) to Makefiles that reference the > names of binaries. I believe that a) is just due to how the win32 > dynamic loader works (all symbols must be accounted for at link-time) in > contrast to how ld.so works under Linux. Fortunately, most of the hard work has been done for existing packages. A CFS "book" would simply require compiling instructions in one place as well as patches, etc. Could be a fun project. -T -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/