Mixed up STAGING_INCDIR's in uclibc.inc?

Mixed up STAGING_INCDIR's in uclibc.inc?

[Geoffrey Wossum]

Hi all,

I'm having a brand new issue building uClibc-0.9.29 for the AVR32.  When 
running do_configure for uclibc, it gets a bunch of errors like:

 
gcc -DCURSES_LOC="<ncurses.h>" -DLOCALE -I/home/geoff/lrs/playpaq/tmp/staging/avr32-angstrom-linux-uclibc/usr/include  -lncursesw 
conf.o  zconf.tab.o -o conf
| conf.o: In function `strip':
| conf.c:(.text+0x20): undefined reference to `__ctype_b'
| conf.c:(.text+0x97): undefined reference to `__ctype_b'
| conf.o: In function `conf_sym':
| conf.c:(.text+0x5bf): undefined reference to `__stdout'
...continues on...

I think the problem is the following line in packages/uclibc/uclibc.inc:
EXTRA_OEMAKE = "${OEMAKE_NO_CC} 'CC=${CC}' HOSTCFLAGS='-I${STAGING_INCDIR}'"

Seems to me like that should be STAGING_INCDIR_NATIVE instead of 
STAGING_INCDIR.  If I make that change, then everything works again.

Does this seem correct? 

---
Geoffrey


#
# old_revision [b5af291fa9dc074af84727684ddae1efa9c1be0d]
#
# patch "packages/uclibc/uclibc.inc"
#  from [472f8824981d2a69ea009b1b57d42dfed1044151]
#    to [cc6432f05133f71d7aae488e59eb8a4423482666]
#
# patch "packages/uclibc/uclibc_0.9.29.bb"
#  from [e670b8966480e150375aa74c2bd62de6c8e5315b]
#    to [0eac903c662c67108b358b1ad2c6d1d976cc5419]
#
============================================================
--- packages/uclibc/uclibc.inc  472f8824981d2a69ea009b1b57d42dfed1044151
+++ packages/uclibc/uclibc.inc  cc6432f05133f71d7aae488e59eb8a4423482666
@@ -72,7 +72,7 @@ OEMAKE_NO_CC = "'STRIPTOOL=true' 'LD=${L
 # the CFLAGS (for when building the utils).
 OEMAKE_NO_CC = "'STRIPTOOL=true' 'LD=${LD}' \
                'LOCALE_DATA_FILENAME=${UCLIBC_LOCALE_FILE}'"
-EXTRA_OEMAKE = "${OEMAKE_NO_CC} 'CC=${CC}' HOSTCFLAGS='-I${STAGING_INCDIR}'"
+EXTRA_OEMAKE = "${OEMAKE_NO_CC} 'CC=${CC}' HOSTCFLAGS='-I${STAGING_INCDIR_NATIVE}'"
 EXTRA_OEMAKE_task_do_populate_staging = "${OEMAKE_NO_CC}"
 EXTRA_OEMAKE_task_do_package = "${OEMAKE_NO_CC}"

============================================================
--- packages/uclibc/uclibc_0.9.29.bb    e670b8966480e150375aa74c2bd62de6c8e5315b
+++ packages/uclibc/uclibc_0.9.29.bb    0eac903c662c67108b358b1ad2c6d1d976cc5419
@@ -7,7 +7,7 @@ UCLIBC_BASE ?= "0.9.29"
 # on whether the base patches apply to the selected (SRCDATE) svn release.
 #
 UCLIBC_BASE ?= "0.9.29"
-PR = "r13"
+PR = "r14"

 require uclibc.inc

Re: Mixed up STAGING_INCDIR's in uclibc.inc?

[Leon Woestenberg]

Hello Geoffrey, Marcin, Richard,

(I think Marcin committed the original change, and I think from Poky)

On Mon, Apr 28, 2008 at 9:51 PM, Geoffrey Wossum <geoffrey@pager.net> wrote:
>  Seems to me like that should be STAGING_INCDIR_NATIVE instead of
>  STAGING_INCDIR.  If I make that change, then everything works again.
>

Additionally, there is another issue:

The original patch Changelog entry described this patch was done as
uclibc needs ncurses-native instead of host provided ncurses.
Now, it seems the committer forgot to add this to the DEPENDS.

I have a freshly installed Ubuntu 8.04, and I probably don't have the
ncurses-dev, whereas Geoffrey probably does, which explains the
difference.

Does this make sense?

Regards,
-- 
Leon

Re: Mixed up STAGING_INCDIR's in uclibc.inc?

[Khem Raj]

On Mon, Apr 28, 2008 at 2:39 PM, Leon Woestenberg
<leon.woestenberg@gmail.com> wrote:
> Hello Geoffrey, Marcin, Richard,
>
> (I think Marcin committed the original change, and I think from Poky)
>
> On Mon, Apr 28, 2008 at 9:51 PM, Geoffrey Wossum <geoffrey@pager.net> wrote:
> >  Seems to me like that should be STAGING_INCDIR_NATIVE instead of
> >  STAGING_INCDIR.  If I make that change, then everything works again.
> >
>
> Additionally, there is another issue:
>
> The original patch Changelog entry described this patch was done as
> uclibc needs ncurses-native instead of host provided ncurses.
> Now, it seems the committer forgot to add this to the DEPENDS.
>
> I have a freshly installed Ubuntu 8.04, and I probably don't have the
> ncurses-dev, whereas Geoffrey probably does, which explains the
> difference.
>
> Does this make sense?

Yeah I dont hit this problem as I have libncurses5-dev installed on my host.

>
> Regards,
> --
> Leon
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: Mixed up STAGING_INCDIR's in uclibc.inc?

[Holger Freyther]

On Monday 28 April 2008 21:51:05 Geoffrey Wossum wrote:
> Hi all,
>
> I'm having a brand new issue building uClibc-0.9.29 for the AVR32.  When
> running do_configure for uclibc, it gets a bunch of errors like:
>
>
> gcc -DCURSES_LOC="<ncurses.h>" -DLOCALE
> -I/home/geoff/lrs/playpaq/tmp/staging/avr32-angstrom-linux-uclibc/usr/inclu
>de  -lncursesw conf.o  zconf.tab.o -o conf
>
> | conf.o: In function `strip':
> | conf.c:(.text+0x20): undefined reference to `__ctype_b'
> | conf.c:(.text+0x97): undefined reference to `__ctype_b'
> | conf.o: In function `conf_sym':
> | conf.c:(.text+0x5bf): undefined reference to `__stdout'
>
> ...continues on...
>
> I think the problem is the following line in packages/uclibc/uclibc.inc:
> EXTRA_OEMAKE = "${OEMAKE_NO_CC} 'CC=${CC}'
> HOSTCFLAGS='-I${STAGING_INCDIR}'"
>
> Seems to me like that should be STAGING_INCDIR_NATIVE instead of
> STAGING_INCDIR.  If I make that change, then everything works again.
>
> Does this seem correct?


