X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=0.2 required=5.0 tests=BAYES_50,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_LOW,TW_YG X-Spam-Check-By: sourceware.org Message-ID: <4BD4A3F6.2060701@cwilson.fastmail.fm> Date: Sun, 25 Apr 2010 16:20:06 -0400 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Cygwin Mailing List Subject: Re: [ANNOUNCEMENT] Updated: cygport-0.9.82-1 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: 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 On 4/25/2010 1:56 PM, Yaakov (Cygwin/X) wrote: > The following package has been updated for the Cygwin distribution: > > *** cygport-0.9.82-1 Yaakov, what sorts of things would be necessary to enable cygport to build cygwin packages from a cross environment? (And would such support ever be something you'd be interested in?) Off hand, I can think of four major areas of concern: 1) Because autoreconf is a normal step in our process, AND because our libtool (at the very least) differs from "standard" (not to mention whatever other mods cygwin-ported packages make to the .m4 files they install into /usr/share/aclocal/) -- a "cross" cygport would need to run the *cygwin* versions of the autotools. But, you can't simply put your cygwin sysroot's 'bin' dir into PATH, because then you'd be trying to run a bunch of other cygwin *binaries* on your $build machine. So...a cygport on $build!=cygwin would need to set AUTOCONF=/path/to, AUTOMAKE=/path/to, etc (I *think* setting these vars would be sufficient; then there is the whole issue of the auto* wrappers being sure to launch the specific version installed into their same directory, rather than simply launching the versioned app via PATH search). Obviously, the default cygconf step would need to detect the cross environment, and insert --build=... --host=i686-pc-cygwin as appropriate. Maybe this could be controlled by ~/.cygconf or /etc/cygconf so that the "correct" triple matching the name of your installed cross compiler could be customized... 2) Various -config, .pc scripts, and .la files in the sysroot would need to be manually adjusted. Perhaps a companion "fixup" helper script. (I assume #4, below). 3) You'd still want to configure with --prefix=/usr and similar (since we're talking about making "real" cygwin packages here), but cygport would need to always set -L/sysroot/lib and -I/sysroot/include (assuming the xxx-$host, cygwin-$target cross compiler isn't itself installed into /sysroot/) 4) Restrictions on supported cross environments: a "sysroot" whose contents are derived from unpacked copies of OFFICIAL (or Cygwin Ports) tarballs? How could such an installation be managed (Hey, cgf, you do this a lot. How do YOU manage your cygwin sysroot?) Also, given that "real" cygwin maps /usr/lib <-> /lib, and /usr/include <-> /include, such an installation would also need to have /lib --> /usr/lib /include --> /usr/include via symlinks I suppose. "Installed" packages in this sysroot might need their postinstall scripts run...but they CAN'T be run in their "normal" form, since AFAIK *none* of them are written with "sysroot" support of any kind. Heck, there are probably a few that assume "cygport.exe" is present (expectations of cygwin-specific tool "runnability" probably affects #2 above, as well). Or is this just too "out there" to even consider? -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple