The Linux Builder (dbg-shlib) compiles Chrome using shared libraries instead of static libraries. Many Linux developers use this setup, since linking is much faster and allows for quicker code/compile/debug cycles. This bot ensures that you don't accidentally break compilation for them.
You can think of static libraries as a ZIP archive containing all compiled object files. When linking using static libraries, the linker picks exactly those symbols from the object files it needs to satisfy all dependencies. Shared libraries on the other hand are more like executables containing all symbols from the object files. With this, it's easy to understand why linking shared libraries fails while linking static libraries still works (note that it might also happen that you can link with shared libraries, but not with static libraries. In that case, you'll first get an error when you try to run the resulting executable):
Add the missing symbols, e.g. remove the class or add an empty method body.
If your CL changes a file in base/ to include a header from chrome/browser, and the header includes a virtual class definition which is, however, not used in your CL, static linking works again, while dynamic linking will fail to create the vtable for that class. The methods for that class are defined somewhere in chrome/browser. But since base does not depend on browser, those methods are not available when linking base, and the dynamic linker will fail.
Either make base depend on browser (no, you don't want that), or don't include headers from chrome/browser in base/.
Assuming you have already have all sources checked out, run:
rm -rf out