hmm, in autoconf terminology host is:
"  --host=HOST       cross-compile to build programs to run on HOST [BUILD]"

if uclibc has the same terminology your patch is wrong, I don't know it 
though.

Re: Mixed up STAGING_INCDIR's in uclibc.inc?

[Geoffrey Wossum]

On Monday 28 April 2008 04:49:46 pm Holger Freyther wrote:
> On Monday 28 April 2008 21:51:05 Geoffrey Wossum wrote:

> > I think the problem is the following line in packages/uclibc/uclibc.inc:
> > EXTRA_OEMAKE = "${OEMAKE_NO_CC} 'CC=${CC}'
> > HOSTCFLAGS='-I${STAGING_INCDIR}'"
> >
> > Seems to me like that should be STAGING_INCDIR_NATIVE instead of
> > STAGING_INCDIR.  If I make that change, then everything works again.
> >
> > Does this seem correct?
>
> hmm, in autoconf terminology host is:
> "  --host=HOST       cross-compile to build programs to run on HOST
> [BUILD]"
>
> if uclibc has the same terminology your patch is wrong, I don't know it
> though.

Ah, autotools, my old nemesis.  How have you been?  This new plot of yours to 
corrupt projects which don't use you by confusing people is indeed fiendish.  
But then, I would expect no less of such a worthy adversary.

