C-C TB Build error: incorrect -II path specification for mozilla/dom/base, "mozilla/" is missing.

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

C-C TB Build error: incorrect -II path specification for mozilla/dom/base, "mozilla/" is missing.

ISHIKAWA,chiaki
Hi,

Starting about 12 hours ago, I refreshed my source and got hit with
another build bustage locally.

Namely, some header files in M-C part of the tree cannot be found during
compilation.

I thought it was a temporary fluke. But, no, it is permanent. Although I
refreshed my tree about an hour ago, the problem still persists.

I took a close look and found that header files below
${MOZ_SRC}/mozilla/dom/base

where MOZ_SRC is the top-level of my local C-C TB tree, are not found
during compilation.

Checking the compiler command line, I found that the -I specification
that is supposed to point to
that directory is incorrect.

After configure,  it comes out as
  -I  ${MOZ_SRC}/dom/base

without "mozilla/" part, thus the compiler could not find the header
files under mozilla/dom/base.

Have anyone seen this?

I have no idea about where to look except I vaguely recall that there
has been incorrect directory path specification before. But in that
case, I recall that the variable for the new build/configure mechanism
got it all wrong and every include path became incorrect (?)
In this case, I found the errors seemed to occur only for the header
files under mozilla/dom/base.

TIA

CI

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: C-C TB Build error: incorrect -II path specification for mozilla/dom/base, "mozilla/" is missing.

ISHIKAWA,chiaki
On 2016/02/04 0:19, ISHIKAWA,chiaki wrote:

> Hi,
>
> Starting about 12 hours ago, I refreshed my source and got hit with
> another build bustage locally.
>
> Namely, some header files in M-C part of the tree cannot be found
> during compilation.
>
> I thought it was a temporary fluke. But, no, it is permanent. Although
> I refreshed my tree about an hour ago, the problem still persists.
>
> I took a close look and found that header files below
> ${MOZ_SRC}/mozilla/dom/base
>
> where MOZ_SRC is the top-level of my local C-C TB tree, are not found
> during compilation.
>
> Checking the compiler command line, I found that the -I specification
> that is supposed to point to
> that directory is incorrect.
>
> After configure,  it comes out as
>  -I  ${MOZ_SRC}/dom/base
>
> without "mozilla/" part, thus the compiler could not find the header
> files under mozilla/dom/base.
>
> Have anyone seen this?
>
> I have no idea about where to look except I vaguely recall that there
> has been incorrect directory path specification before. But in that
> case, I recall that the variable for the new build/configure mechanism
> got it all wrong and every include path became incorrect (?)
> In this case, I found the errors seemed to occur only for the header
> files under mozilla/dom/base.
>
> TIA
>
> CI

(I am adding dev-builds mailing list in the hompe that someone there may
notice a symptom of known issue.)


I investigated a little further and noticed that

/dom/base was specified in the LOCAL_INCLUDES variable
in respective directory where the problem ocucrred.

So just as experiment, I changed /dom/base into a relative form such as
../../dom/base
../../../dom/base
../../../../dom/base
according to the depth of the directory where moz.build is located.


Voila!

The compilation proceeded!?

But I am really puzzled.
Only the header files under dom/base are affected.

This problem did not occur Jan 31 (and Feb 1 I think).
It certainly did not occur before that.

Only yesterday after refreshing the source, I noticed this problem.
I looked at the mercurial logs of M-C portion of the tree, but could not
find
an entry that stood out (I am not familiar with build system and so
I may have missed a crucial patch, etc. Also, there is a blanket log
that says it would include all the patches in mozilla-incoming.)

BTW, funny, it seems that LOCAL_INCLUDES seems to expect a SORTED list of
values when a value is appended to it,
and so I had to move the relative pathnames to the front of the list
where there are multiple directories specified in LOCAL_INCLUDES: but
I am afraid there may be an issue of improper ordering of
include directories if we are forced to use lexicographically sorted
include list paths. We may have a couple of header files with the SAME
name and
may want to include a particular one by specifying the include directory
path for that include file. A case in point is discussed below [1])

I was so puzzled and I looked into bugzilla and searched for
|LOCAL_INCLUDES|, but
only found an entry which generally discusses the header file inclusion
issue.

