Em 17-02-2014 03:47, m...@pc-networking-services.com escreveu:
>>> 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'
>>>>> }}}
>>>>>
>>>>
>>>>
>>>> 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' ?
>>
>>
>>
>>
>>
>
> 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.
>
I think I know what happened. You forgot or did not properly
http://www.linuxfromscratch.org/lfs/view/7.4/chapter09/theend.html
(before doing the following as root, backup, if you have them, the two
files, just for later comparison, so you will see the problem):
echo 7.4 > /etc/lfs-release
In the following, replace <your name here> by what you want the codename
to be. In may case, it is set by jhalfs to "lfs-jhalfs". In your case,
you can use christopher, lfs-christopher, anything you want.
cat > /etc/lsb-release << "EOF"
DISTRIB_ID="Linux From Scratch"
DISTRIB_RELEASE="7.4"
DISTRIB_CODENAME="<your name here>"
DISTRIB_DESCRIPTION="Linux From Scratch"
EOF
This should solve your problems.
You must do this, other software needs the lsb_release output.
Thus,
lsb_release -ds output comes from DISTRIB_DESCRIPTION
lsb_release -is output comes from DISTRIB_ID
Notice, in the referred page: Linux Standards Base (LSB)
--
[]s,
Fernando
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