uClibc uses Kconfig/kbuild, which uses HOST to mean the machine we are 
currently building on.  

From linux/Documentation/kbuild/makefiles.txt:
Kbuild supports building executables on the host for use during the
compilation stage.

Yes, it is very confusing. 

---
Geoffrey

Re: Mixed up STAGING_INCDIR's in uclibc.inc?

[Leon Woestenberg]

Hello,

On Mon, Apr 28, 2008 at 11:49 PM, Holger Freyther <zecke@selfish.org> wrote:
> On Monday 28 April 2008 21:51:05 Geoffrey Wossum wrote:
>  hmm, in autoconf terminology host is:
>  "  --host=HOST       cross-compile to build programs to run on HOST [BUILD]"
>
>  if uclibc has the same terminology your patch is wrong, I don't know it
>  though.
>
I think uclibc's usage is that HOST is the build machine.

Adding DEPENDS ncurses-native for both uclibc.inc and
uclibc-initial.inc together with Geoffrey's patch looks the sane
solution to me, but hey, I might misunderstand something here.

The confusion started with commit "3afb4ffc02c1e4bde1031645cfa9f8e5465f2138".

Could you guys please see into that commit, and follow-up from there?

I hate to unbreak things into the wrong direction.

Regards,
-- 
Leon

Re: Mixed up STAGING_INCDIR's in uclibc.inc?

[Leon Woestenberg]

Hello,

On Tue, Apr 29, 2008 at 12:19 AM, Leon Woestenberg
<leon.woestenberg@gmail.com> wrote:
>  On Mon, Apr 28, 2008 at 11:49 PM, Holger Freyther <zecke@selfish.org> wrote:
>  > On Monday 28 April 2008 21:51:05 Geoffrey Wossum wrote:
>
>  The confusion started with commit "3afb4ffc02c1e4bde1031645cfa9f8e5465f2138".
>  Could you guys please see into that commit, and follow-up from there?
>
FWIW, by reading the intention of the patch commit, I checked with the
source (Poky), and indeed _NATIVE is used, and uclibc.inc DEPENDS on
ncurses-native.

One question remaining for me (and I think Poky might be broken in
that respect?) is that uclibc-initial_0.9.29.bb in Poky does not
DEPEND on ncurses-native (and does not re-use the .inc DEPENDS btw).

I have committed the _NATIVE, on both DEPENDS to the .dev branch.

Regards,
-- 
Leon

Re: Mixed up STAGING_INCDIR's in uclibc.inc?

[Khem Raj]

uclibc-initial recipe has this

require uclibc_${PV}.bb

That should pull the dependency. but this line

DEPENDS = "linux-libc-headers"

should be changed to

DEPENDS += "linux-libc-headers"

I think.

-Khem

On Mon, Apr 28, 2008 at 10:03 PM, Leon Woestenberg
<leon.woestenberg@gmail.com> wrote:
> Hello,
>
>  On Tue, Apr 29, 2008 at 12:19 AM, Leon Woestenberg
>
> <leon.woestenberg@gmail.com> wrote:
>
> >  On Mon, Apr 28, 2008 at 11:49 PM, Holger Freyther <zecke@selfish.org> wrote:
>  >  > On Monday 28 April 2008 21:51:05 Geoffrey Wossum wrote:
>  >
>
> >  The confusion started with commit "3afb4ffc02c1e4bde1031645cfa9f8e5465f2138".
>  >  Could you guys please see into that commit, and follow-up from there?
>  >
>  FWIW, by reading the intention of the patch commit, I checked with the
>  source (Poky), and indeed _NATIVE is used, and uclibc.inc DEPENDS on
>  ncurses-native.
>
>  One question remaining for me (and I think Poky might be broken in
>  that respect?) is that uclibc-initial_0.9.29.bb in Poky does not
>  DEPEND on ncurses-native (and does not re-use the .inc DEPENDS btw).
>
>  I have committed the _NATIVE, on both DEPENDS to the .dev branch.
>
>
>
>  Regards,
>  --
>  Leon
>
>  _______________________________________________
>  Openembedded-devel mailing list
>  Openembedded-devel@lists.openembedded.org
>  http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: Mixed up STAGING_INCDIR's in uclibc.inc?