I wonder why possibly I am the only person on the earth who see this
problem  under local Linux development environment(?).

I am using Debian GNU/Linux 64-bit.

I had to disable a few features such as gstreams, etc. (gstream under
Debian GNU/Linux is old and does not meet the version requirement of
mozilla software.)

But otherwise, I don't see a problem with my mozconfig.
Like I mentioned, the build worked like a charm until Feb 1st.

Any tips/hints regarding this issue will be appreciated.
Should I file a bug ?

[1] Case in point.
mozilla/accessible/generic/HyperTextAccessible.cpp
includes "TreeWalker.h".

There are two TreeWalker.h in the source tree:
mozilla/accessible/base/TreeWalker.h
mozilla/dom/base/TreeWalker.h

HyperTextAccessible.cpp needs to include the version under
accessible/base, not
under mozilla/dom/base. (If the latter is included, compiler complains about
type mismatch.)

So to meet the requirement that the value added to LOCAL_INCLUDES must
be a sorted list and that ../../dom/base does not come before
accessible/base in this particular case, I had to split the list into
two as below.

LOCAL_INCLUDES += [
     '/accessible/base',
     '/accessible/html',
     '/accessible/ipc',
     '/accessible/xpcom',
     '/accessible/xul',
     '/layout/generic',
     '/layout/xul',
]

# I need to add /dom/base, but this has to be specified as relative
# for some reason, and has to come AFTER the others.
# Because of the requirement that a list must be sorted, I have to
# separate the addition of dom/base in another assignment that comes
# after the above (!)
LOCAL_INCLUDES += ['../../dom/base' ]


PS: But again, I am curious why this bustage?
Only headers below dom/base seem to be affected.



_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: C-C TB Build error: incorrect -II path specification for mozilla/dom/base, "mozilla/" is missing.

ISHIKAWA,chiaki
In reply to this post by ISHIKAWA,chiaki
On 2016年02月05日 00:49, ISHIKAWA,chiaki wrote:

