Reland r49135: Linux: enable compiling GNOME Keyring and KWallet integration.

Reland r49135: Linux: enable compiling GNOME Keyring and KWallet integration. It's still unused.
BUG=12351, 25404
TEST=GNOME Keyring and KWallet get compiled, but add no new library dependencies


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=49370

[Mike Mammarella, 2010-06-08 20:40:01]

This was causing the Chromium Arm (dbg) builder to fail:

In file included from chrome/browser/password_manager/password_store_gnome.cc:5:
./chrome/browser/password_manager/password_store_gnome.h:9: fatal
error: gnome-keyring.h: No such file or directory
compilation terminated.
make: ***
[out/Debug/obj.target/browser/chrome/browser/password_manager/password_store_gnome.o]
Error 1

Any idea why? It's got the package installed. Is that bot not OS=="linux"
perhaps?

[Evan Martin, 2010-06-08 20:55:46]

+piman, master of ARM

[piman, 2010-06-09 00:36:53]

I think I'm lacking context to understand why this is arm-related... It looks
like the default is to dlopen the library, so that should be ok (assuming it
degrades gracefully if the library isn't present).

[Mike Mammarella, 2010-06-09 00:43:35]

On 2010/06/09 00:36:53, piman wrote:
> I think I'm lacking context to understand why this is arm-related... It looks
> like the default is to dlopen the library, so that should be ok (assuming it
> degrades gracefully if the library isn't present).

The "Chromium Arm (dbg)" builder was getting a compile error - it couldn't find
gnome-keyring.h, although maurel says libgnome-keyring-dev is definitely
installed on that bot.

I'm wondering if perhaps pkg-config --cflags gnome-keyring-1 wasn't happening or
something, causing the include path for it to be missing.

[piman, 2010-06-09 01:01:29]

On Tue, Jun 8, 2010 at 5:43 PM, <mdm@chromium.org> wrote:

> On 2010/06/09 00:36:53, piman wrote:
>
>> I think I'm lacking context to understand why this is arm-related... It
>> looks
>> like the default is to dlopen the library, so that should be ok (assuming
>> it
>> degrades gracefully if the library isn't present).
>>
>
> The "Chromium Arm (dbg)" builder was getting a compile error - it couldn't
> find
> gnome-keyring.h, although maurel says libgnome-keyring-dev is definitely
> installed on that bot.
>
> I'm wondering if perhaps pkg-config --cflags gnome-keyring-1 wasn't
> happening or
> something, causing the include path for it to be missing.


I see. On ARM everything is cross-compiled, so the host packages installed
on the bot don't matter. They need to be added to the sysroot.
However in this case we don't have gnome or its dependencies on Chrome OS so
we definitely don't want to link against its libs.

Antoine

>
>
> http://codereview.chromium.org/2774002/show
>

[Mike Mammarella, 2010-06-09 01:06:47]

On 2010/06/09 01:01:29, piman wrote:
> On Tue, Jun 8, 2010 at 5:43 PM, <mailto:mdm@chromium.org> wrote:
> 
> > On 2010/06/09 00:36:53, piman wrote:
> >
> >> I think I'm lacking context to understand why this is arm-related... It
> >> looks
> >> like the default is to dlopen the library, so that should be ok (assuming
> >> it
> >> degrades gracefully if the library isn't present).
> >>
> >
> > The "Chromium Arm (dbg)" builder was getting a compile error - it couldn't
> > find
> > gnome-keyring.h, although maurel says libgnome-keyring-dev is definitely
> > installed on that bot.
> >
> > I'm wondering if perhaps pkg-config --cflags gnome-keyring-1 wasn't
> > happening or
> > something, causing the include path for it to be missing.
> 
> 
> I see. On ARM everything is cross-compiled, so the host packages installed
> on the bot don't matter. They need to be added to the sysroot.
> However in this case we don't have gnome or its dependencies on Chrome OS so
> we definitely don't want to link against its libs.
> 
> Antoine
> 
> >
> >
> > http://codereview.chromium.org/2774002/show
> >
> 

That's among the reasons this code is set up to dlopen() the library rather than
link against it, but the header file still needs to be there to compile. Should
I change it to just not even compile these files on ChromeOS? In that case, what
condition should I check for to exclude these files?

[Hironori Bono, 2010-06-09 01:15:25]

Greetings,

This is just for your information.
To compile a test file with a "-v" option in the arm builder, it seems
<gnome-keyring.h> is not installed for arm crosstool as listed in the following
ouptut. (It seems gnome-keyring-dev registers its header files only to x86 gcc
since this builder is a x86 PC?)

$ /usr/local/crosstool-trusted/arm-2009q3/bin/arm-none-linux-gnueabi-gcc -c -v
test.c
Using built-in specs.
Target: arm-none-linux-gnueabi
Configured with: /scratch/julian/2009q3-respin-linux-lite/src/gcc-4.4/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--target=arm-none-linux-gnueabi --enable-threads --disable-libmudflap
--disable-libssp --disable-libstdcxx-pch --enable-extra-sgxxlite-multilibs
--with-arch=armv5te --with-gnu-as --with-gnu-ld
--with-specs='%{funwind-tables|fno-unwind-tables|mabi=*|ffreestanding|nostdlib:;:-funwind-tables}
%{O2:%{!fno-remove-local-statics: -fremove-local-statics}}
%{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics: -fremove-local-statics}}}'
--enable-languages=c,c++ --enable-shared --disable-lto --enable-symvers=gnu
--enable-__cxa_atexit --with-pkgversion='Sourcery G++ Lite 2009q3-67'
--with-bugurl=https://support.codesourcery.com/GNUToolchain/ --disable-nls
--prefix=/opt/codesourcery
--with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc
--with-build-sysroot=/scratch/julian/2009q3-respin-linux-lite/install/arm-none-linux-gnueabi/libc
--with-gmp=/scratch/julian/2009q3-respin-linux-lite/obj/host-libs-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr
--with-mpfr=/scratch/julian/2009q3-respin-linux-lite/obj/host-libs-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr
--with-ppl=/scratch/julian/2009q3-respin-linux-lite/obj/host-libs-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-cloog=/scratch/julian/2009q3-respin-linux-lite/obj/host-libs-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr
--disable-libgomp --enable-poison-system-directories
--with-build-time-tools=/scratch/julian/2009q3-respin-linux-lite/install/arm-none-linux-gnueabi/bin
--with-build-time-tools=/scratch/julian/2009q3-respin-linux-lite/install/arm-none-linux-gnueabi/bin
Thread model: posix
gcc version 4.4.1 (Sourcery G++ Lite 2009q3-67)
COLLECT_GCC_OPTIONS='-c' '-v' '-march=armv5te' '-funwind-tables'

/usr/local/crosstool-trusted/arm-2009q3/bin/../libexec/gcc/arm-none-linux-gnueabi/4.4.1/cc1
-quiet -v -iprefix
/usr/local/crosstool-trusted/arm-2009q3/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/
-isysroot
/usr/local/crosstool-trusted/arm-2009q3/bin/../arm-none-linux-gnueabi/libc aho.c
-quiet -dumpbase aho.c -march=armv5te -auxbase aho -version -funwind-tables -o
/tmp/ccxVQ6xT.s
ignoring nonexistent directory
"/usr/local/crosstool-trusted/arm-2009q3/bin/../arm-none-linux-gnueabi/libc/usr/local/include"
ignoring duplicate directory
"/usr/local/crosstool-trusted/arm-2009q3/bin/../lib/gcc/../../lib/gcc/arm-none-linux-gnueabi/4.4.1/include"
ignoring duplicate directory
"/usr/local/crosstool-trusted/arm-2009q3/bin/../lib/gcc/../../lib/gcc/arm-none-linux-gnueabi/4.4.1/include-fixed"
ignoring duplicate directory
"/usr/local/crosstool-trusted/arm-2009q3/bin/../lib/gcc/../../lib/gcc/arm-none-linux-gnueabi/4.4.1/../../../../arm-none-linux-gnueabi/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/crosstool-trusted/arm-2009q3/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/include

/usr/local/crosstool-trusted/arm-2009q3/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/include-fixed

/usr/local/crosstool-trusted/arm-2009q3/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/../../../../arm-none-linux-gnueabi/include

/usr/local/crosstool-trusted/arm-2009q3/bin/../arm-none-linux-gnueabi/libc/usr/include
End of search list.
GNU C (Sourcery G++ Lite 2009q3-67) version 4.4.1 (arm-none-linux-gnueabi)
        compiled by GNU C version 4.3.2, GMP version 4.3.1, MPFR version
2.4.1-p5.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 74011fea7f66b1cda6b19363b6694363
test.c:1: fatal error: gnome-keyring.h: No such file or directory
compilation terminated.

Regards,

Hironori Bono

[piman, 2010-06-09 05:40:32]

On Tue, Jun 8, 2010 at 6:06 PM, <mdm@chromium.org> wrote:

> On 2010/06/09 01:01:29, piman wrote:
>
>  On Tue, Jun 8, 2010 at 5:43 PM, <mailto:mdm@chromium.org> wrote:
>>
>
>  > On 2010/06/09 00:36:53, piman wrote:
>> >
>> >> I think I'm lacking context to understand why this is arm-related... It
>> >> looks
>> >> like the default is to dlopen the library, so that should be ok
>> (assuming
>> >> it
>> >> degrades gracefully if the library isn't present).
>> >>
>> >
>> > The "Chromium Arm (dbg)" builder was getting a compile error - it
>> couldn't
>> > find
>> > gnome-keyring.h, although maurel says libgnome-keyring-dev is definitely
>> > installed on that bot.
>> >
>> > I'm wondering if perhaps pkg-config --cflags gnome-keyring-1 wasn't
>> > happening or
>> > something, causing the include path for it to be missing.
>>
>
>
>  I see. On ARM everything is cross-compiled, so the host packages installed
>> on the bot don't matter. They need to be added to the sysroot.
>> However in this case we don't have gnome or its dependencies on Chrome OS
>> so
>> we definitely don't want to link against its libs.
>>
>
>  Antoine
>>
>
>  >
>> >
>> > http://codereview.chromium.org/2774002/show
>> >
>>
>
>
> That's among the reasons this code is set up to dlopen() the library rather
> than
> link against it, but the header file still needs to be there to compile.
> Should
> I change it to just not even compile these files on ChromeOS? In that case,
> what
> condition should I check for to exclude these files?


chromeos==1 is true when compiling for Chrome OS. Yes, I would remove the
files in that case if possible...

Antoine


>
> http://codereview.chromium.org/2774002/show
>

[Mike Mammarella, 2010-06-10 01:18:38]

Will the linux_view bot tell me whether this is right?

[piman, 2010-06-10 01:38:30]

On Wed, Jun 9, 2010 at 6:18 PM, <mdm@chromium.org> wrote:

> Will the linux_view bot tell me whether this is right?


There's a Chrome OS bot :
http://build.chromium.org/buildbot/waterfall.fyi/waterfall?builder=Google%20C...
There's even a linux_chromeos trybot.

They both build with chromeos=1. However I believe those build against the
host headers, not a chrome os sysroot, so you may see different results. The
arm builder however uses a chrome os sysroot, so that one will complain if
something is wrong.

Antoine


>
> http://codereview.chromium.org/2774002/show
>

[Mike Mammarella, 2010-06-10 03:18:11]

Looks like it works - the linux trybot compiled the files, and the
linux_chromeos trybot didn't. LGTY?

[piman, 2010-06-10 05:35:58]

LGTM