[Leon Woestenberg]

Hello Khem,

On Tue, Apr 29, 2008 at 9:48 AM, Khem Raj <raj.khem@gmail.com> wrote:
> uclibc-initial recipe has this
>  require uclibc_${PV}.bb
>
I saw that, indeed.

>  That should pull the dependency. but this line
>
>  DEPENDS = "linux-libc-headers"
>
>  should be changed to
>
>  DEPENDS += "linux-libc-headers"
>
>  I think.
>
No, I think the DEPENDS was *intended* to be overridden with a small
*sub*set that is enough for -initial (to prevent cyclic dependencies).

However, I suspect it should DEPEND on ncurses-native now as well.

You know, I'll fire off a Poky Linux build on a system without
ncurses-dev on the host to verify my thesis,

Regards,

Leon.
>  -Khem
>
>  On Mon, Apr 28, 2008 at 10:03 PM, Leon Woestenberg
>
>
> <leon.woestenberg@gmail.com> wrote:
>  > Hello,
>  >
>  >  On Tue, Apr 29, 2008 at 12:19 AM, Leon Woestenberg
>  >
>  > <leon.woestenberg@gmail.com> wrote:
>  >
>  > >  On Mon, Apr 28, 2008 at 11:49 PM, Holger Freyther <zecke@selfish.org> wrote:
>  >  >  > On Monday 28 April 2008 21:51:05 Geoffrey Wossum wrote:
>  >  >
>  >
>  > >  The confusion started with commit "3afb4ffc02c1e4bde1031645cfa9f8e5465f2138".
>  >  >  Could you guys please see into that commit, and follow-up from there?
>  >  >
>  >  FWIW, by reading the intention of the patch commit, I checked with the
>  >  source (Poky), and indeed _NATIVE is used, and uclibc.inc DEPENDS on
>  >  ncurses-native.
>  >
>  >  One question remaining for me (and I think Poky might be broken in
>  >  that respect?) is that uclibc-initial_0.9.29.bb in Poky does not
>  >  DEPEND on ncurses-native (and does not re-use the .inc DEPENDS btw).
>  >
>  >  I have committed the _NATIVE, on both DEPENDS to the .dev branch.
>  >
>  >
>  >
>  >  Regards,
>  >  --
>  >  Leon
>  >
>
>
> >  _______________________________________________
>  >  Openembedded-devel mailing list
>  >  Openembedded-devel@lists.openembedded.org
>  >  http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>  >
>
>  _______________________________________________
>  Openembedded-devel mailing list
>  Openembedded-devel@lists.openembedded.org
>  http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



-- 
Leon

Re: Mixed up STAGING_INCDIR's in uclibc.inc?

[Richard Purdie]

On Tue, 2008-04-29 at 14:07 +0200, Leon Woestenberg wrote:
> On Tue, Apr 29, 2008 at 9:48 AM, Khem Raj <raj.khem@gmail.com> wrote:
> >  That should pull the dependency. but this line
> >
> >  DEPENDS = "linux-libc-headers"
> >
> >  should be changed to
> >
> >  DEPENDS += "linux-libc-headers"
> >
> >  I think.
> >
> No, I think the DEPENDS was *intended* to be overridden with a small
> *sub*set that is enough for -initial (to prevent cyclic dependencies).
> 
> However, I suspect it should DEPEND on ncurses-native now as well.
> 
> You know, I'll fire off a Poky Linux build on a system without
> ncurses-dev on the host to verify my thesis,

This was a recent fix to Poky. I removed all the -dev packages from our
build machine and my desktop and can confirm it worked without the -dev
package installed after the fix. I don't think its needed for -initial,
just for the main version but I could be wrong. Be sure to use "bitbake
uclibc-initial" when you test.

Cheers,

Richard

Re: Mixed up STAGING_INCDIR's in uclibc.inc?

[Leon Woestenberg]

Hello Richard,