> On 2016/02/04 0:19, ISHIKAWA,chiaki wrote:
>> Hi,
>>
>> Starting about 12 hours ago, I refreshed my source and got hit with
>> another build bustage locally.
>>
>> Namely, some header files in M-C part of the tree cannot be found during
>> compilation.
>>
>> I thought it was a temporary fluke. But, no, it is permanent. Although I
>> refreshed my tree about an hour ago, the problem still persists.
>>
>> I took a close look and found that header files below
>> ${MOZ_SRC}/mozilla/dom/base
>>
>> where MOZ_SRC is the top-level of my local C-C TB tree, are not found
>> during compilation.
>>
>> Checking the compiler command line, I found that the -I specification that
>> is supposed to point to
>> that directory is incorrect.
>>
>> After configure,  it comes out as
>>  -I  ${MOZ_SRC}/dom/base
>>
>> without "mozilla/" part, thus the compiler could not find the header files
>> under mozilla/dom/base.
>>
>> Have anyone seen this?
>>
>> I have no idea about where to look except I vaguely recall that there has
>> been incorrect directory path specification before. But in that case, I
>> recall that the variable for the new build/configure mechanism got it all
>> wrong and every include path became incorrect (?)
>> In this case, I found the errors seemed to occur only for the header files
>> under mozilla/dom/base.
>>
>> TIA
>>
>> CI
>
> (I am adding dev-builds mailing list in the hompe that someone there may
> notice a symptom of known issue.)
>
>
> I investigated a little further and noticed that
>
> /dom/base was specified in the LOCAL_INCLUDES variable
> in respective directory where the problem ocucrred.
>
> So just as experiment, I changed /dom/base into a relative form such as
> ../../dom/base
> ../../../dom/base
> ../../../../dom/base
> according to the depth of the directory where moz.build is located.
>
>
> Voila!
>
> The compilation proceeded!?
>
> But I am really puzzled.
> Only the header files under dom/base are affected.
>
> This problem did not occur Jan 31 (and Feb 1 I think).
> It certainly did not occur before that.
>
> Only yesterday after refreshing the source, I noticed this problem.
> I looked at the mercurial logs of M-C portion of the tree, but could not find
> an entry that stood out (I am not familiar with build system and so
> I may have missed a crucial patch, etc. Also, there is a blanket log that
> says it would include all the patches in mozilla-incoming.)
>
> BTW, funny, it seems that LOCAL_INCLUDES seems to expect a SORTED list of
> values when a value is appended to it,
> and so I had to move the relative pathnames to the front of the list
> where there are multiple directories specified in LOCAL_INCLUDES: but
> I am afraid there may be an issue of improper ordering of
> include directories if we are forced to use lexicographically sorted include
> list paths. We may have a couple of header files with the SAME name and
> may want to include a particular one by specifying the include directory
> path for that include file. A case in point is discussed below [1])
>
> I was so puzzled and I looked into bugzilla and searched for
> |LOCAL_INCLUDES|, but
> only found an entry which generally discusses the header file inclusion issue.
>
> I wonder why possibly I am the only person on the earth who see this
> problem  under local Linux development environment(?).
>
> I am using Debian GNU/Linux 64-bit.
>
> I had to disable a few features such as gstreams, etc. (gstream under Debian
> GNU/Linux is old and does not meet the version requirement of mozilla
> software.)
>
> But otherwise, I don't see a problem with my mozconfig.
> Like I mentioned, the build worked like a charm until Feb 1st.
>
> Any tips/hints regarding this issue will be appreciated.
> Should I file a bug ?
>
> [1] Case in point.
> mozilla/accessible/generic/HyperTextAccessible.cpp
> includes "TreeWalker.h".
>
> There are two TreeWalker.h in the source tree:
> mozilla/accessible/base/TreeWalker.h
> mozilla/dom/base/TreeWalker.h
>
> HyperTextAccessible.cpp needs to include the version under accessible/base, not
> under mozilla/dom/base. (If the latter is included, compiler complains about
> type mismatch.)
>
> So to meet the requirement that the value added to LOCAL_INCLUDES must be a
> sorted list and that ../../dom/base does not come before accessible/base in
> this particular case, I had to split the list into two as below.
>
> LOCAL_INCLUDES += [
>     '/accessible/base',
>     '/accessible/html',
>     '/accessible/ipc',
>     '/accessible/xpcom',
>     '/accessible/xul',
>     '/layout/generic',
>     '/layout/xul',
> ]
>
> # I need to add /dom/base, but this has to be specified as relative
> # for some reason, and has to come AFTER the others.
> # Because of the requirement that a list must be sorted, I have to
> # separate the addition of dom/base in another assignment that comes
> # after the above (!)
> LOCAL_INCLUDES += ['../../dom/base' ]
>
>
> PS: But again, I am curious why this bustage?
> Only headers below dom/base seem to be affected.
>

The closest bug I can think of and found is the following one.

Bug 1222591 - nsMsgUtils.cpp:52:10: fatal error: 'nsProtocolProxyService.h'
file not found

But in that case, the header was not during the compilation of source files
in C-C portion of the tree.
This time, the compilation failes since the compiler can not find the
headers during the compilation of
the files in M-C portion of the tree. Strange...

TIA

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: C-C TB Build error: incorrect -II path specification for mozilla/dom/base, "mozilla/" is missing.

Stefan Sitter-2
In reply to this post by ISHIKAWA,chiaki
  On 2016/02/04 0:19, ISHIKAWA,chiaki wrote:
> Starting about 12 hours ago, I refreshed my source and got hit with
> another build bustage locally.
>
> Namely, some header files in M-C part of the tree cannot be found during
> compilation.

According to <https://treeherder.mozilla.org/#/jobs?repo=comm-central>  
Linux x64, Mac OS X and Windows compilation finished successfully on  
05-Feb-2016, indicating this might be problem with your local build  
only. Have you tried a clean build with clean source tree?
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: C-C TB Build error: incorrect -II path specification for mozilla/dom/base, "mozilla/" is missing.

ISHIKAWA,chiaki
On 2016/02/06 18:49, Stefan Sitter wrote:

