Is the --lib32 flag for build/install-build-deps.sh used?

[Paweł Hajdan, Jr.]

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ł

[Nico Weber]

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.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Paweł Hajdan, Jr.]

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ł

[Jakob Kummerow]

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.

--
--
v8-dev mailing list
v8-...@googlegroups.com
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 v8-dev+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[James Cook]

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

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Mark Seaborn]

On 8 August 2014 08:54, Paweł Hajdan, Jr. <phajd...@chromium.org> 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?

I think "--lib32" is not used for NaCl.  I believe NaCl's buildbot slaves just use the same Ubuntu Linux VM images as Chromium's buildbot slaves.

I am not 100% sure of that, because I don't have very good visibility into how Chrome Infrastructure sets up NaCl's buildbot slaves.  So you might want to check with someone else from Chrome Infrastructure.  However, the last time we needed to add a Debian package as a NaCl build dependency, we had to do that by adding the package to the list in Chromium's build/install-build-deps.sh, rather than by adding it to a NaCl-specific list.

 

On Fri, Aug 8, 2014 at 5:31 PM, Nico Weber <tha...@chromium.org> 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. <phajd...@chromium.org> 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.

BTW, my understanding of this is that using an x86-32 chroot was only recommended because Ubuntu's 32-bit multilib packages got broken in Ubuntu Precise (after having worked OK in Ubuntu Lucid).  Specifically, in Precise it was no longer possible to install 32-bit *-dev packages for Gtk alongside their 64-bit equivalents (whereas this worked in Lucid).  So chroots became recommended as a lighter-weight alternative to having a full VM.

The situation with 32-bit multilib packages might have improved in Ubuntu Trusty so that they work again, but I haven't checked.  Or maybe Chromium no longer depends on packages that we used to need multilib versions of (such as Gtk).

Cheers,

Mark