Whatever we decide can someone on infra update these docs? Like check if
the chroot instructions are good and if so delete the non-chroot ones?

https://code.google.com/p/chromium/wiki/LinuxBuild32On64

A couple months ago I got involved in troubleshooting a multi-day Linux 32
debug failure on the main waterfall.  Getting a working 32-bit build was
the hardest part.

James


On Mon, Aug 11, 2014 at 2:13 AM, Jakob Kummerow <[email protected]>
wrote:

> I don't think anyone uses --lib32 locally. It worked well on Lucid, but
> was officially not recommended on Precise, so AFAIK everyone switched to
> using a chroot.
>
> I don't know how our build bots were set up (e.g.
> http://build.chromium.org/p/client.v8/builders/V8-Blink%20Linux%2032),
> but I think they're essentially copies of similar 32-bit Chromium bots, so
> should be re-using whatever mechanism is used for those. machenbach@
> might know more.
>
> As far as I'm concerned, we absolutely need *some* way to build and debug
> 32-bit Chrome, but I don't care much how exactly it's done.
>
>
> On Fri, Aug 8, 2014 at 5:54 PM, Paweł Hajdan, Jr. <[email protected]
> > wrote:
>
>> Adding NaCl and v8 mailing lists. Are you still using
>> build/install-build-deps.sh --lib32? If so, why? How can I test your build
>> on a fresh VM to make sure it works without it?
>>
>> Paweł
>>
>> On Fri, Aug 8, 2014 at 5:31 PM, Nico Weber <[email protected]> wrote:
>>
>>> I think this is no longer needed for Chromium. But as far as I know,
>>> NaCl (and v8?) still use this, instead of a chroot. So I'd reach out to
>>> these teams before making this change.
>>>
>>>
>>> On Fri, Aug 8, 2014 at 7:49 AM, Paweł Hajdan, Jr. <
>>> [email protected]> wrote:
>>>
>>>> I'd like to give it a try to remove --lib32 flag from
>>>> build/install-build-deps.sh . This is not the first try, but now some
>>>> essential 32-bit libraries are installed, and for 32-bit Chrome development
>>>> a chroot is strongly recommended.
>>>>
>>>> Feel free to recommend types of builds you'd like me to test, and I can
>>>> do that on a freshly installed VM.
>>>>
>>>> If any problems are noticed after the change I'll be totally fine with
>>>> a revert. This is easy with version control. Non-trivial merge conflicts
>>>> are unlikely, since this is just a big block of code at the end of the
>>>> script.
>>>>
>>>> The rationale is that the code is super-crazy and as far as I know
>>>> should no longer be needed. Some examples:
>>>>
>>>>       # Create a posix extended regular expression fragment that will
>>>>       # recognize the includes which have changed. Should be rare,
>>>>       # will almost always be empty.
>>>>       includes=`sed -n -e "s/^[0-9a-z]*  //g" \
>>>>                        -e "\,usr/include/,p" dpkg/DEBIAN/md5sums |
>>>>                   xargs -n 1 -I FILE /bin/sh -c \
>>>>                     "cmp -s dpkg/FILE /FILE || echo FILE" |
>>>>                   tr "\n" "|" |
>>>>                   sed -e "s,|$,,"`
>>>>
>>>>       # Rename lib to lib32, but keep debug symbols in
>>>> /usr/lib/debug/usr/lib32
>>>>       # That is where gdb looks for them.
>>>>       find dpkg -type d -o -path "*/lib/*" -print |
>>>>         xargs -r -n 1 sh -c "
>>>>           i=\$(echo \"\${0}\" |
>>>>                sed -e s,/lib/,/lib32/,g \
>>>>                -e
>>>> s,/usr/lib32/debug\\\\\(.*/lib32\\\\\),/usr/lib/debug\\\\1,);
>>>>           mkdir -p \"\${i%/*}\";
>>>>           mv \"\${0}\" \"\${i}\""
>>>>
>>>>     dpkg --build staging/dpkg .' 2>&1)"
>>>>     compat="$(eval echo $(echo "${compat}" |
>>>>                           sed -e 's,_[^_/]*_amd64.deb,_*_amd64.deb,'))"
>>>>     [ -r "${compat}" ] || {
>>>>       echo "${msg}" >&2
>>>>       echo "Failed to build new Debian archive!" >&2
>>>>       exit 1
>>>>     }
>>>>
>>>>     msg="$(sudo dpkg -i "${compat}" 2>&1)" && {
>>>>         echo "Installed ${compat##*/}"
>>>>       } || {
>>>>         # echo "${msg}" >&2
>>>>         echo "Skipped ${compat##*/}"
>>>>       }
>>>>   done
>>>>
>>>>   # Add symbolic links for developing 32bit code
>>>>   echo "Adding missing symbolic links, enabling 32bit code
>>>> development..."
>>>>   for i in $(find /lib32 /usr/lib32 -maxdepth 1 -name \*.so.\* |
>>>>              sed -e 's/[.]so[.][0-9].*/.so/' |
>>>>              sort -u); do
>>>>     [ "x${i##*/}" = "xld-linux.so" ] && continue
>>>>     [ -r "$i" ] && continue
>>>>     j="$(ls "$i."* | sed -e 's/.*[.]so[.]\([^.]*\)$/\1/;t;d' |
>>>>          sort -n | tail -n 1)"
>>>>     [ -r "$i.$j" ] || continue
>>>>     sudo ln -s "${i##*/}.$j" "$i"
>>>>   done
>>>>
>>>> Paweł
>>>>
>>>> --
>>>> --
>>>> Chromium Developers mailing list: [email protected]
>>>> View archives, change email options, or unsubscribe:
>>>> http://groups.google.com/a/chromium.org/group/chromium-dev
>>>>
>>>
>>>
>>  --
>> --
>> v8-dev mailing list
>> [email protected]
>> http://groups.google.com/group/v8-dev
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "v8-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> --
> Chromium Developers mailing list: [email protected]
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
>

-- 
-- 
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
--- 
You received this message because you are subscribed to the Google Groups 
"v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to