> Date: Mon, 17 Feb 2014 19:47:48 +1300
> From: m...@pc-networking-services.com
> To: "BLFS Support List" <blfs-support@linuxfromscratch.org>
> Subject: Re: [blfs-support] Iced Tea 2.4.1 and iced tea 2.4.5 sed unknown
> option to `s'
>
.
.
> >> >>
> >> >> I remember having sometime ago problems with PATH, for some packages,
> >> if
> >> >> I build as root, and for those, I have a line in the script:
> >> >>
> >> >> source /etc/profile
> >> >>
> >> >> and the PATH is well defined, because he needs:
> >> >>
> >> >> export CLASSPATH=.:/usr/share/java &&
> >> >> export PATH="$PATH:/opt/OpenJDK-1.7.0.51-bin/bin"
> >> >>
> >> >> or similar, if the binary is another one, i.e., the binary has to be
> >> in
> >> >> the path, and, in my case, it is provided by:
> >> >>
> >> >> /etc/profile.d/openjdk.sh
> >> >>
> >> >> which is defined in OJDK/Icedtea BLFS page.
> >> >>
> >> >
> >> >
> >> > Yes, tracing through the code indicates that the problem may be
> >> > stemming from 'lsb_release -is' outputting 'n/a' (others on web have
> >> > reported various breakages - not just re icedtea - that seem to stem
> >> > from lsb_release using 'n/a' as a return value - and the code that
> >> uses
> >> > said output not sanitising its own input).
> >> >
> >> >
> >> > The following is working from blfs-svn
> >> ('OpenJDK-1.7.0.51/IcedTea-2.4.5'
> >> > ,
> >> 'http://www.linuxfromscratch.org/blfs/view/svn/general/openjdk.html'),
> >> > but should be similar for blfs-7.4 (I've broken/re-wrapped some of the
> >> > longer outputted lines):
> >> > ----
> >> > (0) # Unpack src tarballs into . for the purposes of following greps.
> >> NB
> >> > that this is not making any suggestion on how you should unpack
> >> > stuff for the build: follow the book for that, of course.
> >> >
> >> > (1) grep -r '@@distro_name@@' .
> >> > ./jdk-9db88c18e114/make/java/version/Makefile:
> >> > -e 's/@@distro_name@@/$(DISTRO_NAME)/g' \
> >> >
> >> > (2) grep -r 'DISTRO_NAME' .
> >> > ./icedtea-2.4.5/Makefile.am:
> >> > echo "DISTRO_NAME=$(DIST_NAME)"
> >> >>openjdk/jdk/make/common/shared/Defs.gmk ;
> >> > ./icedtea-2.4.5/Makefile.in:
> >> > echo "DISTRO_NAME=$(DIST_NAME)"
> >> >>openjdk/jdk/make/common/shared/Defs.gmk ;
> >> > ./jdk-9db88c18e114/make/java/version/Makefile:
> >> > -e 's/@@distro_name@@/$(DISTRO_NAME)/g' \
> >> >
> >> > (3) grep -r 'DIST_NAME' .
> >> > ./icedtea-2.4.5/Makefile.am:
> >> > echo "DISTRO_NAME=$(DIST_NAME)"
> >> >>openjdk/jdk/make/common/shared/Defs.gmk ;
> >> > ./icedtea-2.4.5/ChangeLog: DIST_NAME to build.
> >> > ./icedtea-2.4.5/configure:DIST_NAME
> >> > ./icedtea-2.4.5/configure: DIST_NAME="$($LSB_RELEASE -is | sed
> >> 's/^"//;s/"$//')"
> >> > ./icedtea-2.4.5/configure: DIST_NAME="$build_os"
> >> > ./icedtea-2.4.5/acinclude.m4: DIST_NAME="$($LSB_RELEASE -is | sed
> >> 's/^"//;s/"$//')"
> >> > ./icedtea-2.4.5/acinclude.m4: DIST_NAME="$build_os"
> >> > ./icedtea-2.4.5/acinclude.m4:AC_SUBST(DIST_NAME)
> >> > ./icedtea-2.4.5/Makefile.in:DIST_NAME = @DIST_NAME@
> >> > ./icedtea-2.4.5/Makefile.in:
> >> > echo "DISTRO_NAME=$(DIST_NAME)"
> >> >>openjdk/jdk/make/common/shared/Defs.gmk ;
> >> >
> >> > (4) grep -lrE 'LSB_RELEASE|build_os' .
> >> > ./icedtea-2.4.5/ChangeLog
> >> > ./icedtea-2.4.5/configure
> >> > ./icedtea-2.4.5/acinclude.m4
> >> > ./icedtea-2.4.5/Makefile.in
> >> > ./icedtea-2.4.5/configure.ac
> >> >
> >> > (5) From the files in '(4)', you can see that build_os is only set
> >> > if there's no LSB_RELEASE / lsb_release *detected* (which doesn't
> >> > necessarily mean that you've not got it present).
> >> >
> >> > I'd suggest tracing the execution of './configure ...' to verify
> >> that
> >> > the variables it's using, and the code paths that it thus follows,
> >> > are what you're expecting them to be. A crude but simple &
> >> effective
> >> > way to do that, is to stick in 'echo ....' lines at judicious
> >> places,
> >> > mainly in './icedtea-2.4.5/configure' - and with, per earlier post
> >> > today, appropriate marker text strings so that you can readily
> >> > grep/locate them from the logged output &/or stdout/stderr.
> >> > ----
> >> >
> >> >
> >> >
> >> > hth,
> >> > akh
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> >
> >>
> >> Many thanks again, akh. Read quickly your mail (obliged to do other
> >> things, as I wrote earlier), and seems very good analysis indeed.
> >>
> >>
> >> But still spent some time with this, reading the config.log (it is fast
> >> to do it to this point).
> >>
> >> In one machine, I have:
> >>
> >> {{{
> >> DIST_ID='Custom build (Sat Feb 15 08:33:10 BRT 2014)'
> >> DIST_NAME='linux-gnu'
> >> }}}
> >>
> >> In another:
> >>
> >> {{{
> >> DIST_ID='Linux From Scratch, package '\''7u51-2.4.4-blfs'\'''
> >> DIST_NAME='Linux From Scratch'
> >> }}}
> >>
> >> First one does not have lsb_release, second one does:
> >>
> >> $ env LC_ALL=C which lsb_release
> >> which: no lsb_release in
> >> (/usr/local/bin:/bin:/sbin:/usr/sbin:/opt/gnome/bin:/opt/ant/bin:/opt/openjdk/bin:/opt/qt/bin:/usr/bin:/usr/X11R6/bin)
> >>
> >> $ grep -ri linux-gnu /etc/ 2>/dev/null
> >> /etc/gtk-2.0/gtk.immodules:# ModulesPath =
> >> /root/.gtk-2.0/2.10.0/i686-pc-linux-gnu/immodules:/root/.gtk-2.0/2.10.0/immodules:/root/.gtk-2.0/i686-pc-linux-gnu/immodules:/root/.gtk-2.0/immodules:/usr/lib/gtk-2.0/2.10.0/i686-pc-linux-gnu/immodules:/usr/lib/gtk-2.0/2.10.0/immodules:/usr/lib/gtk-2.0/i686-pc-linux-gnu/immodules:/usr/lib/gtk-2.0/immodules
> >>
> >> I cannot believe that it is taking
> >>
> >> Second machine:
> >>
> >> $ which lsb_release
> >> /usr/bin/lsb_release
> >>
> >> $ lsb_release -ds
> >> "Linux From Scratch"
> >>
> >>
> >> Configure search for DIST_NAME in:
> >>
> >> { $as_echo "$as_me:${as_lineno-$LINENO}: checking build identification"
> >> >&5
> >> $as_echo_n "checking build identification... " >&6; }
> >> if test -n "$LSB_RELEASE"; then
> >> lsb_info="$($LSB_RELEASE -ds | sed 's/^"//;s/"$//')"
> >> if test "x$PKGVERSION" = "xnone"; then
> >> DIST_ID="Built on $lsb_info ($(date))"
> >> else
> >> DIST_ID="$lsb_info, package $PKGVERSION"
> >> fi
> >> DIST_NAME="$($LSB_RELEASE -is | sed 's/^"//;s/"$//')"
> >> else
> >> DIST_ID="Custom build ($(date))"
> >> DIST_NAME="$build_os"
> >> fi
> >>
> >> Thus, it should be able to find using the variable build_os, which seems
> >> to be defined in configure at:
> >>
> >> # Remember, the first character of IFS is used to create $*,
> >> # except with old shells:
> >> build_os=$*
> >>
> >> Value is defined everywhere, including Makefile, only after configure is
> >> run:
> >>
> >> Makefile:build_os = linux-gnu
> >> config.status:S["build_os"]="linux-gnu"
> >> config.log:build_os='linux-gnu'
> >>
> >> I still do not understand how it gets this value.
> >>
> >> I have to stop, now.
> >>
> >
> >
> > (Yes, likewise here doing this in parallel.)
> >
> >
> > I think that it looks like Christopher (OP) config _is_ finding and
> > executing 'lsb_release -is' (& likely also 'lsb_release -ds'), and
> > it's the 'lsb_release -is' that's returning the 'n/a' - iirc
> > usually from/via '/etc/lsb_release' or similar.
> >
> >
> > Christopher, can you confirm if your build environment does have
> > 'lsb_release -is', and if so what does it output? And similarly for
> > 'lsb_release -ds' ?
> >
> >
> > For ref:
> > ----
> > $ grep -r 'n/a' ./lsb-release-1.4/
> > ./lsb-release-1.4/lsb_release:MSG_NA="n/a"
> > ./lsb-release-1.4/lsb_release: echo -e "$MSG_LSBVER$LSB_VERSION"
> > # at least "n/a"
> > ./lsb-release-1.4/lsb_release.examples:LSB Version: n/a
> > $
> > $ grep -r MSG_NA ./lsb-release-1.4/
> > ./lsb-release-1.4/lsb_release:MSG_NA="n/a"
> > ./lsb-release-1.4/lsb_release: [ -z "$LSB_VERSION" ] &&
> > LSB_VERSION=$MSG_NA
> > ./lsb-release-1.4/lsb_release: [ -z "$DISTRIB_ID" ] &&
> > DISTRIB_ID=$MSG_NA
> > ./lsb-release-1.4/lsb_release: [ -z "$DISTRIB_RELEASE" ] &&
> > DISTRIB_RELEASE=$MSG_NA
> > ./lsb-release-1.4/lsb_release: [ -z "$DISTRIB_CODENAME" ] &&
> > DISTRIB_CODENAME=$MSG_NA
> > ./lsb-release-1.4/lsb_release: [ -z "$DISTRIB_ID" ] &&
> > DISTRIB_ID=$MSG_NA
> > ./lsb-release-1.4/lsb_release: [ -z "$DISTRIB_RELEASE" ] &&
> > DISTRIB_RELEASE=$MSG_NA
> > ./lsb-release-1.4/lsb_release: [ -z "$DISTRIB_CODENAME" ] &&
> > DISTRIB_CODENAME=$MSG_NA
> > ./lsb-release-1.4/lsb_release: DISTRIB_ID=$MSG_NA
> > ./lsb-release-1.4/lsb_release: && DISTRIB_RELEASE=$MSG_NA
> > ./lsb-release-1.4/lsb_release: && DISTRIB_CODENAME=$MSG_NA
> > $
> > ----
> >
> >
> >
> > rgds,
> > akh
> >
> >
> >
> >
> >
> > --
> > --
> > http://linuxfromscratch.org/mailman/listinfo/blfs-support
> > FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> > Unsubscribe: See the above information page
> >
>
>
> Hello,
>
> Thanks for all the effort. As requested the output is:
> lsb_release -ds "7.4" (the " are displayed in the output)
> lsb_release -is n/a
>
> Not exactly sure what you wish me to try.
>
> I have no problem with attempting to install a later version if needs be.
>
> Please let me know what to try. I did install the version listed as
> stable in the 7.4 book. It was that one which I replaced the / with a %
> sign. Was the only way to get it to build, and hence why I am not sure if
> it was a successful build or not.
>
It's that 'n/a' (without the quotes) output from 'lsb_release -is' that's
very likely causing the breakage - and more specifically it's the '/' in
that value: when it gets substituted into the sed() code, sed interprets
the '/' (from the 'n/a') not as part of an ordinary string, but instead
as one of the delimiters of the sed expression, and gets confused,
and gives an error like you saw, and showed in your original post.
An immediate fix, like you saw subsequently, is to change the relevant
part of the sed to not use '/' as a delimiter, but instead use e.g. '|'
or in general some character that won't appear in any of the (roughly
speaking) string values that get used in that part of the sed().
E.g. if you make the following (~hacky) change (re blfs-svn versions of
the packages), where you replace the set of three '/' delimiters with
respectively '|' (without the quotes, in each case):
---
file: ./jdk-9db88c18e114/make/java/version/Makefile
old-line: -e 's/@@distro_name@@/$(DISTRO_NAME)/g' \
new-line: -e 's|@@distro_name@@|$(DISTRO_NAME)|g' \
---
, then does the build &c work all-OK for you? If not, then does it go
OK with the likes of '%' or ':' or ';' instead of the '|' - e.g. thus:
===
new-line: -e 's;@@distro_name@@;$(DISTRO_NAME);g' \
===
NB of course you ~need to replace the char at each of the three
places. (It shouldn't really make a difference for that immediate sed,
I'd expect).
The wider fix is for upstream or similar to, if not already, sanitise
the input that they're taking from the likes of 'lsb_release -is' .
Looks like 'OpenJDK-1.7.0.51/IcedTea-2.4.5' is the latest release from
upstream; and is in blfs-svn; and looks like it still has the issue. In
that case, for blfs the most appropriate thing might be to have a patch
to do either or both of the following (ref the above two sequences of
greps):
----
* strip-out, or backslash-escape, or otherwise adjust (e.g. replace with
underscore), any '/' chars where 'DIST_NAME' &/or 'build_os' is set;
and perhaps similarly for any other 'maybe-problematic' chars.
However, some other programs might actually look/test for a value like
'n/a' - e.g. if the use of 'n/a' had gotten part-established in common
usage wrt LSB.
So it might not be a good idea, overall, to make this adjustment.
* use a different delimiter for sed where the likes of DISTRO_NAME
is substituted.
This would allow 'n/a' to be passed-through OK the original point of
failure: but it might still cause problems further on.
----
Out of interest, do you have a file called /etc/lsb_release or similar:
if so can you post it here just as an extra cross-check that the 'n/a'
_is_ coming from the lsb... stuff? Thanks.
rgds,
akhiezer
--
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