On Tue, Apr 29, 2008 at 2:24 PM, Richard Purdie <rpurdie@rpsys.net> wrote:
> On Tue, 2008-04-29 at 14:07 +0200, Leon Woestenberg wrote:
>  > On Tue, Apr 29, 2008 at 9:48 AM, Khem Raj <raj.khem@gmail.com> wrote:
>  > However, I suspect it should DEPEND on ncurses-native now as well.
>  >
>  > You know, I'll fire off a Poky Linux build on a system without
>  > ncurses-dev on the host to verify my thesis,
>
>  This was a recent fix to Poky. I removed all the -dev packages from our
>  build machine and my desktop and can confirm it worked without the -dev
>  package installed after the fix. I don't think its needed for -initial,
>
Uhm, *what* worked exactly?

I just did a "bitbake uclibc-initial" SVN with POKYLIBC=uclibc and it fails.

>  just for the main version but I could be wrong. Be sure to use "bitbake
>  uclibc-initial" when you test.
>
I just checked; uclibc-initial_0.9.29.bb needs a DEPEND on ncurses-native.

That fixes it. I committed this to OE yesterday.

Regards,
-- 
Leon

Re: Mixed up STAGING_INCDIR's in uclibc.inc?

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1482 bytes --]

On Tue, 2008-04-29 at 13:24 +0100, Richard Purdie wrote:
> On Tue, 2008-04-29 at 14:07 +0200, Leon Woestenberg wrote:
> > On Tue, Apr 29, 2008 at 9:48 AM, Khem Raj <raj.khem@gmail.com> wrote:
> > >  That should pull the dependency. but this line
> > >
> > >  DEPENDS = "linux-libc-headers"
> > >
> > >  should be changed to
> > >
> > >  DEPENDS += "linux-libc-headers"
> > >
> > >  I think.
> > >
> > No, I think the DEPENDS was *intended* to be overridden with a small
> > *sub*set that is enough for -initial (to prevent cyclic dependencies).
> > 
> > However, I suspect it should DEPEND on ncurses-native now as well.
> > 
> > You know, I'll fire off a Poky Linux build on a system without
> > ncurses-dev on the host to verify my thesis,
> 
> This was a recent fix to Poky. I removed all the -dev packages from our
> build machine and my desktop and can confirm it worked without the -dev
> package installed after the fix. I don't think its needed for -initial,
> just for the main version but I could be wrong. Be sure to use "bitbake
> uclibc-initial" when you test.

if you are doing anything with kconfig in the recipe you will need
libncurses-dev which I think uclibc-initial is doing.

> 
> Cheers,
> 
> Richard
> 
> 
> 
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: Mixed up STAGING_INCDIR's in uclibc.inc?

[Richard Purdie]

On Tue, 2008-04-29 at 07:22 -0700, Khem Raj wrote:
> On Tue, 2008-04-29 at 13:24 +0100, Richard Purdie wrote:
> > This was a recent fix to Poky. I removed all the -dev packages from our
> > build machine and my desktop and can confirm it worked without the -dev
> > package installed after the fix. I don't think its needed for -initial,
> > just for the main version but I could be wrong. Be sure to use "bitbake
> > uclibc-initial" when you test.
> 
> if you are doing anything with kconfig in the recipe you will need
> libncurses-dev which I think uclibc-initial is doing.

Thanks makes sense and I didn't explicitly test uclibc-initial so its
likely I didn't see the problem. I'll update Poky with that change too.

Cheers,

Richard

Firefox 2.0.0.3 - alix - glib2 - libidl2

[lists]

I was able to build firefox 2 months ago. 
I see those missing glib.h and IDL.h which are indeed exist in staging inc path

[avr@dev org.openembedded.dev]$ ls tmp/staging/i586-angstrom-linux/usr/include/glib-2.0/glib.h
tmp/staging/i586-angstrom-linux/usr/include/glib-2.0/glib.h

[avr@dev org.openembedded.dev]$ ls tmp/staging/i586-angstrom-linux/usr/include/libIDL-2.0/libIDL/IDL.h
tmp/staging/i586-angstrom-linux/usr/include/libIDL-2.0/libIDL/IDL.h

