>> Date: Sat, 15 Feb 2014 09:58:02 -0300
>> From: Fernando de Oliveira <fam...@yahoo.com.br>
>> 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'
>>
>> Em 15-02-2014 08:29, akhiezer escreveu:
>> >> From blfs-support-boun...@linuxfromscratch.org Fri Feb 14 13:19:25
>> 2014
>> >> Date: Fri, 14 Feb 2014 10:13:47 -0300
>> >> From: Fernando de Oliveira <fam...@yahoo.com.br>
>> >> 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 am trying to understand this better, and have found that configure
>> and
>> >> configure.ac have mentions to lsb_release. I am trying to understand
>> if
>> >> it is a required, recommended or optional dependency. However, in one
>> >> machine I do not have it installed and it gives me linux-gnu and
>> builds
>> >> fine, so, I am intending to add as optional.
>> >>
>> >> What do you all think about this? I cannot understand why
>> Christopher's
>> >> is getting n/a.
>> >>
>> >> In the following, I am writing some observations and guesses.
>> >>
>> >> In configure, for 2.4.4, which is a build dir still in place in yet
>> >> another machine, I see:
>> >>
>> >> {{{
>> >> if test -n "$ac_tool_prefix"; then
>> >> # Extract the first word of "${ac_tool_prefix}lsb_release", so it
>> can
>> >> be a program name with args.
>> >> set dummy ${ac_tool_prefix}lsb_release; ac_word=$2
>> >> { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
>> >> $as_echo_n "checking for $ac_word... " >&6; }
>> >> if ${ac_cv_path_LSB_RELEASE+:} false; then :
>> >> $as_echo_n "(cached) " >&6
>> >> else
>> >> case $LSB_RELEASE in
>> >> [\\/]* | ?:[\\/]*)
>> >> ac_cv_path_LSB_RELEASE="$LSB_RELEASE" # Let the user override the
>> test
>> >> with a path.
>> >> ;;
>> >> *)
>> >> as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
>> >> }}}
>> >>
>> >>
>> >> Also, I noticed that he is building at /opt, so probably as root. I
>> have:
>> >>
>> >> {{{
>> >> $ xzgrep -C6 distro_name
>> >> /home/fernando/Downloads/blfs/OpenJDK-1.7.0.51-2.4.5-2014.01.29-18h12m38s.log.xz
>> >> rm -f
>> >> /home/fernando/tmp/paco-build-2014.01.29-18h12m38s/icedtea-2.4.5/generated.build/sun/misc/Version.java
>> >> rm -f
>> >> /home/fernando/tmp/paco-build-2014.01.29-18h12m38s/icedtea-2.4.5/generated.build/sun/misc/Version.java.temp
>> >> /bin/sed -e 's/@@launcher_name@@/java/g' \
>> >> -e 's/@@java_version@@/1.7.0_51-blfs/g' \
>> >> -e 's/@@java_runtime_version@@/1.7.0_51-blfs-b31/g' \
>> >> -e 's/@@jdk_derivative_name@@/IcedTea 2.4.5/g' \
>> >> -e 's/@@distro_name@@/Linux From Scratch/g' \
>> >> -e 's/@@distro_package_version@@/'7u51-2.4.5-blfs'/g' \
>> >> -e 's/@@java_runtime_name@@/OpenJDK Runtime Environment/g' \
>> >> -e 's/@@jdk_revid@@//g' \
>> >> -e 's/@@hotspot_revid@@//g' \
>> >> ../../../src/share/classes/sun/misc/Version.java.template >
>> >> /home/fernando/tmp/paco-build-2014.01.29-18h12m38s/icedtea-2.4.5/generated.build/sun/misc/Version.java.temp
>> >> make[5]: Leaving directory
>> >> `/home/fernando/tmp/paco-build-2014.01.29-18h12m38s/icedtea-2.4.5/openjdk-boot/jdk/make/java/version'
>> >> }}}
>> >>
>> >> 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.
Regards,
Christopher.
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
