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: [patch] cygport

Yaakov S (Cygwin Ports) wrote:
Charles Wilson wrote:
| The attached patch (+ two new files) enables cygport to build
| "relocatable" packages using the framework devised by Bruno Haible -- if
| the upstream source supports it.  Currently, only libiconv and gettext
| support this feature (coincidentally, the upstream maintainer of both
| packages is...Bruno Haible).

Forgive me for my ignorance on the topic, but what is gained through
enabling relocatibility?  FWIW, I don't see Gentoo[1][2] using it, for
example.  Do other distros use it?

Many times packages are compiled with hard-coded paths to resources. E.g. if you compile foo with --prefix=/my/local/area, it's likely that data will be installed into /my/local/area/share/foo/*, and that the path "/my/local/area/share/foo" will be hard-coded into and/or foo.exe. (also, -rpath on ELF systems, etc)

But what if you want to make a binary release that can be installed by some user into ~/.local-packages/? (or /mnt/usb-stick/?) What if you *don't know* where the end-user will install the binary package? (Try for a real-life example, or Movable Python

Certainly, gentoo has no use for this; they expect everyone to recompile everything everytime. Since GentooUserBob will compile the package specifying his desired installation prefix, he doesn't care about relocation after the build is complete.

Now, the Bruno said (way back when he first introduced this feature)

"I hope that people will learn when to use --enable-relocatable by
themselves. For example, I don't think a Linux distributor should use
--enable-relocatable for anything installed in /usr - it would only
be bloat that makes the system slower."

And that's true for the official cygwin dist of gettext and libiconv, too -- the official cygwin gettext and libiconv packages are not built with relocation support. However, I always do a test build WITH relocation, to make sure nothing has broken. [*]

Often, something /has/ broken, and this little exercise exposes it -- and sometimes the problem thus exposed also affects the non-relocatable build, but wasn't exposed in the "regular" build. So adding the ability to automate relocatable builds within the cygport framework would certainly help ME quite a bit (and not just on gettext/libiconv. I'm working on adding relocation support to two other packages, also -- not that the official cygwin distributed versions would actually use that support, either).

The original relocation proposal gives a much better justification for relocation in general than I do:


[*] actually, I do a whole sequence of test builds (thanks to the fact that libiconv and gettext are interdependent):

  1. libiconv --disable-nls
  2. gettext (link against #1, NOT installed libiconv)
  3. libiconv --enable-nls (link against #2)
       run test suite
  4. gettext (link against #3)
       run test suite

  5. libiconv --disable-nls
  6. gettext (link against #5, NOT installed libiconv)
  7. libiconv --enable-nls (link against #6)
       run test suite
  8. gettext (link against #7)
       run test suite

The packages generated in #7 and #8 are the ones that get uploaded for cygwin. And you wonder why I don't update libiconv/gettext very often...

Unsubscribe info:
Problem reports:

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