mozilla configure script :

line 6305
if test ! -f "${_GLIB_PREFIX_DIR}/include/glib.h"; then
        { echo "configure: error: Cannot find $_GLIB_PREFIX_DIR/include/glib.h ." 1>&2; exit 1; }
    Fi

And line 6330

if test ! -f "${_LIBIDL_PREFIX_DIR}/include/libIDL/IDL.h"; then
        { echo "configure: error: Cannot find $_LIBIDL_PREFIX_DIR/include/libIDL/IDL.h ." 1>&2; exit 1; }
    Fi

As you can see those paths are different than the ones installed by glib and libidl.


Below is the error while trying to complile.

Any patch suggestions for those new glib/idl versions?



| ccache gcc -o host_xpidl.o -c -isystem/home/avr/OE/org.openembedded.dev/tmp/staging/i686-linux/usr/include -Os -DXP_UNIX -O3  `PKG_CONFIG_PATH=/home/avr/OE/org.openembedded.dev/tmp/staging/i686-linux/usr/lib/pkgconfig pkg-config libIDL-2.0 --cflags` -DMDCPUCFG=\"md/_linux.cfg\"   -I../../../dist/include/xpcom -I../../../dist/include -I../../../dist/include/nspr    -I../../../dist/sdk/include -I../../../dist/include/nspr xpidl.c
| In file included from xpidl.c:42:
| xpidl.h:49:18: error: glib.h: No such file or directory
| xpidl.h:53:24: error: libIDL/IDL.h: No such file or directory
| In file included from xpidl.c:42:
| xpidl.h:83: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'enable_debug'
| xpidl.h:84: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'enable_warnings'
| xpidl.h:85: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'verbose_mode'
| xpidl.h:86: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'emit_typelib_annotations'
| xpidl.h:87: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'explicit_output_filename'
| xpidl.h:97: error: expected declaration specifiers or '...' before '*' token
| xpidl.h:97: error: 'gboolean' declared as function returning a function
| xpidl.h:103: error: expected specifier-qualifier-list before 'nodeHandler'
| xpidl.h:133: error: expected specifier-qualifier-list before 'IDL_ns'
| xpidl.h:141: error: expected specifier-qualifier-list before 'GHashTable'
| xpidl.h:159: error: expected ')' before 'p'
| xpidl.h:180: error: 'xpidl_process_node' declared as function returning a function
| xpidl.h:205: error: 'xpidl_sprint_iid' declared as function returning a function
| xpidl.h:212: error: 'xpidl_parse_iid' declared as function returning a function
| xpidl.h:244: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'find_underlying_type'
| xpidl.h:251: error: expected ')' before 'const_tree'
| xpidl.h:257: error: expected ')' before 'method_tree'
| xpidl.h:263: error: expected ')' before 'method_tree'
| xpidl.h:269: error: expected ')' before 'method_tree'
| xpidl.h:276: error: 'check_native' declared as function returning a function
| xpidl.h:279: error: expected declaration specifiers or '...' before 'GSList'
| xpidl.c:63: error: function 'enable_debug' is initialized like a variable
| xpidl.c:63: error: 'FALSE' undeclared here (not in a function)
| xpidl.c:64: error: function 'enable_warnings' is initialized like a variable
| xpidl.c:65: error: function 'verbose_mode' is initialized like a variable
| xpidl.c:66: error: function 'emit_typelib_annotations' is initialized like a variable
| xpidl.c:67: error: function 'explicit_output_filename' is initialized like a variable
| xpidl.c: In function 'main':
| xpidl.c:107: error: function 'create_old_typelib' is initialized like a variable
| xpidl.c:131: error: 'TRUE' undeclared (first use in this function)
| xpidl.c:131: error: (Each undeclared identifier is reported only once
| xpidl.c:131: error: for each function it appears in.)
| xpidl.c:144: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
| xpidl.c:144: error: 'typelib_version_string' undeclared (first use in this function)
| xpidl.c:157: warning: the address of 'create_old_typelib', will always evaluate as 'true'
| make[6]: *** [host_xpidl.o] Error 1


Thanks

Bill