>  On 2016/02/04 0:19, ISHIKAWA,chiaki wrote:
>> Starting about 12 hours ago, I refreshed my source and got hit with
>> another build bustage locally.
>>
>> Namely, some header files in M-C part of the tree cannot be found during
>> compilation.
>
> According to <https://treeherder.mozilla.org/#/jobs?repo=comm-central>
> Linux x64, Mac OS X and Windows compilation finished successfully on
> 05-Feb-2016, indicating this might be problem with your local build
> only. Have you tried a clean build with clean source tree?
> _______________________________________________
> dev-apps-thunderbird mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-apps-thunderbird
>
>

I did and the build failed with the same issue.

But if the build succeeded on 05-Feb-2016 on the try server, maybe there
is hope if I refresh the
source and try again. Stay tuned.

(But I have to tell you that TWO different PCs suffered from the same
build bustage, and the only common factor is that they use Debian
GNU/Linux. So it may be that some tool chain such as python under Debian
GNU/Linux may be to blame. *BUT*, like I said, the problem suddenly
happend on Feb 1 timeframe and
something presumably in M-C portion of the tree changed.)

TIA

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: C-C TB Build error: incorrect -II path specification for mozilla/dom/base, "mozilla/" is missing.

ISHIKAWA,chiaki
In reply to this post by Stefan Sitter-2
On 2016/02/06 18:49, Stefan Sitter wrote:

>  On 2016/02/04 0:19, ISHIKAWA,chiaki wrote:
>> Starting about 12 hours ago, I refreshed my source and got hit with
>> another build bustage locally.
>>
>> Namely, some header files in M-C part of the tree cannot be found during
>> compilation.
>
> According to <https://treeherder.mozilla.org/#/jobs?repo=comm-central>
> Linux x64, Mac OS X and Windows compilation finished successfully on
> 05-Feb-2016, indicating this might be problem with your local build
> only. Have you tried a clean build with clean source tree?

I missed one cruicial point.

What is the difference between the following two?
  comm-central
and
  try-comm-central

