This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ANNOUNCEMENT] Updated: cygport-0.9.82-1


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
    <sysroot>/lib     --> <sysroot>/usr/lib
    <sysroot>/include --> <sysroot>/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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]