Re: [E-devel] e_start_main.c: debatable things inside _prefix_try_proc()

[Carsten H. (T. R. <ra...@ra...>]

On Sat, 27 Aug 2011 17:27:12 +0200 Fabio Erculiani <lx...@sa...> said:

> On Sat, Aug 27, 2011 at 4:03 PM, Carsten Haitzler <ra...@ra...>
> wrote:
> > On Sat, 27 Aug 2011 11:06:59 +0200 Fabio Erculiani <lx...@sa...> said:
> >
> > no. we will not change. we determine it at runtime to allow for relocation.
> > if you must use weird fs setups you can set env vars to tell e where its
> > prefix is - but e will determine it at runtime for relocation. so will
> > evas, edje, elementary etc. - they ALL runtime detect location. i suggest
> > you fix your distros boot process so it doesnt have broken proc data (or
> > supply patches to the kernel developers).
> 
> Any distro out there does chroot setup followed by chroot(). I am

none i have ever used uses a chroot as part of any kind of standard boot. but i
don't use live cd's - i install.

> almost sure many other distros are going to have the same problem, but
> of course, not many are supporting E17 as well. How many distros out
> there are using squashfs+(unionfs or aufs)? That's the same number of
> distros going to fail.

none that i have used. the kernel reports information that is incorrect.

> And any other DE and the rest of the userspace applications are fine
> with it (roughly >10000 applications).

and this is the point at which i say "i don't care". those applications all are
also totally unrelocatable. they must be specifically compiled to work in 1
place and can never be moved without a recompile. that is incredibly primitive.

> Your prefix detection is just very bad and error prone, both the proc
> usage (bad) itself and the self/maps parsing (error prone and subject
> to future failure -- anything relying on parsing output like that is
> going to fail sooner or later).

oh my bad. e_start doesn't use the eina_prefix stuff - but dladdr will give you
the same result anyway. the standardised prefix code uses dladdr (). what
dladdr () uses is a matter for glibc. it falls back to proc if dladdr doesn't
exist. enlightenment_start just wasn't moved to use eina_prefix yet. it got
skipped somewhere along the way. but we're not removing the prefix detection
code. i'll fix that. but you'll have to live with verbose complaints from
everything saying it is falling back to compiled in prefixes.

> We will try to workaround the broken code inside e as long as we can
> (in fact commenting out the same broken code makes enlightenment_start
> not failing on exec() due to bad _prefix_path and all seems to work
> fine). Could you guys at least provide a way to override it (trough
> env)?

that's what i was saying - we do have a way. enlightenment_start was just
missed in moving over to use the central prefix setup.

> If we will get to the point it won't be possible to maintain our
> support towards E17, we won't have any other choice other than
> dropping the same.

you still have created a situation where the information provided by the kernel
is in fact incorrect. this will break many other tools that trawl through proc
for process information, debugging etc. so you still have your core problem.

> >> Hi there,
> >> Just running off latest SVN trunk.
> >> In both Gentoo-based and Sabayon-based E17 LiveCDs, the same fails to
> >> start because /proc/self/maps doesn't contain reliable paths*.
> >
> > actually e uses dladdr() if it exists in your libc/libdl (which it does on
> > linux). it has a fallback for /proc/self/maps and a few other things (argv
> > [0] for binaries) and finally as a last resort, the compiled in path.
> 
> dladdr() has nothing to do with the problem of detecting /usr .

i seriously suggest you read the manual page on it. dladdr can tell you which
file a symbol (function etc.) came from. you ask - and it will tell you.

> >
> >> Please don't use /proc/self/maps to just determine what is the
> >> configured prefix but rather set it at build time (like the rest of us
> >> human beings do ;-) ).
> >
> > those other human beings are living in a world that is 20+ years old where
> > location MUST be determined at compile time and then moving an app to
> > anywhere else would break it. it's primitive, limited and obsolete.
> 
> ...
> 
> >
> >
> >
> > --
> > ------------- Codito, ergo sum - "I code, therefore I am" --------------
> > The Rasterman (Carsten Haitzler)    ra...@ra...
> >
> >
> 
> 
> 
> -- 
> Fabio Erculiani
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ra...@ra...