I noticed the build mentioned above is with comm-central.
[ Somehow, I was led to believe I should use try-comm-central for a long
time.
I could build on try-comm-central with the patch
8b2b3bdb1f7c
<https://hg.mozilla.org/try-comm-central/rev/8b2b3bdb1f7c>*ISHIKAWA,
Chiaki — fix mozilla/dom/base -I path issue.*

https://hg.mozilla.org/try-comm-central/pushloghtml?changeset=5c80e0ed4ca9
but that should not be necessary, right (?).
I have not tried the build with the patch on try-comm-central. But maybe
I should.

TIA





_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: C-C TB Build error: incorrect -II path specification for mozilla/dom/base, "mozilla/" is missing.

ISHIKAWA,chiaki
On 2016/02/07 3:47, ISHIKAWA,chiaki wrote:

> On 2016/02/06 18:49, Stefan Sitter wrote:
>>  On 2016/02/04 0:19, ISHIKAWA,chiaki wrote:
>>> Starting about 12 hours ago, I refreshed my source and got hit with
>>> another build bustage locally.
>>>
>>> Namely, some header files in M-C part of the tree cannot be found
>>> during
>>> compilation.
>>
>> According to
>> <https://treeherder.mozilla.org/#/jobs?repo=comm-central> Linux x64,
>> Mac OS X and Windows compilation finished successfully on
>> 05-Feb-2016, indicating this might be problem with your local build
>> only. Have you tried a clean build with clean source tree?
>
> I missed one cruicial point.
>
> What is the difference between the following two?
>  comm-central
> and
>  try-comm-central
>
> I noticed the build mentioned above is with comm-central.
> [ Somehow, I was led to believe I should use try-comm-central for a
> long time.
> I could build on try-comm-central with the patch
> 8b2b3bdb1f7c
> <https://hg.mozilla.org/try-comm-central/rev/8b2b3bdb1f7c>*ISHIKAWA,
> Chiaki — fix mozilla/dom/base -I path issue.*
>
> https://hg.mozilla.org/try-comm-central/pushloghtml?changeset=5c80e0ed4ca9 
>
> but that should not be necessary, right (?).
> I have not tried the build with the patch on try-comm-central. But
> maybe I should.
>
I meant to say I have not tried the build *WITHOUT* the patch on
try-comm-central.

I did.

And it worked for OSX and Windows(!!!), but due to the chronicle linux
build bustage (caused by infrastructure issue, I am afraid), linux build
did not succeed at all.

So I am in a situation where I can't build C-C TB under local Debian
GNU/Linux
installations (a couple of them) without a patch that fixes the
strange path issues
while I can certainly see that C-C TB try-comm-central can build windows
and OSX version without such a patch, but it does not tell anything about
linux build due to its inability to build linux binary for now.

Maybe I should rephrase my question.

Is there a Debian user (64-bit) who can build C-C TB locally since Feb 2?

I am suspecting a subtle regular expression library bug in Debian or
something that caused the build script to create incorrect path string.
(A few years ago, for a period of half a year or longer, Debian's GCC
could not compile mozilla source tree at all. I had to give up any
contribution during that time. So distribution-specific bug may habe
crept in this time.)

Well, as long as I can compile with the patch to take care of the issue of
strange include path, that is OK, but I am afraid that
the problem may become more difficult to handle and eventually I
wouldn't be able compile C-C TB as in the situation a few years back.

So I want to hear if fellow Debian users are all right for now.
(At least, I have a couple of PCs with Debian suffering from the same issue
and it suggests it is likely a Debian-specific issue (?). I am perplexed.
I gather mozilla compilation farm uses CentOS.

TIA

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: C-C TB Build error: incorrect -II path specification for mozilla/dom/base, "mozilla/" is missing.

aleth
On Sun, Feb 7, 2016, at 08:10 AM, ISHIKAWA,chiaki wrote:

> On 2016/02/07 3:47, ISHIKAWA,chiaki wrote:
> > On 2016/02/06 18:49, Stefan Sitter wrote:
> >>  On 2016/02/04 0:19, ISHIKAWA,chiaki wrote:
> >>> Starting about 12 hours ago, I refreshed my source and got hit with
> >>> another build bustage locally.
> >>>
> >>> Namely, some header files in M-C part of the tree cannot be found
> >>> during
> >>> compilation.
> >>
> >> According to
> >> <https://treeherder.mozilla.org/#/jobs?repo=comm-central> Linux x64,
> >> Mac OS X and Windows compilation finished successfully on
> >> 05-Feb-2016, indicating this might be problem with your local build
> >> only. Have you tried a clean build with clean source tree?
> >
> > I missed one cruicial point.
> >
> > What is the difference between the following two?
> >  comm-central
> > and
> >  try-comm-central
> >
> > I noticed the build mentioned above is with comm-central.
> > [ Somehow, I was led to believe I should use try-comm-central for a
> > long time.
> > I could build on try-comm-central with the patch
> > 8b2b3bdb1f7c
> > <https://hg.mozilla.org/try-comm-central/rev/8b2b3bdb1f7c>*ISHIKAWA,
> > Chiaki — fix mozilla/dom/base -I path issue.*
> >
> > https://hg.mozilla.org/try-comm-central/pushloghtml?changeset=5c80e0ed4ca9 
> >
> > but that should not be necessary, right (?).
> > I have not tried the build with the patch on try-comm-central. But
> > maybe I should.
> >
> I meant to say I have not tried the build *WITHOUT* the patch on
> try-comm-central.
>
> I did.
>
> And it worked for OSX and Windows(!!!), but due to the chronicle linux
> build bustage (caused by infrastructure issue, I am afraid), linux build
> did not succeed at all.

Fwiw, linux64 builds should succeed on try-c-c, just as they do on c-c.
Your recent try pushes only include "linux" however, which is linux32.
Those builds, while they are OK locally, fail on the server due to an
infra issue.

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: C-C TB Build error: incorrect -II path specification for mozilla/dom/base, "mozilla/" is missing.

ISHIKAWA,chiaki
On 2016/02/07 18:16, [hidden email] wrote:

> On Sun, Feb 7, 2016, at 08:10 AM, ISHIKAWA,chiaki wrote:
>> On 2016/02/07 3:47, ISHIKAWA,chiaki wrote:
>>> On 2016/02/06 18:49, Stefan Sitter wrote:
>>>>   On 2016/02/04 0:19, ISHIKAWA,chiaki wrote:
>>>>> Starting about 12 hours ago, I refreshed my source and got hit with
>>>>> another build bustage locally.
>>>>>
>>>>> Namely, some header files in M-C part of the tree cannot be found
>>>>> during
>>>>> compilation.
>>>> According to
>>>> <https://treeherder.mozilla.org/#/jobs?repo=comm-central> Linux x64,
>>>> Mac OS X and Windows compilation finished successfully on
>>>> 05-Feb-2016, indicating this might be problem with your local build
>>>> only. Have you tried a clean build with clean source tree?
>>> I missed one cruicial point.
>>>
>>> What is the difference between the following two?
>>>   comm-central
>>> and
>>>   try-comm-central
>>>
>>> I noticed the build mentioned above is with comm-central.
>>> [ Somehow, I was led to believe I should use try-comm-central for a
>>> long time.
>>> I could build on try-comm-central with the patch
>>> 8b2b3bdb1f7c
>>> <https://hg.mozilla.org/try-comm-central/rev/8b2b3bdb1f7c>*ISHIKAWA,
>>> Chiaki — fix mozilla/dom/base -I path issue.*
>>>
>>> https://hg.mozilla.org/try-comm-central/pushloghtml?changeset=5c80e0ed4ca9
>>>
>>> but that should not be necessary, right (?).
>>> I have not tried the build with the patch on try-comm-central. But
>>> maybe I should.
>>>
>> I meant to say I have not tried the build *WITHOUT* the patch on
>> try-comm-central.
>>
>> I did.
>>
>> And it worked for OSX and Windows(!!!), but due to the chronicle linux
>> build bustage (caused by infrastructure issue, I am afraid), linux build
>> did not succeed at all.
> Fwiw, linux64 builds should succeed on try-c-c, just as they do on c-c.
> Your recent try pushes only include "linux" however, which is linux32.
> Those builds, while they are OK locally, fail on the server due to an
> infra issue.
>

I see. I will try linux64 push, then.

TIA

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: C-C TB Build error: incorrect -II path specification for mozilla/dom/base, "mozilla/" is missing.

ISHIKAWA,chiaki
In reply to this post by ISHIKAWA,chiaki
On 2016/02/07 16:10, ISHIKAWA,chiaki wrote:

> On 2016/02/07 3:47, ISHIKAWA,chiaki wrote:
>> On 2016/02/06 18:49, Stefan Sitter wrote:
>>>  On 2016/02/04 0:19, ISHIKAWA,chiaki wrote:
>>>> Starting about 12 hours ago, I refreshed my source and got hit with
>>>> another build bustage locally.
>>>>
>>>> Namely, some header files in M-C part of the tree cannot be found
>>>> during
>>>> compilation.
>>>
>>> According to
>>> <https://treeherder.mozilla.org/#/jobs?repo=comm-central> Linux x64,
>>> Mac OS X and Windows compilation finished successfully on
>>> 05-Feb-2016, indicating this might be problem with your local build
>>> only. Have you tried a clean build with clean source tree?
>>
>> I missed one cruicial point.
>>
>> What is the difference between the following two?
>>  comm-central
>> and
>>  try-comm-central
>>
>> I noticed the build mentioned above is with comm-central.
>> [ Somehow, I was led to believe I should use try-comm-central for a
>> long time.
>> I could build on try-comm-central with the patch
>> 8b2b3bdb1f7c
>> <https://hg.mozilla.org/try-comm-central/rev/8b2b3bdb1f7c>*ISHIKAWA,
>> Chiaki — fix mozilla/dom/base -I path issue.*
>>
>> https://hg.mozilla.org/try-comm-central/pushloghtml?changeset=5c80e0ed4ca9 
>>
>> but that should not be necessary, right (?).
>> I have not tried the build with the patch on try-comm-central. But
>> maybe I should.
>>
> I meant to say I have not tried the build *WITHOUT* the patch on
> try-comm-central.
>
> I did.
>
> And it worked for OSX and Windows(!!!), but due to the chronicle linux
> build bustage (caused by infrastructure issue, I am afraid), linux
> build did not succeed at all.
>
> So I am in a situation where I can't build C-C TB under local Debian
> GNU/Linux
> installations (a couple of them) without a patch that fixes the
> strange path issues
> while I can certainly see that C-C TB try-comm-central can build
> windows and OSX version without such a patch, but it does not tell
> anything about
> linux build due to its inability to build linux binary for now.
>
> Maybe I should rephrase my question.
>
> Is there a Debian user (64-bit) who can build C-C TB locally since Feb 2?
>
> I am suspecting a subtle regular expression library bug in Debian or
> something that caused the build script to create incorrect path string.
> (A few years ago, for a period of half a year or longer, Debian's GCC
> could not compile mozilla source tree at all. I had to give up any
> contribution during that time. So distribution-specific bug may habe
> crept in this time.)
>
> Well, as long as I can compile with the patch to take care of the
> issue of
> strange include path, that is OK, but I am afraid that
> the problem may become more difficult to handle and eventually I
> wouldn't be able compile C-C TB as in the situation a few years back.
>
> So I want to hear if fellow Debian users are all right for now.
> (At least, I have a couple of PCs with Debian suffering from the same
> issue
> and it suggests it is likely a Debian-specific issue (?). I am perplexed.
> I gather mozilla compilation farm uses CentOS.
>
> TIA

I *think* I figured out the issue somehow at least on one of the Debian
installations.

Background: C-C tree has as its subdirectory under ./mozilla, the M-C
source tree.
C-C tree itself has its own HG repository, .hg, and ./mozilla M-C
portion has its own repository under ./mozilla/.hg.
This means that a patch for C-C must be applied under C-C tree's top
directory
and a patch for M-C must be applied under ./mozilla subdirectory.

Problem found:

In my haste to restore at least a compilation-capable environment after the
bug in  Bug 1243760 - Replace nsPIDOMWindow with
nsPIDOMWindowInner/Outer in C-C due to bug 1241764 and a few others
rendered the source tree unusable at the end of January, I obtained the
interim patch(es) posted in  the related bugzilla entries (I think a few
of serious bugs showed up simultaneously),
and tried to apply them to my local source tree.

I did not realize that the patch(s) was meant for M-C tree and applied
it at the top-most tree of C-C tree. Naturally, the patch failed since
the matching files were not found. But in order to leave .rej files in
the tree, one  such failed patch CREATED ./dom directory at the
top-level of C-C source tree (which should have been ./mozilla/dom in
C-C tree's layout ).
In my haste, I reapplied the patch under ./mozilla subdirectory, but never
bothered to remove the .rej file (and the directory) created.

Apparently, this spurious ./dom directory confused the configure/build
script to create the Makefile, et al to produce
-I...top-level-src-of-C-C/dom instead of the proper
-I...top-level-src-of-C-C/mozilla/dom (note the extra /mozilla/ path)
because top-level-src-of-C-C/dom directory existed (!).

This explains why only the headers under mozilla/dom directory were
missing due to incorrect -I path on this computer.

After removing the suprious top-level ./dom directory and a couple
directories that were created to store .rej patch files by incorrect
application of M-C patch(es) at the top-level of C-C source tree
(instead of ./mozilla M-C subtree),
I ran the equivalent of make -f client.mk configure, and all is well.
The compilation went smoothly.

At least on this computer.

I have no idea why the other linux failed in a similar manner.
But it is possible that I have tried to install the same patches to restore
compile-capable environment temporarily and made the same mistake of
applying M-C patch at the top level of C-C sourc tree instead of
./mozilla subdirectory there, too, possibly. Hunan nature being what it
is, the separate HG repositories overlaid in a single source tree is a
source of mistakes...

I won't be able to put my hands on the other computer until Friday. Once
I check it out, I will report back.

TIA

(BTW, I found this extra ./dom directory by happenstance.
I was checking the source tree for improper use of outdated syntax for
octal literal constant [ Bug 1247052 - Improper outdated octal constant
syntax in mailnews/compose/test/unit/test_bug235432.js.
Initially I used find and grep, but then
I found that calendar subdirectory has a tendency to use
ParseInt("0666", 8) style of specification. So I tried to exclude the
directory and only meant to focus on other other directories when I
noticed a strange "dom" directory under C-C source tree top directory!
Short of this happenstance, I will be scratching my head for the rest of
2016 I suppose.)

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird