this is a protoco of all packages that have been emerged this night.
5 packages out of 69 broke and required a second try. Below the
reasons what did break.
>>> Install baselayout-prefix-1.12.5-r6 into /home/prefix/gentoo/var/tmp/portage/sys-apps/baselayout-prefix-1.12.5-r6/image/home/prefix/gentoo/ category sys-apps
>>> Completed installing baselayout-prefix-1.12.5-r6 into /home/prefix/gentoo/var/tmp/portage/sys-apps/baselayout-prefix-1.12.5-r6/image/home/prefix/gentoo/
^GQA Security Notice:
- /bash.exe.stackdump will be a world writable file.
- This may or may not be a security problem, most of the time it is one.
- Please double check that baselayout-prefix-1.12.5-r6 really needs a
world writeable bit and file bugs accordingly.
ecompressdir: bzip2 -9 /home/prefix/gentoo/usr/share/man
^GQA Security Notice:
- /bash.exe.stackdump will be a world writable file.
- This may or may not be a security problem, most of the time it is one.
- Please double check that pax-utils-0.2.1 really needs a world
writeable bit and file bugs accordingly.
* QA Notice: the following files are outside of the prefix:
* /bash.exe.stackdump
32 enolar: RETRY 1: sys-devel/libtool
./libtool: line 1146: 5624 Aborted ( cd
$output_objdir && $LTCC$symtab_cflags
-c$no_builtin_flag$pic_flag_for_symtable "$my_dlsyms" )
./libtool: line 1149: 656 Aborted ( exit 134 )
make[2]: *** [libltdl/libltdl.la] Error 134
make[2]: Leaving directory
`/home/prefix/gentoo/var/tmp/portage/sys-devel/libtool-2.2.10/work/libtool-2.2.10'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/home/prefix/gentoo/var/tmp/portage/sys-devel/libtool-2.2.10/work/libtool-2.2.10'
make: *** [all] Error 2
* ERROR: sys-devel/libtool-2.2.10 failed:
* (no error message)
*
* Call stack:
* ebuild.sh, line 53: Called src_configure
* environment, line 6366: Called die
* The specific snippet of code:
* emake || die
> on interix, a missing or wrong interpreter is not handled correctly, and
> thus leads to crashes without appropriate error messages. i'm really
> glad portage now checks for those
>
If bootstrapping dies with dozends of packages for no other reason
than invalid shebangs, and if nobody fixes them even in the
fundamental packages, doesn't this mean, that nobody tries to bootsrap
at all any more? With the exeption of mine.
Nobody could bootstrap without either fixing all this packages or
commenting out the call to die. What I want to say is, that I see some
danger that the Prefix projekt kills itself by this blocker. People
don't get started at all.
> interix is more like a real unix than cygwin; it uses symlinks, etc.
> also, it does _not_ use PATH to search for libraries, but has propper
> support for rpath, etc.
>
> additionally the x86-winnt profiles, which i started, use the parity
> compiler for windows [1], which adds support for rpath, lazy loading,
> unix like shared library building, libtool support, etc, etc. so even on
> windows, there is not need for PATH hacks, and such.
>
The parity compiler sounds very ambitious and I am curious. On the
other hands I also see the advantages in Microsofts PATH approach.
Dynamic libraries doen't depend on a special path any more and can be
moved around. All you have to do, is to adapt the PATH variable to the
new location. That makes your programs more portable.
Fortunatly you can do the some on Unix by use of LD_LIBRARY_PATH. However:
<quote http://en.wikipedia.org/wiki/Rpath_%28linking%29>
The primary disadvantage of using RPATH is that it overrides the
LD_LIBRARY_PATH settings which makes things like running a precompiled
binary out of a user's home directory or some other non-default
location difficult or impossible. Use of RPATH also makes it
difficult, if not impossible, to upgrade libraries without forcing a
reinstallation of all the software dependent on (even the older
versions of) the libraries.
</quote>
What I am pondering on, is a relative RPATH, relative to the prefix
path. By this the Prefix installation as a whole could still be moved
around without breaking. You could run a precompiled PREFIX
installation out of different user's home directories.
>
> P.S.: i built cygwin support into parity - would be curious if (after i
> fixed the portage prefix-chaining patch, which is a prerequisite)
> x86-winnt profiles would work unmodified on cygwin.
>
If you want to reach that goal you will reach it. Cygwin isn't
difficult. There are a few cases when the .exe magic gets into your
way, but they are usually easy to fix.
Specially you need the Cygwin patch for coreutils to reflect the .exe
magic and that patch conflicts with the interix-warn-mount.patch.
Al
10-01-2010, 10:53 AM
Fabian Groffen
Stating officially with Cygwin
On 01-10-2010 12:46:48 +0200, Al wrote:
> The parity compiler sounds very ambitious and I am curious. On the
> other hands I also see the advantages in Microsofts PATH approach.
> Dynamic libraries doen't depend on a special path any more and can be
> moved around. All you have to do, is to adapt the PATH variable to the
> new location. That makes your programs more portable.
you have a wrong perception of portable to me
> What I am pondering on, is a relative RPATH, relative to the prefix
> path. By this the Prefix installation as a whole could still be moved
> around without breaking. You could run a precompiled PREFIX
> installation out of different user's home directories.
You simply can't, because the libraries have paths hardcoded compiled
in. That is the whole reason why we decided to "fix" the paths where
the libs are and should be found. It's simply not as simple as thinking
that if the lib can be found in any place that you've solved all (if not
any) of the problems that occur here.
As you've found already yourself, on ELF systems, there are a couple of
ways of finding libs in other places. However, this is mostly a
debugging aid, and often screws up more than it solves.
chpathtool exists for a reason, but still it's fragile, and won't work
on cygwin for sure.
--
Fabian Groffen
Gentoo on a different level
10-01-2010, 11:05 AM
Al
Stating officially with Cygwin
2010/10/1 Fabian Groffen <grobian@gentoo.org>:
> On 01-10-2010 12:46:48 +0200, Al wrote:
>> The parity compiler sounds very ambitious and I am curious. On the
>> other hands I also see the advantages in Microsofts PATH approach.
>> Dynamic libraries doen't depend on a special path any more and can be
>> moved around. All you have to do, is to adapt the PATH variable to the
>> new location. That makes your programs more portable.
>
> you have a wrong perception of portable to me
It's not a wrong perception, it's a wider perception. In german it
translates with: tragbar, transportabel, portabel.
Here I use it in the sense of portablility inside one file system.
Maybe you can find a better term.
>
>> What I am pondering on, is a relative RPATH, relative to the prefix
>> path. By this the Prefix installation as a whole could still be moved
>> around without breaking. You could run a precompiled *PREFIX
>> installation out of different user's home directories.
>
> You simply can't, because the libraries have paths hardcoded compiled
> in. *That is the whole reason why we decided to "fix" the paths where
I know, however, I ponder.
The prefix is a first step in that direction, Maybe, one can do the
second step one day, but one can't do it all at once.
> chpathtool exists for a reason, but still it's fragile, and won't work
> on cygwin for sure.
I'll take a look at that this evening.
Al
10-01-2010, 11:17 AM
Fabian Groffen
Stating officially with Cygwin
On 01-10-2010 13:05:22 +0200, Al wrote:
> 2010/10/1 Fabian Groffen <grobian@gentoo.org>:
> > On 01-10-2010 12:46:48 +0200, Al wrote:
> >> The parity compiler sounds very ambitious and I am curious. On the
> >> other hands I also see the advantages in Microsofts PATH approach.
> >> Dynamic libraries doen't depend on a special path any more and can be
> >> moved around. All you have to do, is to adapt the PATH variable to the
> >> new location. That makes your programs more portable.
> >
> > you have a wrong perception of portable to me
>
> It's not a wrong perception, it's a wider perception. In german it
> translates with: tragbar, transportabel, portabel.
>
> Here I use it in the sense of portablility inside one file system.
> Maybe you can find a better term.
porting to me sounds like being able to bring to other systems
you seem to be discussing relocation here
--
Fabian Groffen
Gentoo on a different level
10-01-2010, 11:21 AM
Al
Stating officially with Cygwin
>
> porting to me sounds like being able to bring to other systems
>
> you seem to be discussing relocation here
>
Here I could answer, you have a wrong perception of relocation. I
always read this for relocation inside the memory. We need a third
term.
Al
10-04-2010, 07:09 AM
Michael Haubenwallner
Stating officially with Cygwin
Hi Al,
On 10/01/2010 12:46 PM, Al wrote:
> The parity compiler sounds very ambitious and I am curious. On the
> other hands I also see the advantages in Microsofts PATH approach.
> Dynamic libraries doen't depend on a special path any more and can be
> moved around. All you have to do, is to adapt the PATH variable to the
> new location. That makes your programs more portable.
While the environment-variable-based approach to find dynamic libraries does
have it advantages indeed, it is a no-go for (automated) package managing.
Use LD_LIBRARY_PATH (and its equivalents) for debugging, playing around,
trying something out, but don't have final binary packages rely on it.
We have been using LD_LIBRARY_PATH&Co in our company for some years, but we
have thrown that away and use the built-into-binaries RPATH/RUNPATH/whatever
approach now, because the environment-variables caused too many headaches:
partially unable to fix at all, or with really bad hacks only.
> What I am pondering on, is a relative RPATH, relative to the prefix
> path. By this the Prefix installation as a whole could still be moved
> around without breaking. You could run a precompiled PREFIX
> installation out of different user's home directories.
Some of our target platform do support "$ORIGIN" in RPATH&Co.
The problem is that I cannot think of a good way yet to inform prefix'
toolchain about the just linked binary's target location by package's
build systems, which is necessary to calculate an $ORIGIN-based RPATH.
/haubi/
--
Michael Haubenwallner
Gentoo on a different level
Stating officially with Cygwin
