Re: Build r1829228 on Linux-32 (gstreamer build problem)

[Don Lewis]

On  1 May, Peter kovacs wrote:
> I think we do have the pain only with Linux. Since some distributions
> move slower then others.
> 
> We could bundle the only 1.0.0 with Windows and Mac I think. For Linux
> we would need some logic, that identifies the right gstreamer
> available on the distribution. Maybe we could even reduce the effort
> to one certain package.

Does Windows even use gstreamer?

> I do not know about OS/2 or BSD. Maybe the appropiate volunteers could
> answer that. But imho it should not be a problem to create an
> additional port for this on BSD and integrate the right extention on
> OS/2.

I switched the FreeBSD port over to 1.0.0.  Both versions of gstreamer
are available, though.

> A complete different approach could be not to bundle the extention. It
> would give us the option for Windows user to add the gstreamer into
> the extention,  providing them a simplified access.
> 
> For Linux a integration into the distribution would be the way. But I
> do not know how we can do that. We need maintainers for that.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Build r1829228 on Linux-32 (gstreamer build problem)

[Kay Schenk]

​Thanks for this info, Damjan. It would be very useful if we could identify
the Linux media player that would likely be used -- as DirectX is for WNT
and QuickTime for Mac. Maybe VLC? This would mean defining a new
​AVMEDIA_MANAGER_SERVICE_NAME, right?


On Tue, May 1, 2018 at 6:51 AM, Damjan Jovanovic  wrote:

> In main/avmedia/source/inc/mediamisc.hxx, the media player is chosen with
> the following code. Note how GStreamer is only used on non-Windows non-Mac
> platforms.
>
> #ifdef WNT
>
> #define AVMEDIA_MANAGER_SERVICE_NAME
> "com.sun.star.comp.avmedia.Manager_DirectX"
> #define AVMEDIA_MANAGER_SERVICE_IS_JAVABASEDsal_False
>
> #define AVMEDIA_MANAGER_SERVICE_NAME_FALLBACK1  ""
> #define AVMEDIA_MANAGER_SERVICE_IS_JAVABASED_FALLBACK1  sal_False
>
> #else
> #ifdef QUARTZ
>
> #define AVMEDIA_MANAGER_SERVICE_NAME
> "com.sun.star.comp.avmedia.Manager_QuickTime"
> #define AVMEDIA_MANAGER_SERVICE_IS_JAVABASEDsal_False
>
> #define AVMEDIA_MANAGER_SERVICE_NAME_FALLBACK1
> "com.sun.star.comp.avmedia.Manager_MacAVF"
> #define AVMEDIA_MANAGER_SERVICE_IS_JAVABASED_FALLBACK1  sal_False
>
> #else
>
> #define AVMEDIA_MANAGER_SERVICE_NAME
> "com.sun.star.comp.avmedia.Manager_GStreamer"
> #define AVMEDIA_MANAGER_SERVICE_IS_JAVABASEDsal_False
>
> #define AVMEDIA_MANAGER_SERVICE_NAME_FALLBACK1
> "com.sun.star.comp.avmedia.Manager_Java"
> #define AVMEDIA_MANAGER_SERVICE_IS_JAVABASED_FALLBACK1  sal_True
>
> #endif
> #endif
>
>
> On Tue, May 1, 2018 at 3:01 PM Peter kovacs  wrote:
>
> > I think we do have the pain only with Linux. Since some distributions
> move
> > slower then others.
> >
> > We could bundle the only 1.0.0 with Windows and Mac I think. For Linux we
> > would need some logic, that identifies the right gstreamer available on
> the
> > distribution.
> > Maybe we could even reduce the effort to one certain package.
> >
> > I do not know about OS/2 or BSD. Maybe the appropiate volunteers could
> > answer that. But imho it should not be a problem to create an additional
> > port for this on BSD and integrate the right extention on OS/2.
> >
> > A complete different approach could be not to bundle the extention. It
> > would give us the option for Windows user to add the gstreamer into the
> > extention,  providing them a simplified access.
> >
> > For Linux a integration into the distribution would be the way. But I do
> > not know how we can do that. We need maintainers for that.
> >
> > Am 1. Mai 2018 13:57:50 MESZ schrieb Jim Jagielski :
> > >So that would mean that our 'official' community builds would
> > >not longer bundle/include it by default? Would we have 2 different
> > >versions of the extension (0.10 and 1.0) or just one?
> > >
> > >I like the idea, btw :)
> > >
> > >> On Apr 26, 2018, at 1:14 AM, Peter Kovacs  wrote:
> > >>
> > >> Does it make sense to reorg the gstreamer module into an extention?
> > >> We could then have multiple versions of it.
> > >>
> > >> I mean after all this is only a optional feature, thats important to
> > >some not all.
> > >>
> > >> On 25.04.2018 16:18, Jim Jagielski wrote:
> > >>> I think this shows that we need to come to *some* consensus on
> > >>> how to handle the gstreamer stuff. Either we provide both CentOS6
> > >>> and Ubuntu builds to our community or we fold in the proposed
> > >>> gstreamer "work-around" which makes it a purely runtime
> > >>> concern.
> > >>>
> > >>> I would love to see how far we can go with the latter, but I am
> > >>> loath to volunteer someone else to "do the work" since I am
> > >>> unsure what the exact status of the patch is, how to fold it
> > >>> into trunk and how to handle building with the patch folded in.
> > >>>
> > >>> I know that there are other issues related to being at the stage
> > >>> to branch AOO420 from trunk but this, to me, seems like the
> > >>> priority at this point.
> > >>>
> > >>>
> > >-
> > >>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > >>> For additional commands, e-mail: dev-h...@openoffice.apache.org
> > >>>
> > >>
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > >> For additional commands, e-mail: dev-h...@openoffice.apache.org
> > >>
> > >
> > >
> > >-
> > >To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > >For additional commands, e-mail: dev-h...@openoffice.apache.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> >
> >
>



-- 
--
MzK

"Less is MORE."

Re: Build r1829228 on Linux-32 (gstreamer build problem)

[Damjan Jovanovic]

In main/avmedia/source/inc/mediamisc.hxx, the media player is chosen with
the following code. Note how GStreamer is only used on non-Windows non-Mac
platforms.

#ifdef WNT

#define AVMEDIA_MANAGER_SERVICE_NAME
"com.sun.star.comp.avmedia.Manager_DirectX"
#define AVMEDIA_MANAGER_SERVICE_IS_JAVABASEDsal_False

#define AVMEDIA_MANAGER_SERVICE_NAME_FALLBACK1  ""
#define AVMEDIA_MANAGER_SERVICE_IS_JAVABASED_FALLBACK1  sal_False

#else
#ifdef QUARTZ

#define AVMEDIA_MANAGER_SERVICE_NAME
"com.sun.star.comp.avmedia.Manager_QuickTime"
#define AVMEDIA_MANAGER_SERVICE_IS_JAVABASEDsal_False

#define AVMEDIA_MANAGER_SERVICE_NAME_FALLBACK1
"com.sun.star.comp.avmedia.Manager_MacAVF"
#define AVMEDIA_MANAGER_SERVICE_IS_JAVABASED_FALLBACK1  sal_False

#else

#define AVMEDIA_MANAGER_SERVICE_NAME
"com.sun.star.comp.avmedia.Manager_GStreamer"
#define AVMEDIA_MANAGER_SERVICE_IS_JAVABASEDsal_False

#define AVMEDIA_MANAGER_SERVICE_NAME_FALLBACK1
"com.sun.star.comp.avmedia.Manager_Java"
#define AVMEDIA_MANAGER_SERVICE_IS_JAVABASED_FALLBACK1  sal_True

#endif
#endif


On Tue, May 1, 2018 at 3:01 PM Peter kovacs  wrote:

> I think we do have the pain only with Linux. Since some distributions move
> slower then others.
>
> We could bundle the only 1.0.0 with Windows and Mac I think. For Linux we
> would need some logic, that identifies the right gstreamer available on the
> distribution.
> Maybe we could even reduce the effort to one certain package.
>
> I do not know about OS/2 or BSD. Maybe the appropiate volunteers could
> answer that. But imho it should not be a problem to create an additional
> port for this on BSD and integrate the right extention on OS/2.
>
> A complete different approach could be not to bundle the extention. It
> would give us the option for Windows user to add the gstreamer into the
> extention,  providing them a simplified access.
>
> For Linux a integration into the distribution would be the way. But I do
> not know how we can do that. We need maintainers for that.
>
> Am 1. Mai 2018 13:57:50 MESZ schrieb Jim Jagielski :
> >So that would mean that our 'official' community builds would
> >not longer bundle/include it by default? Would we have 2 different
> >versions of the extension (0.10 and 1.0) or just one?
> >
> >I like the idea, btw :)
> >
> >> On Apr 26, 2018, at 1:14 AM, Peter Kovacs  wrote:
> >>
> >> Does it make sense to reorg the gstreamer module into an extention?
> >> We could then have multiple versions of it.
> >>
> >> I mean after all this is only a optional feature, thats important to
> >some not all.
> >>
> >> On 25.04.2018 16:18, Jim Jagielski wrote:
> >>> I think this shows that we need to come to *some* consensus on
> >>> how to handle the gstreamer stuff. Either we provide both CentOS6
> >>> and Ubuntu builds to our community or we fold in the proposed
> >>> gstreamer "work-around" which makes it a purely runtime
> >>> concern.
> >>>
> >>> I would love to see how far we can go with the latter, but I am
> >>> loath to volunteer someone else to "do the work" since I am
> >>> unsure what the exact status of the patch is, how to fold it
> >>> into trunk and how to handle building with the patch folded in.
> >>>
> >>> I know that there are other issues related to being at the stage
> >>> to branch AOO420 from trunk but this, to me, seems like the
> >>> priority at this point.
> >>>
> >>>
> >-
> >>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >>> For additional commands, e-mail: dev-h...@openoffice.apache.org
> >>>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >> For additional commands, e-mail: dev-h...@openoffice.apache.org
> >>
> >
> >
> >-
> >To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >For additional commands, e-mail: dev-h...@openoffice.apache.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Build r1829228 on Linux-32 (gstreamer build problem)

[Peter kovacs]

I think we do have the pain only with Linux. Since some distributions move 
slower then others.

We could bundle the only 1.0.0 with Windows and Mac I think. For Linux we would 
need some logic, that identifies the right gstreamer available on the 
distribution.
Maybe we could even reduce the effort to one certain package.

I do not know about OS/2 or BSD. Maybe the appropiate volunteers could answer 
that. But imho it should not be a problem to create an additional port for this 
on BSD and integrate the right extention on OS/2.

A complete different approach could be not to bundle the extention. It would 
give us the option for Windows user to add the gstreamer into the extention,  
providing them a simplified access.

For Linux a integration into the distribution would be the way. But I do not 
know how we can do that. We need maintainers for that.

Am 1. Mai 2018 13:57:50 MESZ schrieb Jim Jagielski :
>So that would mean that our 'official' community builds would
>not longer bundle/include it by default? Would we have 2 different
>versions of the extension (0.10 and 1.0) or just one?
>
>I like the idea, btw :)
>
>> On Apr 26, 2018, at 1:14 AM, Peter Kovacs  wrote:
>> 
>> Does it make sense to reorg the gstreamer module into an extention?
>> We could then have multiple versions of it.
>> 
>> I mean after all this is only a optional feature, thats important to
>some not all.
>> 
>> On 25.04.2018 16:18, Jim Jagielski wrote:
>>> I think this shows that we need to come to *some* consensus on
>>> how to handle the gstreamer stuff. Either we provide both CentOS6
>>> and Ubuntu builds to our community or we fold in the proposed
>>> gstreamer "work-around" which makes it a purely runtime
>>> concern.
>>> 
>>> I would love to see how far we can go with the latter, but I am
>>> loath to volunteer someone else to "do the work" since I am
>>> unsure what the exact status of the patch is, how to fold it
>>> into trunk and how to handle building with the patch folded in.
>>> 
>>> I know that there are other issues related to being at the stage
>>> to branch AOO420 from trunk but this, to me, seems like the
>>> priority at this point.
>>> 
>>>
>-
>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>> 
>
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>For additional commands, e-mail: dev-h...@openoffice.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Build r1829228 on Linux-32 (gstreamer build problem)

[Jim Jagielski]

So that would mean that our 'official' community builds would
not longer bundle/include it by default? Would we have 2 different
versions of the extension (0.10 and 1.0) or just one?

I like the idea, btw :)

> On Apr 26, 2018, at 1:14 AM, Peter Kovacs  wrote:
> 
> Does it make sense to reorg the gstreamer module into an extention?
> We could then have multiple versions of it.
> 
> I mean after all this is only a optional feature, thats important to some not 
> all.
> 
> On 25.04.2018 16:18, Jim Jagielski wrote:
>> I think this shows that we need to come to *some* consensus on
>> how to handle the gstreamer stuff. Either we provide both CentOS6
>> and Ubuntu builds to our community or we fold in the proposed
>> gstreamer "work-around" which makes it a purely runtime
>> concern.
>> 
>> I would love to see how far we can go with the latter, but I am
>> loath to volunteer someone else to "do the work" since I am
>> unsure what the exact status of the patch is, how to fold it
>> into trunk and how to handle building with the patch folded in.
>> 
>> I know that there are other issues related to being at the stage
>> to branch AOO420 from trunk but this, to me, seems like the
>> priority at this point.
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Build r1829228 on Linux-32 (gstreamer build problem)

[Kay Schenk]

On 04/25/2018 10:14 PM, Peter Kovacs wrote:
> Does it make sense to reorg the gstreamer module into an extention?
> We could then have multiple versions of it.
>
> I mean after all this is only a optional feature, thats important to
> some not all.

I think this idea is very good and deserves serious consideration. 
Thanks for bringing it up.

>
> On 25.04.2018 16:18, Jim Jagielski wrote:
>> I think this shows that we need to come to *some* consensus on
>> how to handle the gstreamer stuff. Either we provide both CentOS6
>> and Ubuntu builds to our community or we fold in the proposed
>> gstreamer "work-around" which makes it a purely runtime
>> concern.
>>
>> I would love to see how far we can go with the latter, but I am
>> loath to volunteer someone else to "do the work" since I am
>> unsure what the exact status of the patch is, how to fold it
>> into trunk and how to handle building with the patch folded in.
>>
>> I know that there are other issues related to being at the stage
>> to branch AOO420 from trunk but this, to me, seems like the
>> priority at this point.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>

-- 
--
MzK

"Less is MORE."


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Build r1829228 on Linux-32 (gstreamer build problem)

[Peter Kovacs]

Does it make sense to reorg the gstreamer module into an extention?
We could then have multiple versions of it.

I mean after all this is only a optional feature, thats important to 
some not all.


On 25.04.2018 16:18, Jim Jagielski wrote:

I think this shows that we need to come to *some* consensus on
how to handle the gstreamer stuff. Either we provide both CentOS6
and Ubuntu builds to our community or we fold in the proposed
gstreamer "work-around" which makes it a purely runtime
concern.

I would love to see how far we can go with the latter, but I am
loath to volunteer someone else to "do the work" since I am
unsure what the exact status of the patch is, how to fold it
into trunk and how to handle building with the patch folded in.

I know that there are other issues related to being at the stage
to branch AOO420 from trunk but this, to me, seems like the
priority at this point.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Build r1829228 on Linux-32 (gstreamer build problem)

[Jim Jagielski]

I think this shows that we need to come to *some* consensus on
how to handle the gstreamer stuff. Either we provide both CentOS6
and Ubuntu builds to our community or we fold in the proposed
gstreamer "work-around" which makes it a purely runtime
concern.

I would love to see how far we can go with the latter, but I am
loath to volunteer someone else to "do the work" since I am
unsure what the exact status of the patch is, how to fold it
into trunk and how to handle building with the patch folded in.

I know that there are other issues related to being at the stage
to branch AOO420 from trunk but this, to me, seems like the
priority at this point.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Build r1829228 on Linux-32 (gstreamer build problem)

[Kay Schenk]

On Mon, Apr 23, 2018 at 1:50 AM, Peter Kovacs 
wrote:

> Does the build work without gstreamer activated?
>

​Yes, without gstreamer as part of the my  config, I can build without
issue.



>
> Am 23. April 2018 03:09:49 MESZ schrieb Kay Schenk :
> >On Sun, Apr 22, 2018, 15:47 Andrea Pescetti 
> >wrote:
> >
> >> Matthias Seidel wrote:
> >> > Am 23.04.2018 um 00:15 schrieb Andrea Pescetti:
> >> >> Correct. Jim's builds (not only releases) are done with CentOS 6,
> >so
> >> >> they will work on CentOS 6 too, and Kay can try with the latest
> >link
> >> >> you gave. Only buildbots builds won't.
> >> > And that's the problem, even Jim's build won't run! ;-)
> >> > https://bz.apache.org/ooo/show_bug.cgi?id=127738
> >>
> >> This is because those specific builds, as an exceptional case, were
> >done
> >> on Ubuntu: https://s.apache.org/Jwr0
> >>
> >> Regards,
> >>Andrea.
> >>
> >
> >One final note on this. Jim had built 4.2.0 on CentOS6 a while back
> >before
> >the gstreamer 1.0 update and that one DID work for me.
> >
> >We'll see how things go from here.
> >
> >
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >> For additional commands, e-mail: dev-h...@openoffice.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


-- 
--
MzK

"Less is MORE."

Re: Build r1829228 on Linux-32 (gstreamer build problem)

[Peter Kovacs]

Does the build work without gstreamer activated?

Am 23. April 2018 03:09:49 MESZ schrieb Kay Schenk :
>On Sun, Apr 22, 2018, 15:47 Andrea Pescetti 
>wrote:
>
>> Matthias Seidel wrote:
>> > Am 23.04.2018 um 00:15 schrieb Andrea Pescetti:
>> >> Correct. Jim's builds (not only releases) are done with CentOS 6,
>so
>> >> they will work on CentOS 6 too, and Kay can try with the latest
>link
>> >> you gave. Only buildbots builds won't.
>> > And that's the problem, even Jim's build won't run! ;-)
>> > https://bz.apache.org/ooo/show_bug.cgi?id=127738
>>
>> This is because those specific builds, as an exceptional case, were
>done
>> on Ubuntu: https://s.apache.org/Jwr0
>>
>> Regards,
>>Andrea.
>>
>
>One final note on this. Jim had built 4.2.0 on CentOS6 a while back
>before
>the gstreamer 1.0 update and that one DID work for me.
>
>We'll see how things go from here.
>
>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Build Problem (solved)

[Andrea Pescetti]

On 08/08/2015 Jason Marshall wrote:

build completed and I was able to install from the build. ...
Hopefully from there I can tackle some of the smaller issues
identified on Bugzilla and so make a meaningful contribution.


Welcome Jason, congratulations and if you want to start making some 
small contributions that will immediately be useful to the project you 
can practice with the release blockers for 4.1.2.


A particularly simple one, for example, is
https://bz.apache.org/ooo/show_bug.cgi?id=126454
which can be solved the same way as
https://bz.apache.org/ooo/show_bug.cgi?id=125965
but still allows you to practice updating components. If you wish to try 
with that one, just let us know (and ask for any doubts); otherwise I'll 
take care of this one and we can find several other issues to fix.


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Build Problem (solved)

[Regina Henschel]

Hi Jason,

Jason Marshall schrieb:

Hi Regina


Thank you for the advice here.  I followed what you said and moved
the source into the root of C drive, placing it in a directory with
no special characters.  I did subsequently encounter an issue with
building the modules associated with the SDK, but I re-ran configure
with SDK disabled using the --disable-odk command.  Accordingly, the
build completed and I was able to install from the build.


That is good news. Congratulation.




I will not move onto some of the tutorials kindly provided on the OO
wiki and have a go at hacking some of the code on my own computer.
Hopefully from there I can tackle some of the smaller issues
identified on Bugzilla and so make a meaningful contribution.


When you have identified an area of interest, you should write a note. 
OpenOffice is huge. Perhaps you can get then some useful hints and tips 
from our experts.


Kind regards
Regina













From: Regina Henschel Sent: ‎Tuesday‎, ‎21‎ ‎July‎ ‎2015 ‎12‎:‎51 To:
dev@openoffice.apache.org





Hi Jason,

Jason Marshall schrieb:

Hi Regina

Thank you for looking at this.  I have ensured that with a new
Cygwin session I have run the following successfully:

/source winenv.set.sh/


Following that, I have run the following:

/build --all:comphelper 2>&1 | tee mybuild.log/


The build again did not progress past building the 'comphelper'
module and appeared to have the same error as previously.  However,
I have attached the log file, 'mybuild.log' that was produced.

When I ran the 'configure' command, I ran this with the following
parameters:

/./configure --with-frame-home="$SDK_PATH"
--with-psdk-home="$SDK_PATH" --with-midl-path="$SDK_PATH/bin"
--with-ant-home="/cygdrive/c/ant"
--with-jdk-home="/cygdrive/c/Java/jdk1.8.0_45"
--with-dmake-url="//https://github.com/mohawk2/dmake/archive/DMAKE_4_12.tar.gz//";



--with-epm-url="//https://www.msweet.org/files/project2/epm-4.2-source.tar.gz//";

--enable-pch --disable-atl --disable-activex --without-junit
--disable-directx/


Please try with removed --enable-pch "pch" is "precompiled header
support"

--with-epm-url is not needed for Windows builds.

You might want to add --without-fonts, download of "gentium"
sometimes fails.




I have also included as a file attachment the output of running
'configure' and can confirm that no errors were generated, although
two warnings were as follows, which appear to not be related to the
issue here:

/checking which cppunit to use... configure: WARNING: not using
cppunit/ /configure: WARNING: NSIS not found, no self contained
installer will be build./


I also note from the 'configure' output that the source code is
identified as being in the 'tmp' directory as follows:

/The variable SRC_ROOT  is set to:
C:/cygwin/tmp/aoo-4.1.1/main/


Do you think that it may be better for me to delete the part of
the build that has succeeded and then unpack the source into
another directory that is not temp?  If so, would this simply be to
the root of the Cygwin file system?


Yes, I think it is better to put the source not under tmp or any
other directory, which is set somewhere as temp-directory.

I have always use a directory directly under C: I have always use
names without special characters. I have never tried to put the
source somewhere inside cygwin, so I cannot say, whether that is
possible.

To test, whether the tmp directory is the problem, please move the
folder aoo-4.1.1 under C: and rename it to e.g. aoo411

You need to remove all remainders of previous build tries then. In
cygwin change to the main folder of your source, then use the
following command (all in one line) find . -maxdepth 2 -name
"wntmsci12*" | xargs rm -rf

In addition you have to manually delete the wntmsci12* folders in
main/solver in all subfolders of ext_libraries in all subfolders of
extras

Start with a new configure with parameters.

Hopefully it works better then.

Kind regards Regina





-



To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org

For additional commands, e-mail: dev-h...@openoffice.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Build Problem (solved)

[Jason Marshall]

Hi Regina


Thank you for the advice here.  I followed what you said and moved the source 
into the root of C drive, placing it in a directory with no special characters. 
 I did subsequently encounter an issue with building the modules associated 
with the SDK, but I re-ran configure with SDK disabled using the --disable-odk 
command.  Accordingly, the build completed and I was able to install from the 
build.


I will not move onto some of the tutorials kindly provided on the OO wiki and 
have a go at hacking some of the code on my own computer.  Hopefully from there 
I can tackle some of the smaller issues identified on Bugzilla and so make a 
meaningful contribution.


Best regards


Jason






Sent from Windows Mail





From: Regina Henschel
Sent: ‎Tuesday‎, ‎21‎ ‎July‎ ‎2015 ‎12‎:‎51
To: dev@openoffice.apache.org





Hi Jason,

Jason Marshall schrieb:
> Hi Regina
>
> Thank you for looking at this.  I have ensured that with a new Cygwin
> session I have run the following successfully:
>
> /source winenv.set.sh/
>
>
> Following that, I have run the following:
>
> /build --all:comphelper 2>&1 | tee mybuild.log/
>
>
> The build again did not progress past building the 'comphelper' module
> and appeared to have the same error as previously.  However, I have
> attached the log file, 'mybuild.log' that was produced.
>
> When I ran the 'configure' command, I ran this with the following
> parameters:
>
> /./configure --with-frame-home="$SDK_PATH"
> --with-psdk-home="$SDK_PATH" --with-midl-path="$SDK_PATH/bin"
> --with-ant-home="/cygdrive/c/ant"
> --with-jdk-home="/cygdrive/c/Java/jdk1.8.0_45"
> 
> --with-dmake-url="//https://github.com/mohawk2/dmake/archive/DMAKE_4_12.tar.gz//";
> 
> --with-epm-url="//https://www.msweet.org/files/project2/epm-4.2-source.tar.gz//";
> --enable-pch --disable-atl --disable-activex --without-junit
> --disable-directx/

Please try with removed --enable-pch
"pch" is "precompiled header support"

--with-epm-url is not needed for Windows builds.

You might want to add --without-fonts, download of "gentium" sometimes 
fails.

>
>
> I have also included as a file attachment the output of running
> 'configure' and can confirm that no errors were generated, although two
> warnings were as follows, which appear to not be related to the issue here:
>
> /checking which cppunit to use... configure: WARNING: not using cppunit/
> /configure: WARNING: NSIS not found, no self contained installer
> will be build./
>
>
> I also note from the 'configure' output that the source code is
> identified as being in the 'tmp' directory as follows:
>
> /The variable SRC_ROOT  is set to: C:/cygwin/tmp/aoo-4.1.1/main/
>
>
> Do you think that it may be better for me to delete the part of the
> build that has succeeded and then unpack the source into another
> directory that is not temp?  If so, would this simply be to the root of
> the Cygwin file system?

Yes, I think it is better to put the source not under tmp or any other 
directory, which is set somewhere as temp-directory.

I have always use a directory directly under C:
I have always use names without special characters.
I have never tried to put the source somewhere inside cygwin, so I 
cannot say, whether that is possible.

To test, whether the tmp directory is the problem, please move the 
folder aoo-4.1.1 under C: and rename it to e.g. aoo411

You need to remove all remainders of previous build tries then.
In cygwin change to the main folder of your source, then use the 
following command (all in one line)
find . -maxdepth 2 -name "wntmsci12*" | xargs rm -rf

In addition you have to manually delete the wntmsci12* folders
in main/solver
in all subfolders of ext_libraries
in all subfolders of extras

Start with a new configure with parameters.

Hopefully it works better then.

Kind regards
Regina





-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Build Problem

[Regina Henschel]

Hi Jason,

Jason Marshall schrieb:

Hi Regina

Thank you for looking at this.  I have ensured that with a new Cygwin
session I have run the following successfully:

/source winenv.set.sh/


Following that, I have run the following:

/build --all:comphelper 2>&1 | tee mybuild.log/


The build again did not progress past building the 'comphelper' module
and appeared to have the same error as previously.  However, I have
attached the log file, 'mybuild.log' that was produced.

When I ran the 'configure' command, I ran this with the following
parameters:

/./configure --with-frame-home="$SDK_PATH"
--with-psdk-home="$SDK_PATH" --with-midl-path="$SDK_PATH/bin"
--with-ant-home="/cygdrive/c/ant"
--with-jdk-home="/cygdrive/c/Java/jdk1.8.0_45"

--with-dmake-url="//https://github.com/mohawk2/dmake/archive/DMAKE_4_12.tar.gz//";

--with-epm-url="//https://www.msweet.org/files/project2/epm-4.2-source.tar.gz//";
--enable-pch --disable-atl --disable-activex --without-junit
--disable-directx/


Please try with removed --enable-pch
"pch" is "precompiled header support"

--with-epm-url is not needed for Windows builds.

You might want to add --without-fonts, download of "gentium" sometimes 
fails.





I have also included as a file attachment the output of running
'configure' and can confirm that no errors were generated, although two
warnings were as follows, which appear to not be related to the issue here:

/checking which cppunit to use... configure: WARNING: not using cppunit/
/configure: WARNING: NSIS not found, no self contained installer
will be build./


I also note from the 'configure' output that the source code is
identified as being in the 'tmp' directory as follows:

/The variable SRC_ROOT  is set to: C:/cygwin/tmp/aoo-4.1.1/main/


Do you think that it may be better for me to delete the part of the
build that has succeeded and then unpack the source into another
directory that is not temp?  If so, would this simply be to the root of
the Cygwin file system?


Yes, I think it is better to put the source not under tmp or any other 
directory, which is set somewhere as temp-directory.


I have always use a directory directly under C:
I have always use names without special characters.
I have never tried to put the source somewhere inside cygwin, so I 
cannot say, whether that is possible.


To test, whether the tmp directory is the problem, please move the 
folder aoo-4.1.1 under C: and rename it to e.g. aoo411


You need to remove all remainders of previous build tries then.
In cygwin change to the main folder of your source, then use the 
following command (all in one line)

find . -maxdepth 2 -name "wntmsci12*" | xargs rm -rf

In addition you have to manually delete the wntmsci12* folders
in main/solver
in all subfolders of ext_libraries
in all subfolders of extras

Start with a new configure with parameters.

Hopefully it works better then.

Kind regards
Regina





-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

RE: Build Problem

[Jason Marshall]

Having looked again at the following build error message:
 

awk: fatal: can't open source file 
`C:/cygwinc:/cygwin/tmp/aoo-4.1.1/main/solenv/gbuild/processdeps.awk' for 
reading (No such file or directory)
C:/cygwin/tmp/aoo-4.1.1/main/solenv/gbuild/PrecompiledHeaders.mk:49: recipe for 
target 
'/tmp/aoo-4.1.1/main/solver/411/wntmsci12.pro/workdir/PrecompiledHeader/nodebug/precompiled_comphelper.hxx.pch'
 failed
make: *** 
[/tmp/aoo-4.1.1/main/solver/411/wntmsci12.pro/workdir/PrecompiledHeader/nodebug/precompiled_comphelper.hxx.pch]
 Error 2
dmake:  Error code 2, while making 'all'
 
I have viewed the file 'precompiled_comphelper.hxx.pch' using vi and having 
searched have found multiple hard-coded entries to an invalid path as follows:
 

C:/cygwinc:/cygwin/tmp/aoo-4.1.1/main/solver/411/wntmsci12.pro/inc/stl
C:/cygwinc:/cygwin/tmp/aoo-4.1.1/main/solver/411/wntmsci12.pro/inc/external
C:/cygwinc:/cygwin/tmp/aoo-4.1.1/main/solver/411/wntmsci12.pro/inc
C:/cygwinc:/cygwin/tmp/aoo-4.1.1/main/solenv/wntmsci12/inc
C:/cygwinc:/cygwin/tmp/aoo-4.1.1/main/solenv/inc
C:/cygwinc:/cygwin/tmp/aoo-4.1.1/main/res
C:/cygwinc:/cygwin/tmp/aoo-4.1.1/main/solver/411/wntmsci12.pro/inc/stl
C:/cygwinc:/Cygwin/tmp/aoo-4.1.1/main/solver/411/wntmsci12.pro/inc/external
C:/cygwinc:/cygwin/tmp/aoo-4.1.1/main/solver/411/wntmsci12.pro/inc
C:/cygwinc:/cygwin/tmp/aoo-4.1.1/main/solenv/wntmsci12/inc
C:/cygwinc:/cygwin/tmp/aoo-4.1.1/main/solenv/inc
C:/cygwinc:/cygwin/tmp/aoo-4.1.1/main/res
 
However, other paths in the same file do appear correct, as follows:
 

c:\cygwin\tmp\aoo-4.1.1\main\solver\411\wntmsci12.pro\workdir\linktarget\pdb\library\icomphelp.lib.pdb
I am guessing that this is a header file for the C++ code.  Based on the date 
and time of modification, which is at the time of my last build attempt, I am 
guessing that the header file is produced at build time.  However, I am 
struggling to understand how this erroneous path is being introduced.  
Presumably it is by whatever process of creating the 
'precompiled_comphelper.hxx.pch' file.  Furthermore, it seems to be only some 
of the paths in the header file that are incorrect, with others being correct.
 
I guess that at least this has narrowed things down, but I am still struggling 
to know where to go from here.
 
Thanks
 
Jason

 
> Date: Sat, 18 Jul 2015 20:03:11 +0200
> From: rb.hensc...@t-online.de
> To: dev@openoffice.apache.org
> Subject: Re: Build Problem
> 
> Hi Jason,
> 
> you have put the source into a folder under "tmp". I see the same in the 
> mail you referred. I'm not sure, but it might be, that this confuses 
> some path settings.
> 
> 
> Some curious errors appear, if the path settings are not applied or if 
> build is called from a wrong directory.
> 
> Please close your cygwin window. Then open it again.
> Change into folder "main" of the source.
> Call command
> 
>  source winenv.set.sh
> 
> Change into folder "instsetoo_native"
> 
> Call command
> 
>  build --all 2>&1 | tee mybuild.log
> 
> If build still breaks, you should provide some more information, for 
> example your configure command with all its parameters.
> 
> 
> 
> Some access errors might occur, when an antivirus software is running. 
> You can try to exclude the AOO source directory from any scan or you 
> deactive the antivirus software while compiling (and do nothing parallel 
> in that state!).
> 
> Kind regards
> Regina
> 
> 
> 
> Jason Marshall schrieb:
> > Hi everyone
> >
> > I am attempting to build OpenOffice on Windows 7 32-bit having downloaded 
> > version 4.1.1 of the source code.  I have got as far as calling build, but 
> > have encountered the following error which terminates the build:
> >
> > =
> > Building module comphelper
> > =
> > Entering /tmp/aoo-4.1.1/main/comphelper/prj
> > cd .. && make -s -r -j1   && make -s -r deliverlog
> > [ info  ALL ] LinkTarget Library/isal.lib not defined: Assuming headers to 
> > be there!
> > [ info  ALL ] LinkTarget Library/icppuhelper.lib not defined: Assuming 
> > headers to be there!
> > [ info  ALL ] LinkTarget Library/icppu.lib not defined: Assuming headers to 
> > be there!
> > [ info  ALL ] LinkTarget Library/iucbhelper.lib not defined: Assuming 
> > headers to be there!
> > [ info  ALL ] LinkTarget Library/ivos.lib not defined: Assuming headers to 
> > be there!
> > [ info  ALL ] LinkTarget Library/msvcprt.lib not defined: Assuming headers 
> > to be there!
> > [ info  ALL ] LinkTarget Library/uwinapi.lib not defined: Assuming headers 
> > to be there!
> > [ info  ALL ] LinkTarget Library/kernel32.lib not defin

RE: Build Problem

[Jason Marshall]

Hi Regina
 
Thank you for looking at this.  I have ensured that with a new Cygwin session I 
have run the following successfully:
 
source winenv.set.sh
 
Following that, I have run the following:
 
build --all:comphelper 2>&1 | tee mybuild.log
 
The build again did not progress past building the 'comphelper' module and 
appeared to have the same error as previously.  However, I have attached the 
log file, 'mybuild.log' that was produced.
 
When I ran the 'configure' command, I ran this with the following parameters:
 
./configure --with-frame-home="$SDK_PATH" --with-psdk-home="$SDK_PATH" 
--with-midl-path="$SDK_PATH/bin" --with-ant-home="/cygdrive/c/ant" 
--with-jdk-home="/cygdrive/c/Java/jdk1.8.0_45" 
--with-dmake-url="https://github.com/mohawk2/dmake/archive/DMAKE_4_12.tar.gz"; 
--with-epm-url="https://www.msweet.org/files/project2/epm-4.2-source.tar.gz"; 
--enable-pch --disable-atl --disable-activex --without-junit --disable-directx
 
I have also included as a file attachment the output of running 'configure' and 
can confirm that no errors were generated, although two warnings were as 
follows, which appear to not be related to the issue here:
 
checking which cppunit to use... configure: WARNING: not using cppunit
configure: WARNING: NSIS not found, no self contained installer will be build.
 
I also note from the 'configure' output that the source code is identified as 
being in the 'tmp' directory as follows:
 
The variable SRC_ROOT  is set to: C:/cygwin/tmp/aoo-4.1.1/main
 
Do you think that it may be better for me to delete the part of the build that 
has succeeded and then unpack the source into another directory that is not 
temp?  If so, would this simply be to the root of the Cygwin file system?
 
If you require any further information, please do let me know.
 
Thanks again.
 
Jason
 
> Date: Sat, 18 Jul 2015 20:03:11 +0200
> From: rb.hensc...@t-online.de
> To: dev@openoffice.apache.org
> Subject: Re: Build Problem
> 
> Hi Jason,
> 
> you have put the source into a folder under "tmp". I see the same in the 
> mail you referred. I'm not sure, but it might be, that this confuses 
> some path settings.
> 
> 
> Some curious errors appear, if the path settings are not applied or if 
> build is called from a wrong directory.
> 
> Please close your cygwin window. Then open it again.
> Change into folder "main" of the source.
> Call command
> 
>  source winenv.set.sh
> 
> Change into folder "instsetoo_native"
> 
> Call command
> 
>  build --all 2>&1 | tee mybuild.log
> 
> If build still breaks, you should provide some more information, for 
> example your configure command with all its parameters.
> 
> 
> 
> Some access errors might occur, when an antivirus software is running. 
> You can try to exclude the AOO source directory from any scan or you 
> deactive the antivirus software while compiling (and do nothing parallel 
> in that state!).
> 
> Kind regards
> Regina
> 
> 
> 
> Jason Marshall schrieb:
> > Hi everyone
> >
> > I am attempting to build OpenOffice on Windows 7 32-bit having downloaded 
> > version 4.1.1 of the source code.  I have got as far as calling build, but 
> > have encountered the following error which terminates the build:
> >
> > =
> > Building module comphelper
> > =
> > Entering /tmp/aoo-4.1.1/main/comphelper/prj
> > cd .. && make -s -r -j1   && make -s -r deliverlog
> > [ info  ALL ] LinkTarget Library/isal.lib not defined: Assuming headers to 
> > be there!
> > [ info  ALL ] LinkTarget Library/icppuhelper.lib not defined: Assuming 
> > headers to be there!
> > [ info  ALL ] LinkTarget Library/icppu.lib not defined: Assuming headers to 
> > be there!
> > [ info  ALL ] LinkTarget Library/iucbhelper.lib not defined: Assuming 
> > headers to be there!
> > [ info  ALL ] LinkTarget Library/ivos.lib not defined: Assuming headers to 
> > be there!
> > [ info  ALL ] LinkTarget Library/msvcprt.lib not defined: Assuming headers 
> > to be there!
> > [ info  ALL ] LinkTarget Library/uwinapi.lib not defined: Assuming headers 
> > to be there!
> > [ info  ALL ] LinkTarget Library/kernel32.lib not defined: Assuming headers 
> > to be there!
> > [ info  ALL ] LinkTarget Library/msvcrt.lib not defined: Assuming headers 
> > to be there!
> > [ info  ALL ] LinkTarget Library/oldnames.lib not defined: Assuming headers 
> > to be there!
> > [ build PKG ] comphelper_inc
> > [ build PCH ] precompiled_comphelper
> > precompiled_

Re: Build Problem

[Regina Henschel]

Hi Jason,

you have put the source into a folder under "tmp". I see the same in the 
mail you referred. I'm not sure, but it might be, that this confuses 
some path settings.



Some curious errors appear, if the path settings are not applied or if 
build is called from a wrong directory.


Please close your cygwin window. Then open it again.
Change into folder "main" of the source.
Call command

source winenv.set.sh

Change into folder "instsetoo_native"

Call command

build --all 2>&1 | tee mybuild.log

If build still breaks, you should provide some more information, for 
example your configure command with all its parameters.




Some access errors might occur, when an antivirus software is running. 
You can try to exclude the AOO source directory from any scan or you 
deactive the antivirus software while compiling (and do nothing parallel 
in that state!).


Kind regards
Regina



Jason Marshall schrieb:

Hi everyone

I am attempting to build OpenOffice on Windows 7 32-bit having downloaded 
version 4.1.1 of the source code.  I have got as far as calling build, but have 
encountered the following error which terminates the build:

=
Building module comphelper
=
Entering /tmp/aoo-4.1.1/main/comphelper/prj
cd .. && make -s -r -j1   && make -s -r deliverlog
[ info  ALL ] LinkTarget Library/isal.lib not defined: Assuming headers to be 
there!
[ info  ALL ] LinkTarget Library/icppuhelper.lib not defined: Assuming headers 
to be there!
[ info  ALL ] LinkTarget Library/icppu.lib not defined: Assuming headers to be 
there!
[ info  ALL ] LinkTarget Library/iucbhelper.lib not defined: Assuming headers 
to be there!
[ info  ALL ] LinkTarget Library/ivos.lib not defined: Assuming headers to be 
there!
[ info  ALL ] LinkTarget Library/msvcprt.lib not defined: Assuming headers to 
be there!
[ info  ALL ] LinkTarget Library/uwinapi.lib not defined: Assuming headers to 
be there!
[ info  ALL ] LinkTarget Library/kernel32.lib not defined: Assuming headers to 
be there!
[ info  ALL ] LinkTarget Library/msvcrt.lib not defined: Assuming headers to be 
there!
[ info  ALL ] LinkTarget Library/oldnames.lib not defined: Assuming headers to 
be there!
[ build PKG ] comphelper_inc
[ build PCH ] precompiled_comphelper
precompiled_comphelper.cxx
awk: fatal: can't open source file 
`C:/cygwinc:/cygwin/tmp/aoo-4.1.1/main/solenv/gbuild/processdeps.awk' for 
reading (No such file or directory)
C:/cygwin/tmp/aoo-4.1.1/main/solenv/gbuild/PrecompiledHeaders.mk:49: recipe for 
target 
'/tmp/aoo-4.1.1/main/solver/411/wntmsci12.pro/workdir/PrecompiledHeader/nodebug/precompiled_comphelper.hxx.pch'
 failed
make: *** 
[/tmp/aoo-4.1.1/main/solver/411/wntmsci12.pro/workdir/PrecompiledHeader/nodebug/precompiled_comphelper.hxx.pch]
 Error 2
dmake:  Error code 2, while making 'all'
1 module(s):
 comphelper
need(s) to be rebuilt
Reason(s):
ERROR: error 65280 occurred while making /tmp/aoo-4.1.1/main/comphelper/prj
When you have fixed the errors in that module you can resume the build by 
running:
 build --all:comphelper

I have confirmed that 'processdeps.awk' does indeed exist and believe that the 
problem is that the script is attempting to find the file using a following 
directory, which is clearly invalid:

C:/cygwinc:/cygwin/tmp/aoo-4.1.1/main/solenv/gbuild

It therefore seems that for some reason the build process is using a patently 
incorrect file path.  I have tried to understand the workings of the 'build' 
script and the overall process, including looking in the relevant 'build.lst' 
file, but there is nothing obvious.  Also, I note that this issue was reported 
by someone else previously at the following link:

http://mail-archives.apache.org/mod_mbox/openoffice-dev/201301.mbox/%3c50f54500.6050...@googlemail.com%3E

However, it did not appear to get any answer.  I am rather stumped and 
essentially cannot move forward, so if anyone can help, that would be 
appreciated.

Thanks

Jason





-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Build Problem

[Jason Marshall]

Hi everyone
 
I am attempting to build OpenOffice on Windows 7 32-bit having downloaded 
version 4.1.1 of the source code.  I have got as far as calling build, but have 
encountered the following error which terminates the build:
 
=
Building module comphelper
=
Entering /tmp/aoo-4.1.1/main/comphelper/prj
cd .. && make -s -r -j1   && make -s -r deliverlog
[ info  ALL ] LinkTarget Library/isal.lib not defined: Assuming headers to be 
there!
[ info  ALL ] LinkTarget Library/icppuhelper.lib not defined: Assuming headers 
to be there!
[ info  ALL ] LinkTarget Library/icppu.lib not defined: Assuming headers to be 
there!
[ info  ALL ] LinkTarget Library/iucbhelper.lib not defined: Assuming headers 
to be there!
[ info  ALL ] LinkTarget Library/ivos.lib not defined: Assuming headers to be 
there!
[ info  ALL ] LinkTarget Library/msvcprt.lib not defined: Assuming headers to 
be there!
[ info  ALL ] LinkTarget Library/uwinapi.lib not defined: Assuming headers to 
be there!
[ info  ALL ] LinkTarget Library/kernel32.lib not defined: Assuming headers to 
be there!
[ info  ALL ] LinkTarget Library/msvcrt.lib not defined: Assuming headers to be 
there!
[ info  ALL ] LinkTarget Library/oldnames.lib not defined: Assuming headers to 
be there!
[ build PKG ] comphelper_inc
[ build PCH ] precompiled_comphelper
precompiled_comphelper.cxx
awk: fatal: can't open source file 
`C:/cygwinc:/cygwin/tmp/aoo-4.1.1/main/solenv/gbuild/processdeps.awk' for 
reading (No such file or directory)
C:/cygwin/tmp/aoo-4.1.1/main/solenv/gbuild/PrecompiledHeaders.mk:49: recipe for 
target 
'/tmp/aoo-4.1.1/main/solver/411/wntmsci12.pro/workdir/PrecompiledHeader/nodebug/precompiled_comphelper.hxx.pch'
 failed
make: *** 
[/tmp/aoo-4.1.1/main/solver/411/wntmsci12.pro/workdir/PrecompiledHeader/nodebug/precompiled_comphelper.hxx.pch]
 Error 2
dmake:  Error code 2, while making 'all'
1 module(s):
comphelper
need(s) to be rebuilt
Reason(s):
ERROR: error 65280 occurred while making /tmp/aoo-4.1.1/main/comphelper/prj
When you have fixed the errors in that module you can resume the build by 
running:
build --all:comphelper
 
I have confirmed that 'processdeps.awk' does indeed exist and believe that the 
problem is that the script is attempting to find the file using a following 
directory, which is clearly invalid:
 
C:/cygwinc:/cygwin/tmp/aoo-4.1.1/main/solenv/gbuild
 
It therefore seems that for some reason the build process is using a patently 
incorrect file path.  I have tried to understand the workings of the 'build' 
script and the overall process, including looking in the relevant 'build.lst' 
file, but there is nothing obvious.  Also, I note that this issue was reported 
by someone else previously at the following link:
 
http://mail-archives.apache.org/mod_mbox/openoffice-dev/201301.mbox/%3c50f54500.6050...@googlemail.com%3E
 
However, it did not appear to get any answer.  I am rather stumped and 
essentially cannot move forward, so if anyone can help, that would be 
appreciated.
 
Thanks
 
Jason
  

Re: Checked out revision 1547453 Build problem on Windows 7

[Herbert Duerr]

Hello Vadim,

I'm replying on the general mailing list again, because there are some 
points that may be of general interest.


On 12.12.2013 08:43, Vadim Yedzinovich wrote:

Successful build AOO 4.1.0!


That's an important milestone. Congratulations!


But I have to update C:\source\aoo-trunk\main\sal\inc\rtl>allocator.hxx
So this module need to be updated in SVN repository as well if it is not
done yet.


You mean the commenting out of code in allocator.hxx? They used to be 
superfluous and you observed them to be problematic in some 
environments, so I removed them already in revision 1549785.



Could you please let me know what need to be done according to this?


To get this something like this done you could write a small issue in 
our bugzilla [1] and attach a patch. Or for small changes you could 
suggest them directly here on this mailing list. After some 
contributions the PMC [2] may invites you to become a committer, so you 
could commit it directly then.


[1] https://issues.apache.org/ooo/
[2] http://www.apache.org/foundation/how-it-works.html
[3] https://community.apache.org/contributors/


Perhaps it make sense to update information on page
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Building_on_Windows
according to requested for build Visual C++ 2008 Feature Pack Release.


You can discuss better formulations here or you could update it yourself 
directly, when you get an account for that Wiki. Signing up there is 
easy [4].


[4] 
https://wiki.openoffice.org/w/index.php?title=Special:UserLogin&returnto=Main+Page&type=signup



What do you think?


Welcome aboard ;-)

Herbert

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Checked out revision 1547453 Build problem on Windows 7

[Vadim Yedzinovich]

Hello Herbert,

Have install Visual C++ 2008 Feature Pack Release.

Go ahead but have another problem...
Now with Handler.cxx:

=

Building module writerfilter

=

Entering /cygdrive/c/source/aoo-trunk/main/writerfilter/source/resourcemodel

 Entering
/cygdrive/c/source/aoo-trunk/main/writerfilter/unocomponent/debugservices/doctok

 Entering /cygdrive/c/source/aoo-trunk/main/writerfilter/source/ooxml

Compiling: writerfilter/source/ooxml/Handler.cxx

C:/source/aoo-trunk/main/writerfilter/source/ooxml/Handler.cxx(49) : error
C2664: 'writerfilter::ooxml ::OOXMLFastContextHandler::resolveFootnote' :
cannot convert parameter 1 from 'rtl::OUString' to 'cons t sal_Int32'

No user-defined-conversion operator available that can perform this
conversion, or the operato r cannot be called

C:/source/aoo-trunk/main/writerfilter/source/ooxml/Handler.cxx(77) : error
C2664: 'writerfilter::ooxml ::OOXMLFastContextHandler::resolveEndnote' :
cannot convert parameter 1 from 'rtl::OUString' to 'const sal_Int32'

No user-defined-conversion operator available that can perform this
conversion, or the operato r cannot be called

C:/source/aoo-trunk/main/writerfilter/source/ooxml/Handler.cxx(105) : error
C2664: 'writerfilter::ooxm l::OOXMLFastContextHandler::resolveComment' :
cannot convert parameter 1 from 'rtl::OUString' to 'cons t sal_Int32'

No user-defined-conversion operator available that can perform this
conversion, or the operato r cannot be called

dmake: Error code 2, while making '../../wntmsci12.pro/slo/Handler.obj'

1 module(s):

writerfilter

need(s) to be rebuilt

Last Changed Rev: 1549788

Thank you,
Vadim.
2013/12/10 Herbert Duerr 

> On 09.12.2013 17:46, Vadim Yedzinovich wrote:
>
>> Hello Herbert,
>>
>>
>> Commented:
>> //namespace _STL
>> //{
>> ///** @internal */
>> //template
>> //inline ::rtl::Allocator & __stl_alloc_rebind (::rtl::Allocator
>> & a, U const *)
>> //{
>> //return (::rtl::Allocator&)(a);
>> //}
>> //}
>>
>> in C:\source\aoo-trunk\main\sal\inc\rtl\allocator.hxx
>>
>
> So disabling that code fixed the namespace problem. Great!
>
> *The next problem is with undeclared identifiers:*
>> [...]
>>
>> C:/PROGRA~2/MICROS~1.0/VC/include\../../VC/include/unordered_set(64) :
>> error C2065: '_Hash_compare' : undeclared identifier
>>
>
> This looks like a known installation problem [1] for an sdk interacting
> badly with a feature pack. Ariel provided some great pointers in that
> mailing list thread that should solve the problem.
>
> [1] http://markmail.org/thread/ax5fq3iebmgc437k
>
> Herbert
>

Re: Checked out revision 1547453 Build problem on Windows 7

[Herbert Duerr]

On 09.12.2013 17:46, Vadim Yedzinovich wrote:

Hello Herbert,


Commented:
//namespace _STL
//{
///** @internal */
//template
//inline ::rtl::Allocator & __stl_alloc_rebind (::rtl::Allocator
& a, U const *)
//{
//return (::rtl::Allocator&)(a);
//}
//}

in C:\source\aoo-trunk\main\sal\inc\rtl\allocator.hxx


So disabling that code fixed the namespace problem. Great!


*The next problem is with undeclared identifiers:*
[...]
C:/PROGRA~2/MICROS~1.0/VC/include\../../VC/include/unordered_set(64) :
error C2065: '_Hash_compare' : undeclared identifier


This looks like a known installation problem [1] for an sdk interacting 
badly with a feature pack. Ariel provided some great pointers in that 
mailing list thread that should solve the problem.


[1] http://markmail.org/thread/ax5fq3iebmgc437k

Herbert

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Checked out revision 1547453 Build problem on Windows 7

[Vadim Yedzinovich]

Hello Herbert,


Commented:
//namespace _STL
//{
///** @internal */
//template
//inline ::rtl::Allocator & __stl_alloc_rebind (::rtl::Allocator
& a, U const *)
//{
//return (::rtl::Allocator&)(a);
//}
//}

in C:\source\aoo-trunk\main\sal\inc\rtl\allocator.hxx

*The next problem is with undeclared identifiers:*

Entering /cygdrive/c/source/aoo-trunk/main/sal/osl/all

Compiling: sal/osl/all/debugbase.cxx
C:/PROGRA~2/MICROS~1.0/VC/include\../../VC/include/unordered_set(64) :
error C2065: '_Hash_compare' : undeclared identifier

C:/PROGRA~2/MICROS~1.0/VC/include\../../VC/include/unordered_set(183)
: see reference to class template instantiation
'std::tr1::unordered_set<_Kty,_Hasher,_Keyeq,_Alloc>' being
compiled
C:/PROGRA~2/MICROS~1.0/VC/include\../../VC/include/unordered_set(64) :
error C2974: 'std::tr1::_Uset_traits' : invalid template
argument for '_Tr', type expected

C:/PROGRA~2/MICROS~1.0/VC/include\../../VC/include/unordered_set(20) :
see declaration of 'std::tr1::_Uset_traits'
C:/PROGRA~2/MICROS~1.0/VC/include\../../VC/include/unordered_set(64) :
error C2975: 'std::tr1::_Uset_traits' : invalid template
argument for '_Mfl', expected compile-time constant expression

C:/PROGRA~2/MICROS~1.0/VC/include\../../VC/include/unordered_set(20) :
see declaration of 'std::tr1::_Uset_traits'
C:/PROGRA~2/MICROS~1.0/VC/include\../../VC/include/unordered_set(64) :
error C2977: 'stdext::_Hash' : too many template arguments
C:/PROGRA~2/MICROS~1.0/VC/include\xhash(147) : see declaration of
'stdext::_Hash'
C:/PROGRA~2/MICROS~1.0/VC/include\../../VC/include/unordered_set(64) :
error C2955: 'stdext::_Hash' : use of class template requires
template argument list
C:/PROGRA~2/MICROS~1.0/VC/include\xhash(147) : see declaration of
'stdext::_Hash'
C:/PROGRA~2/MICROS~1.0/VC/include\../../VC/include/unordered_set(64) :
error C2143: syntax error : missing ',' before '>'
C:/PROGRA~2/MICROS~1.0/VC/include\../../VC/include/unordered_set(67) :
error C2143: syntax error : missing ';' before '<'
C:/PROGRA~2/MICROS~1.0/VC/include\../../VC/include/unordered_set(67) :
error C4430: missing type specifier - int assumed. Note: C++
does not support default-int
C:/PROGRA~2/MICROS~1.0/VC/include\../../VC/include/unordered_set(67) :
error C2238: unexpected token(s) preceding ';'
C:/PROGRA~2/MICROS~1.0/VC/include\../../VC/include/unordered_set(69) :
error C2065: '_Mytraits' : undeclared identifier
C:/PROGRA~2/MICROS~1.0/VC/include\../../VC/include/unordered_set(69) :
error C3203: '_Uset_traits' : unspecialized class template
can't be used as a template argument for template parameter
'_Traits', expected a real type
C:/PROGRA~2/MICROS~1.0/VC/include\../../VC/include/unordered_set(69) :
error C2955: 'std::tr1::_Uset_traits' : use of class template
requires template argument list

C:/PROGRA~2/MICROS~1.0/VC/include\../../VC/include/unordered_set(20) :
see declaration of 'std::tr1::_Uset_traits'
C:/PROGRA~2/MICROS~1.0/VC/include\../../VC/include/unordered_set(73) :
error C2146: syntax error : missing ';' before identifier
'key_compare'
C:/PROGRA~2/MICROS~1.0/VC/include\../../VC/include/unordered_set(73) :
error C4430: missing type specifier - int assumed. Note: C++
does not support default-int
C:/PROGRA~2/MICROS~1.0/VC/include\../../VC/include/unordered_set(73) :
error C2208: '_Hash<_Traits>::_Traits::key_compare' : no
members defined using this type
C:/PROGRA~2/MICROS~1.0/VC/include\../../VC/include/unordered_set(202) :
error C2065: '_Hash_compare' : undeclared identifier

C:/PROGRA~2/MICROS~1.0/VC/include\../../VC/include/unordered_set(339)
: see reference to class template instantiation
'std::tr1::unordered_multiset<_Kty,_Hasher,_Keyeq,_Alloc>'
being compiled
C:/PROGRA~2/MICROS~1.0/VC/include\../../VC/include/unordered_set(202) :
error C2974: 'std::tr1::_Uset_traits' : invalid template
argument for '_Tr', type expected

C:/PROGRA~2/MICROS~1.0/VC/include\../../VC/include/unordered_set(20) :
see declaration of 'std::tr1::_Uset_traits'
C:/PROGRA~2/MICROS~1.0/VC/include\../../VC/include/unordered_set(202) :
error C2975: 'std::tr1::_Uset_traits' : invalid template
argument for '_Mfl', expected compile-time constant expression

C:/PROGRA~2/MICROS~1.0/VC/include\../../VC/include/unordered_set(20) :
see declaration of 'std::tr1::_Uset_traits'
C:/PROGRA~2/MICROS~1.0/VC/include\../../VC/include/unordered_set(202) :
error C2977: 'stdext::_Hash' : too many template arguments
C:/PROGRA~2/MICROS~1.0/VC/include\xhash(147) : see declaration of
'stdext::_Hash'
C:/PROGRA~2/MICROS~1.0

Re: Checked out revision 1547453 Build problem on Windows 7

[Herbert Duerr]

Hello Vadim,

I'm replying on the mailing list, because this may be of interest to a 
wider audience.


On 06.12.2013 18:58, Vadim Yedzinovich wrote:

Get preprocess output to debugbase.i file (you can see it in attached
file)...


Got it, thanks!


As I can see basic_string comes from namespace std templates definitions
like:
  #line 13 "C:/PROGRA~2/MICROS~1.0/VC/include\\xstring"
namespace std {
[...]


The basic_strings being defined in the std namespace is fine. That's 
where it belongs so this is good.



namespace _STL comes from allocator.hxx:
#line 32 "../../inc\\rtl/allocator.hxx"
  namespace _STL
[...]


The _STL namespace is only mentioned at that one location, so I wonder 
how basic_string is now expected in that namespace?



[...]
Sorry, but a the monemt I've no idea how to resolve this problem.


The few lines mentioning _STL in allocator.hxx should be obsolete 
nowadays, anyway. Could you try out whether deleting them (the 
"namespace _STL" from start to closing and all that it encloses) helps?


Herbert

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Checked out revision 1547453 Build problem on Windows 7

[Herbert Duerr]

Hello Vadim,

On 06.12.2013 10:17, Vadim Yedzinovich wrote:

MSVS or SDK was not updated.


good.


I've perform dmake clean:
  /cygdrive/c/source/aoo-trunk/main
$ dmake clean

rm -rf */wntmsci12.pro 

rm -rf solver/*/wntmsci12.pro 

rm -rf ../ext_libraries/*/wntmsci12.pro 

echo cleaning up dmake...

cleaning up dmake...

make -C dmake clean

make: *** dmake: No such file or directory. Stop.

As recommend here: http://www.openoffice.org/tools/troubleshoot.html

Not sure if it is corresponding to 'clean build' that your recommend to
do...


That's as clean as it gets ;-)


Then get the latest version with SVN:

svn info


Better use "svn update" for updating, but for finding out what actual 
AOO version you got use "svn info|grep Rev:".



Pefrorm build instructions from step: Run autoconf to create the
configure script:
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#Windows_7
Start: Build --all
and have just the same problem with
C:\...oft Visual Studio 9.0\VC\include>xhash

So probably I still have old headers files somewhere around ...
Sorry, but I dont know what I need to do with MSVC's bitset header to
have correct definition for _STL namespace...


I'm afraid we have to check the preprocessed output of the problematic 
source file. Please find out how this file is compiled in your 
environment by cd'ing into the sal module directory and then run

build verbose=1 | grep debugbase.cxx
there. This will tell you the compiler command line for debugbase.cxx. 
Use this command line, but modify it using [1] to make the compilation 
stop after the preprocessor step. In short: you probably have to replace 
the -c option with the -E or the -P option.


[1] 
http://stackoverflow.com/questions/8978997/how-can-i-see-the-output-of-the-visual-c-preprocessor


Then look into the output of preprocessor and search in which namespace 
and where basic_string gets defined. Then look where the _STL define 
gets into the play and why it is expected later from the xhash header. 
This should help to find the root cause of the problem.


Hope that helps,
Herbert


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Checked out revision 1547453 Build problem on Windows 7

[Herbert Duerr]

Hi Vadim,

On 04.12.2013 11:27, Vadim Yedzinovich wrote:

$ svn co https://svn.apache.org/repos/asf/openoffice/trunk aoo-trunk
Receive AOO upgrade Checked out revision 1547453.


The AOO revision you probably got was 1547747. Subversion reporting it 
as 1547453 is an artifact from the "all projects share one big 
repository" philosophy at the ASF. Better use

"svn info | grep "Rev:"


[...]
Compiling: sal/osl/all/debugbase.cxx

C:/PROGRA~2/MICROS~1.0/VC/include\xhash(60) : error C2039: 'basic_string' :
is n ot a member of '_STL'


For some reason it expects basic_string in the _STL namespace. It most 
probably is available as std::basic_string (from MSVC's bitset header!).


The _STL namespace looks like a remnant of the old stlport4. Please 
start a clean build to make sure that no old header files are around.



It seems a problem with MS VS include module:
C:\...oft Visual Studio 9.0\VC\include>xhash

The last successful build was with AOO Checked out revision 1537066.


Did you happen to update MSVC or its SDKs? Does the older revision 
(which is actually 1537044) still build?



Could you please help me to understand what is wrong now?

Currently I'm not subscribed to the Development Mailing List, please put me
in CC in your Reply .


Done.

Herbert


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Checked out revision 1547453 Build problem on Windows 7

[Vadim Yedzinovich]

Hello,

Windows 7, Cygwin64 Terminal
With command:

$ svn co https://svn.apache.org/repos/asf/openoffice/trunk aoo-trunk
Receive AOO upgrade Checked out revision 1547453.


Try to rebuild it with command:

$ build --all

build -- version: 275224
Have error messages in sal module:

=

Building module sal

=

Entering /cygdrive/c/source/aoo-trunk/main/sal/inc

mkdir.exe -p ../wntmsci12.pro/slo/pch

precompiled_sal.cxx

mkdir.exe -p ../wntmsci12.pro/slo/pch_ex

precompiled_sal.cxx

Entering /cygdrive/c/source/aoo-trunk/main/sal/osl/all

Compiling: sal/osl/all/utility.cxx

Compiling: sal/osl/all/debugbase.cxx

C:/PROGRA~2/MICROS~1.0/VC/include\xhash(60) : error C2039: 'basic_string' :
is n ot a member of '_STL'

C:/PROGRA~2/MICROS~1.0/VC/include\xhash(60) : error C4430: missing type
specifie r - int assumed. Note: C++ does not support default-int

C:/PROGRA~2/MICROS~1.0/VC/include\xhash(60) : error C2143: syntax error :
missin g ',' before '<'

C:/PROGRA~2/MICROS~1.0/VC/include\xhash(887) : error C2143: syntax error :
missi ng ';' before '<'

C:/PROGRA~2/MICROS~1.0/VC/include\xhash(887) : error C2059: syntax error :
'<'

C:/PROGRA~2/MICROS~1.0/VC/include\xhash(887) : error C2065: '_Traits' :
undeclar ed identifier

C:/PROGRA~2/MICROS~1.0/VC/include\xhash(888) : error C2143: syntax error :
missi ng ';' before '{'

C:/PROGRA~2/MICROS~1.0/VC/include\xhash(888) : error C2447: '{' : missing
functi on header (old-style formal list?)
It seems a problem with MS VS include module:
C:\...oft Visual Studio 9.0\VC\include>xhash

The last successful build was with AOO Checked out revision 1537066.

Could you please help me to understand what is wrong now?

Currently I'm not subscribed to the Development Mailing List, please put me
in CC in your Reply .

Thank you,
Vadim.

Re: build problem...missing oox/source/token/tokens.hxx

[Kay Schenk]

On Fri, Jul 5, 2013 at 10:11 AM, Kay Schenk  wrote:

>
>
> On Fri, Jul 5, 2013 at 9:02 AM, Herbert Duerr  wrote:
>
>> On 05.07.2013 17:53, Kay Schenk wrote:
>>
>>> I'm trying to a build and seem to be missing  oox/source/token/tokens.hxx
>>>
>>> referenced in oox/prj/d.lst
>>>
>>> I seem to have oox/source/token/tokens.hxx.**head and
>>> oox/source/token/tokens.hxx.**tail
>>> but no oox/source/token/tokens.hxx.
>>>
>>> Can d.lst be fixed to use these or has tokens.hxx been removed or ???
>>>
>>
>> The tokens.hxx header seems to be a file generated by
>>   main/oox/source/token/token.pl
>> and
>>   main/oox/source/token/makefile**.mk 
>>
>
> hmmm...OK, this is a help. I didn't run into this last time about a month
> or so ago, so a surprise.
>

Oddly, I reconfigured to use my local C stdlibs and local python as I had
formerly done, and got past this issue. Now on to other issues. :/

Thanks again.



>
>
>
>>
>> I suggest to remove the output tree from the oox/module and then rebuild
>> that module. The name of that output tree depends on the platform (e.g.
>> wntmsci12* on Windows).
>>
>
> ok, thanks.
>
>
>>
>> Herbert
>>
>> --**--**-
>> To unsubscribe, e-mail: 
>> dev-unsubscribe@openoffice.**apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>>
>
>
> --
>
> -
> MzK
>
> "If you stick with a vision, it might not all work,
>  but some of it will be absolute genius."
>-- Kim Cattrall
>
>


-- 
-
MzK

"If you stick with a vision, it might not all work,
 but some of it will be absolute genius."
   -- Kim Cattrall

Re: build problem...missing oox/source/token/tokens.hxx

[Kay Schenk]

On Fri, Jul 5, 2013 at 9:02 AM, Herbert Duerr  wrote:

> On 05.07.2013 17:53, Kay Schenk wrote:
>
>> I'm trying to a build and seem to be missing  oox/source/token/tokens.hxx
>>
>> referenced in oox/prj/d.lst
>>
>> I seem to have oox/source/token/tokens.hxx.**head and
>> oox/source/token/tokens.hxx.**tail
>> but no oox/source/token/tokens.hxx.
>>
>> Can d.lst be fixed to use these or has tokens.hxx been removed or ???
>>
>
> The tokens.hxx header seems to be a file generated by
>   main/oox/source/token/token.pl
> and
>   main/oox/source/token/makefile**.mk 
>

hmmm...OK, this is a help. I didn't run into this last time about a month
or so ago, so a surprise.



>
> I suggest to remove the output tree from the oox/module and then rebuild
> that module. The name of that output tree depends on the platform (e.g.
> wntmsci12* on Windows).
>

ok, thanks.


>
> Herbert
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@openoffice.**apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


-- 
-
MzK

"If you stick with a vision, it might not all work,
 but some of it will be absolute genius."
   -- Kim Cattrall

Re: build problem...missing oox/source/token/tokens.hxx

[Herbert Duerr]

On 05.07.2013 17:53, Kay Schenk wrote:

I'm trying to a build and seem to be missing  oox/source/token/tokens.hxx

referenced in oox/prj/d.lst

I seem to have oox/source/token/tokens.hxx.head and
oox/source/token/tokens.hxx.tail
but no oox/source/token/tokens.hxx.

Can d.lst be fixed to use these or has tokens.hxx been removed or ???


The tokens.hxx header seems to be a file generated by
  main/oox/source/token/token.pl
and
  main/oox/source/token/makefile.mk

I suggest to remove the output tree from the oox/module and then rebuild 
that module. The name of that output tree depends on the platform (e.g. 
wntmsci12* on Windows).


Herbert

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

build problem...missing oox/source/token/tokens.hxx

[Kay Schenk]

I'm trying to a build and seem to be missing  oox/source/token/tokens.hxx

referenced in oox/prj/d.lst

I seem to have oox/source/token/tokens.hxx.head and
oox/source/token/tokens.hxx.tail
but no oox/source/token/tokens.hxx.

Can d.lst be fixed to use these or has tokens.hxx been removed or ???

-- 
-
MzK

"If you stick with a vision, it might not all work,
 but some of it will be absolute genius."
   -- Kim Cattrall

Re: Build problem on epm in the rejuvenate01 branche

[Raphael Bircher]

Am 31.05.13 08:59, schrieb Herbert Dürr:

Hi Raphael,

On 2013/05/30 8:27 PM, Raphael Bircher wrote:

Mac OS X 10.7 with XCode 4.3

My build stops at the epm modul. I know there is a workflow to find more
details about the breaker, but I fergot it :-( Can sameone help me?


Go into the module that had the problem and run
   build verbose=t
there.

Thanks Herbert. I fail over the wrong epm Link ;-)

Greetings Raphael



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Build problem on epm in the rejuvenate01 branche

[Herbert Dürr]

Hi Raphael,

On 2013/05/30 8:27 PM, Raphael Bircher wrote:

Mac OS X 10.7 with XCode 4.3

My build stops at the epm modul. I know there is a workflow to find more
details about the breaker, but I fergot it :-( Can sameone help me?


Go into the module that had the problem and run
   build verbose=t
there.

Herbert

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Build problem on epm in the rejuvenate01 branche

[Raphael Bircher]

Hi at all

Mac OS X 10.7 with XCode 4.3

My build stops at the epm modul. I know there is a workflow to find more 
details about the breaker, but I fergot it :-( Can sameone help me?


Thanks and greetings
Raphael

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [BUILD PROBLEM] Fail on JPropex build.xml line 122 \\ Error 65280

[Maarten Kesselaers]

Hi guys,

I have some problems building ( see below).
The guide I've used is the one at : 
http://wiki.openoffice.org/wiki/User:Dyrcona/LeopardBuild#flex

The output I get after the following command : build --from l10ntools -P4 
--dlv_switch -link  
is :
BUILD FAILED
/Users/maartenkesselaers/Documents/Projecten/aoo/main/l10ntools/java/jpropex/build.xml:122:
 Compile failed; see the compiler error output for details.

Total time: 3 seconds
dmake:  Error code 1, while making 'ANTBUILD'
Making:tralay
unx
-rwxr-xr-x  1 maartenkesselaers  staff  372972 Feb 16 12:47 
../unxmacxi.pro/bin/tralay
Making:all_tralay.dpobj
Compiling: l10ntools/source/help/HelpCompiler.cxx
Making:HelpLinker.lib
Compiling: l10ntools/source/help/HelpLinker.cxx
Compiling: l10ntools/source/help/HelpCompiler.cxx
Making:HelpLinker.lib
Making:libhelplinker.dylib
/Users/maartenkesselaers/Documents/Projecten/aoo/main/solenv/bin/checkdll.sh 
-L../../unxmacxi.pro/lib 
-L/Users/maartenkesselaers/Documents/Projecten/aoo/main/solver/400/unxmacxi.pro/lib
  ../../unxmacxi.pro/lib/libhelplinker.dylib
Checking DLL ../../unxmacxi.pro/lib/libhelplinker.dylib ...: ok
Making:HelpLinker
unx
-rwxr-xr-x  1 maartenkesselaers  staff  270820 Feb 16 12:47 
../../unxmacxi.pro/bin/HelpLinker
zip warning: ../HelpIndexerTool.jar not found or empty
  adding: META-INF/MANIFEST.MF (deflated 11%)
  adding: com/sun/star/help/HelpFileDocument.class (deflated 51%)
  adding: com/sun/star/help/HelpIndexerTool.class (deflated 47%)
Making:all_HelpLinker.dpslo
Making:all_HelpLinker.dpobj

1 module(s): 
l10ntools
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making 
/Users/maartenkesselaers/Documents/Projecten/aoo/main/l10ntools/java/jpropex

When you have fixed the errors in that module you can resume the build by 
running:

build --from l10ntools

Any ideas?

Thanks a lot,
Regards,
Maarten

Op 15-feb-2013, om 17:18 heeft Maarten Kesselaers het volgende geschreven:

> I'm building the total source in the terminal, not with Eclipse.
> The building guide that I used was the normal one for Mac OS X Snow Leopard.
> I haven't changed any classpath in my Java build env.
> 
> Regards,
> Maarten
> 
> Op 15-feb.-2013 09:32 schreef "Jürgen Schmidt"  het 
> volgende:
> On 2/15/13 7:00 AM, Maarten Kesselaers wrote:
> > I have full working eclipse env and try to build on Mac OS X 10.6.
> > All prerequisits are installed as described in the guide.
> 
> l10tools is normally build as all other modules in a command line
> environment triggered via makefiles. I am not aware that anybody has
> build it in eclipse.
> 
> Which guide, do you mean the normal building guide? Have you configured
> the build env? If yes tweak the build.xml and print out the classpath to
> see what you need inside Eclipse.
> 
> Juergen
> 
> 
> >
> > Thanks,
> > Maarten
> > Op 14-feb.-2013 09:33 schreef "Jürgen Schmidt"  het
> > volgende:
> >
> >> On 2/13/13 10:27 PM, Maarten Kesselaers wrote:
> >>> My build just crashed on the build.xml under
> >>> ./main/l10ntools/java/jpropex/ at line 122 :
> >>>
> >>> 122classpathref="classpath">
> >>>
> >>> So I guess I need to set a CLASSPATH, right?
> >>> To which directory should it be set?
> >>>
> >>
> >> do you have configured a working build env with Java? If no please try
> >> to do that first. You don't have to tweak classpath settings manually,
> >> everything should be fine with working and well configured build env.
> >>
> >> On which platform are you building?
> >>
> >> Juergen
> >>
> >>
> >>
> >
> 

Re: [BUILD PROBLEM] Fail on JPropex build.xml line 122 \\ Error 65280

[Maarten Kesselaers]

I'm building the total source in the terminal, not with Eclipse.
The building guide that I used was the normal one for Mac OS X Snow Leopard.
I haven't changed any classpath in my Java build env.

Regards,
Maarten
Op 15-feb.-2013 09:32 schreef "Jürgen Schmidt"  het
volgende:

> On 2/15/13 7:00 AM, Maarten Kesselaers wrote:
> > I have full working eclipse env and try to build on Mac OS X 10.6.
> > All prerequisits are installed as described in the guide.
>
> l10tools is normally build as all other modules in a command line
> environment triggered via makefiles. I am not aware that anybody has
> build it in eclipse.
>
> Which guide, do you mean the normal building guide? Have you configured
> the build env? If yes tweak the build.xml and print out the classpath to
> see what you need inside Eclipse.
>
> Juergen
>
>
> >
> > Thanks,
> > Maarten
> > Op 14-feb.-2013 09:33 schreef "Jürgen Schmidt" 
> het
> > volgende:
> >
> >> On 2/13/13 10:27 PM, Maarten Kesselaers wrote:
> >>> My build just crashed on the build.xml under
> >>> ./main/l10ntools/java/jpropex/ at line 122 :
> >>>
> >>> 122classpathref="classpath">
> >>>
> >>> So I guess I need to set a CLASSPATH, right?
> >>> To which directory should it be set?
> >>>
> >>
> >> do you have configured a working build env with Java? If no please try
> >> to do that first. You don't have to tweak classpath settings manually,
> >> everything should be fine with working and well configured build env.
> >>
> >> On which platform are you building?
> >>
> >> Juergen
> >>
> >>
> >>
> >
>
>

Re: [BUILD PROBLEM] Fail on JPropex build.xml line 122 \\ Error 65280

[Jürgen Schmidt]

On 2/15/13 7:00 AM, Maarten Kesselaers wrote:
> I have full working eclipse env and try to build on Mac OS X 10.6.
> All prerequisits are installed as described in the guide.

l10tools is normally build as all other modules in a command line
environment triggered via makefiles. I am not aware that anybody has
build it in eclipse.

Which guide, do you mean the normal building guide? Have you configured
the build env? If yes tweak the build.xml and print out the classpath to
see what you need inside Eclipse.

Juergen


> 
> Thanks,
> Maarten
> Op 14-feb.-2013 09:33 schreef "Jürgen Schmidt"  het
> volgende:
> 
>> On 2/13/13 10:27 PM, Maarten Kesselaers wrote:
>>> My build just crashed on the build.xml under
>>> ./main/l10ntools/java/jpropex/ at line 122 :
>>>
>>> 122classpathref="classpath">
>>>
>>> So I guess I need to set a CLASSPATH, right?
>>> To which directory should it be set?
>>>
>>
>> do you have configured a working build env with Java? If no please try
>> to do that first. You don't have to tweak classpath settings manually,
>> everything should be fine with working and well configured build env.
>>
>> On which platform are you building?
>>
>> Juergen
>>
>>
>>
> 

Re: [BUILD PROBLEM] Fail on JPropex build.xml line 122 \\ Error 65280

[Maarten Kesselaers]

I have full working eclipse env and try to build on Mac OS X 10.6.
All prerequisits are installed as described in the guide.

Thanks,
Maarten
Op 14-feb.-2013 09:33 schreef "Jürgen Schmidt"  het
volgende:

> On 2/13/13 10:27 PM, Maarten Kesselaers wrote:
> > My build just crashed on the build.xml under
> > ./main/l10ntools/java/jpropex/ at line 122 :
> >
> > 122classpathref="classpath">
> >
> > So I guess I need to set a CLASSPATH, right?
> > To which directory should it be set?
> >
>
> do you have configured a working build env with Java? If no please try
> to do that first. You don't have to tweak classpath settings manually,
> everything should be fine with working and well configured build env.
>
> On which platform are you building?
>
> Juergen
>
>
>

Re: [BUILD PROBLEM] Fail on JPropex build.xml line 122 \\ Error 65280

[Jürgen Schmidt]

On 2/13/13 10:27 PM, Maarten Kesselaers wrote:
> My build just crashed on the build.xml under
> ./main/l10ntools/java/jpropex/ at line 122 :
> 
> 122classpathref="classpath">
> 
> So I guess I need to set a CLASSPATH, right?
> To which directory should it be set?
> 

do you have configured a working build env with Java? If no please try
to do that first. You don't have to tweak classpath settings manually,
everything should be fine with working and well configured build env.

On which platform are you building?

Juergen

[BUILD PROBLEM] Fail on JPropex build.xml line 122 \\ Error 65280

[Maarten Kesselaers]

My build just crashed on the build.xml under
./main/l10ntools/java/jpropex/ at line 122 :

122classpathref="classpath">

So I guess I need to set a CLASSPATH, right?
To which directory should it be set?

Thanks for your help,
Regards,
Maarten

Re: Re: Re: Re: build problem

[Fan Zheng]

Welcome!

2013/1/21 2 

> Fan Zheng，
>  I'm so sorry for missing your reply because of my job. I have
> finished the building with your help.
> Thank you!
>
> Yi
> At 2013-01-11 15:07:44,"Fan Zheng"  wrote:
> >Seems your cygwin did not to be allow to use system api to create process.
> >Did you use some kind of anti-virus application like Symantec EndPoint
> >Protection? If yes, you may need to install a newly version with certain
> >verification for cygwin.
> >
> >BTW, the method you executed last one "make -sr" will give a release build
> >without the debug information. try "make -sr debug=true" please.
> >
> >
> >2013/1/10 2 
> >
> >> After my step 2, I go to sw and run "build debug=true", but it didn'i
> >> work. I got the message:
> >>  >/cygdrive/d/aoo/main/sw
> >> >$ build debug=true
> >> cygwin warning:
> >>   MS-DOS style path detected: D:/aoo/main/solenv/bin/build.pl
> >>   Preferred POSIX equivalent is: /cygdrive/d/aoo/main/solenv/bin/
> build.pl
> >>   CYGWIN environment variable option "nodosfilewarning" turns off this
> >> warning.
> >>   Consult the user's guide for more details about POSIX paths:
> >> http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
> >> build -- version: 275224
> >> This module has been migrated to GNU make.
> >> You can only use build --all/--since here with build.pl.
> >> To do the equivalent of 'build && deliver' call:
> >> make -sr
> >> in the module root (This will modify the solver).
> >>
> >> >/cygdrive/d/aoo/main/sw
> >> >$ make -sr
> >>   2 [main] sh 2720 fork: child -1 - CreateProcessW failed for
> >> 'C:\cygwin\bin\sh.exe', errno 13
> >> /bin/sh: fork: Permission denied
> >> D:/aoo/main/solenv/gbuild/AllLangResTarget.mk:91: recipe for target
> >> `/cygdrive/d/aoo/main/solver/341/
> >> wntmsci12.pro/workdir/Dep/SrsPartTarget/sw/source/ui/index/idxmrk.src.d
> '
> >> failed
> >> make: *** [/cygdrive/d/aoo/main/solver/341/
> >> wntmsci12.pro/workdir/Dep/SrsPartTarget/sw/source/ui/index/idxmrk.src.d
> ]
> >> Error 254
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> At 2013-01-10 11:07:51,chengjh  wrote:
> >> >I am not sure your step 4,5,6...After your step 2, you can go to sw
> module
> >> >and run "build debug=true" to do individual build with debug info once
> you
> >> >have done modifications in sw module,and then you will find
> >> >that breakpoints can be added to your modified files after the new
> built
> >> >dlls at ..\main\solver\350\wntmsci12.pro\workdir\LinkTarget\Library
> are
> >> >copied and pasted to your installation directory,such as
> >> >D:\OO34\Basis\program\...
> >> >
> >> >On Thu, Jan 10, 2013 at 10:43 AM, 2  wrote:
> >> >
> >> >> Hi,
> >> >> I have found the dlls in solver folder, but I was another
> >> problem,
> >> >> when build sw with debug information, but I couldn't found the dlls
> with
> >> >> debug infomation, where are them?
> >> >> there are the command I input in cygwin:
> >> >> 1.cd main
> >> >> 2.source winenv.Set.sh
> >> >> 4.cd instsetoo_native
> >> >> 5.build --from sw --prepare # removes old output trees and solver
> >> >> 6.build debug=true --from sw
> >> >>
> >> >> Yi
> >> >>
> >> >>
> >> >> At 2013-01-09 16:32:46,chengjh  wrote:
> >> >> >Sure,the compiled object files can be found at ..\main\solver\350\
> >> >> >wntmsci12.pro\workdir\CxxObject\sw\.,and dlls can be got
> >> >> >from ..\main\solver\350\wntmsci12.pro
> >> \workdir\LinkTarget\Library..Thanks.
> >> >> >
> >> >> >On Wed, Jan 9, 2013 at 3:52 PM, Herbert Duerr 
> wrote:
> >> >> >
> >> >> >> On 09.01.2013 08:06, 2 wrote:
> >> >> >>
> >> >> >>>  when got my own build, I couldn't found the filefolder
> >> >> wntmsci12.proin sw module which be found in sc module, could it be
> said
> >> >> that my build
> >> >> >>> failed ?
> >> >> >>>
> >> >> >>
> >> >> >> That is no problem: The sw module has been converted to gbuild, so
> >> that
> >> >> >> the files are now in main/solver/350/wntmsci12.pro instead of the
> >> >> modules
> >> >> >> wntmsci12.pro folder.
> >> >> >>
> >> >> >> Herbert
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> >--
> >> >> >
> >> >> >Best Regards,Jianhong Cheng
> >> >>
> >> >
> >> >
> >> >
> >> >--
> >> >
> >> >Best Regards,Jianhong Cheng
> >>
>

Re:Re: Re: Re: build problem

[2]

Fan Zheng，
 I'm so sorry for missing your reply because of my job. I have finished 
the building with your help.
Thank you!
 
Yi
At 2013-01-11 15:07:44,"Fan Zheng"  wrote:
>Seems your cygwin did not to be allow to use system api to create process.
>Did you use some kind of anti-virus application like Symantec EndPoint
>Protection? If yes, you may need to install a newly version with certain
>verification for cygwin.
>
>BTW, the method you executed last one "make -sr" will give a release build
>without the debug information. try "make -sr debug=true" please.
>
>
>2013/1/10 2 
>
>> After my step 2, I go to sw and run "build debug=true", but it didn'i
>> work. I got the message:
>>  >/cygdrive/d/aoo/main/sw
>> >$ build debug=true
>> cygwin warning:
>>   MS-DOS style path detected: D:/aoo/main/solenv/bin/build.pl
>>   Preferred POSIX equivalent is: /cygdrive/d/aoo/main/solenv/bin/build.pl
>>   CYGWIN environment variable option "nodosfilewarning" turns off this
>> warning.
>>   Consult the user's guide for more details about POSIX paths:
>> http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
>> build -- version: 275224
>> This module has been migrated to GNU make.
>> You can only use build --all/--since here with build.pl.
>> To do the equivalent of 'build && deliver' call:
>> make -sr
>> in the module root (This will modify the solver).
>>
>> >/cygdrive/d/aoo/main/sw
>> >$ make -sr
>>   2 [main] sh 2720 fork: child -1 - CreateProcessW failed for
>> 'C:\cygwin\bin\sh.exe', errno 13
>> /bin/sh: fork: Permission denied
>> D:/aoo/main/solenv/gbuild/AllLangResTarget.mk:91: recipe for target
>> `/cygdrive/d/aoo/main/solver/341/
>> wntmsci12.pro/workdir/Dep/SrsPartTarget/sw/source/ui/index/idxmrk.src.d'
>> failed
>> make: *** [/cygdrive/d/aoo/main/solver/341/
>> wntmsci12.pro/workdir/Dep/SrsPartTarget/sw/source/ui/index/idxmrk.src.d]
>> Error 254
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> At 2013-01-10 11:07:51,chengjh  wrote:
>> >I am not sure your step 4,5,6...After your step 2, you can go to sw module
>> >and run "build debug=true" to do individual build with debug info once you
>> >have done modifications in sw module,and then you will find
>> >that breakpoints can be added to your modified files after the new built
>> >dlls at ..\main\solver\350\wntmsci12.pro\workdir\LinkTarget\Library are
>> >copied and pasted to your installation directory,such as
>> >D:\OO34\Basis\program\...
>> >
>> >On Thu, Jan 10, 2013 at 10:43 AM, 2  wrote:
>> >
>> >> Hi,
>> >> I have found the dlls in solver folder, but I was another
>> problem,
>> >> when build sw with debug information, but I couldn't found the dlls with
>> >> debug infomation, where are them?
>> >> there are the command I input in cygwin:
>> >> 1.cd main
>> >> 2.source winenv.Set.sh
>> >> 4.cd instsetoo_native
>> >> 5.build --from sw --prepare # removes old output trees and solver
>> >> 6.build debug=true --from sw
>> >>
>> >> Yi
>> >>
>> >>
>> >> At 2013-01-09 16:32:46,chengjh  wrote:
>> >> >Sure,the compiled object files can be found at ..\main\solver\350\
>> >> >wntmsci12.pro\workdir\CxxObject\sw\.,and dlls can be got
>> >> >from ..\main\solver\350\wntmsci12.pro
>> \workdir\LinkTarget\Library..Thanks.
>> >> >
>> >> >On Wed, Jan 9, 2013 at 3:52 PM, Herbert Duerr  wrote:
>> >> >
>> >> >> On 09.01.2013 08:06, 2 wrote:
>> >> >>
>> >> >>>  when got my own build, I couldn't found the filefolder
>> >> wntmsci12.proin sw module which be found in sc module, could it be said
>> >> that my build
>> >> >>> failed ?
>> >> >>>
>> >> >>
>> >> >> That is no problem: The sw module has been converted to gbuild, so
>> that
>> >> >> the files are now in main/solver/350/wntmsci12.pro instead of the
>> >> modules
>> >> >> wntmsci12.pro folder.
>> >> >>
>> >> >> Herbert
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> >--
>> >> >
>> >> >Best Regards,Jianhong Cheng
>> >>
>> >
>> >
>> >
>> >--
>> >
>> >Best Regards,Jianhong Cheng
>>

Re: Re: Re: build problem

[Fan Zheng]

Seems your cygwin did not to be allow to use system api to create process.
Did you use some kind of anti-virus application like Symantec EndPoint
Protection? If yes, you may need to install a newly version with certain
verification for cygwin.

BTW, the method you executed last one "make -sr" will give a release build
without the debug information. try "make -sr debug=true" please.


2013/1/10 2 

> After my step 2, I go to sw and run "build debug=true", but it didn'i
> work. I got the message:
>  >/cygdrive/d/aoo/main/sw
> >$ build debug=true
> cygwin warning:
>   MS-DOS style path detected: D:/aoo/main/solenv/bin/build.pl
>   Preferred POSIX equivalent is: /cygdrive/d/aoo/main/solenv/bin/build.pl
>   CYGWIN environment variable option "nodosfilewarning" turns off this
> warning.
>   Consult the user's guide for more details about POSIX paths:
> http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
> build -- version: 275224
> This module has been migrated to GNU make.
> You can only use build --all/--since here with build.pl.
> To do the equivalent of 'build && deliver' call:
> make -sr
> in the module root (This will modify the solver).
>
> >/cygdrive/d/aoo/main/sw
> >$ make -sr
>   2 [main] sh 2720 fork: child -1 - CreateProcessW failed for
> 'C:\cygwin\bin\sh.exe', errno 13
> /bin/sh: fork: Permission denied
> D:/aoo/main/solenv/gbuild/AllLangResTarget.mk:91: recipe for target
> `/cygdrive/d/aoo/main/solver/341/
> wntmsci12.pro/workdir/Dep/SrsPartTarget/sw/source/ui/index/idxmrk.src.d'
> failed
> make: *** [/cygdrive/d/aoo/main/solver/341/
> wntmsci12.pro/workdir/Dep/SrsPartTarget/sw/source/ui/index/idxmrk.src.d]
> Error 254
>
>
>
>
>
>
>
>
>
> At 2013-01-10 11:07:51,chengjh  wrote:
> >I am not sure your step 4,5,6...After your step 2, you can go to sw module
> >and run "build debug=true" to do individual build with debug info once you
> >have done modifications in sw module,and then you will find
> >that breakpoints can be added to your modified files after the new built
> >dlls at ..\main\solver\350\wntmsci12.pro\workdir\LinkTarget\Library are
> >copied and pasted to your installation directory,such as
> >D:\OO34\Basis\program\...
> >
> >On Thu, Jan 10, 2013 at 10:43 AM, 2  wrote:
> >
> >> Hi,
> >> I have found the dlls in solver folder, but I was another
> problem,
> >> when build sw with debug information, but I couldn't found the dlls with
> >> debug infomation, where are them?
> >> there are the command I input in cygwin:
> >> 1.cd main
> >> 2.source winenv.Set.sh
> >> 4.cd instsetoo_native
> >> 5.build --from sw --prepare # removes old output trees and solver
> >> 6.build debug=true --from sw
> >>
> >> Yi
> >>
> >>
> >> At 2013-01-09 16:32:46,chengjh  wrote:
> >> >Sure,the compiled object files can be found at ..\main\solver\350\
> >> >wntmsci12.pro\workdir\CxxObject\sw\.,and dlls can be got
> >> >from ..\main\solver\350\wntmsci12.pro
> \workdir\LinkTarget\Library..Thanks.
> >> >
> >> >On Wed, Jan 9, 2013 at 3:52 PM, Herbert Duerr  wrote:
> >> >
> >> >> On 09.01.2013 08:06, 2 wrote:
> >> >>
> >> >>>  when got my own build, I couldn't found the filefolder
> >> wntmsci12.proin sw module which be found in sc module, could it be said
> >> that my build
> >> >>> failed ?
> >> >>>
> >> >>
> >> >> That is no problem: The sw module has been converted to gbuild, so
> that
> >> >> the files are now in main/solver/350/wntmsci12.pro instead of the
> >> modules
> >> >> wntmsci12.pro folder.
> >> >>
> >> >> Herbert
> >> >>
> >> >
> >> >
> >> >
> >> >--
> >> >
> >> >Best Regards,Jianhong Cheng
> >>
> >
> >
> >
> >--
> >
> >Best Regards,Jianhong Cheng
>

Re:Re: Re: build problem

[2]

After my step 2, I go to sw and run "build debug=true", but it didn'i work. I 
got the message:
 >/cygdrive/d/aoo/main/sw
>$ build debug=true
cygwin warning:
  MS-DOS style path detected: D:/aoo/main/solenv/bin/build.pl
  Preferred POSIX equivalent is: /cygdrive/d/aoo/main/solenv/bin/build.pl
  CYGWIN environment variable option "nodosfilewarning" turns off this warning.
  Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
build -- version: 275224
This module has been migrated to GNU make.
You can only use build --all/--since here with build.pl.
To do the equivalent of 'build && deliver' call:
make -sr
in the module root (This will modify the solver).

>/cygdrive/d/aoo/main/sw
>$ make -sr
  2 [main] sh 2720 fork: child -1 - CreateProcessW failed for 
'C:\cygwin\bin\sh.exe', errno 13
/bin/sh: fork: Permission denied
D:/aoo/main/solenv/gbuild/AllLangResTarget.mk:91: recipe for target 
`/cygdrive/d/aoo/main/solver/341/wntmsci12.pro/workdir/Dep/SrsPartTarget/sw/source/ui/index/idxmrk.src.d'
 failed
make: *** 
[/cygdrive/d/aoo/main/solver/341/wntmsci12.pro/workdir/Dep/SrsPartTarget/sw/source/ui/index/idxmrk.src.d]
 Error 254









At 2013-01-10 11:07:51,chengjh  wrote:
>I am not sure your step 4,5,6...After your step 2, you can go to sw module
>and run "build debug=true" to do individual build with debug info once you
>have done modifications in sw module,and then you will find
>that breakpoints can be added to your modified files after the new built
>dlls at ..\main\solver\350\wntmsci12.pro\workdir\LinkTarget\Library are
>copied and pasted to your installation directory,such as
>D:\OO34\Basis\program\...
>
>On Thu, Jan 10, 2013 at 10:43 AM, 2  wrote:
>
>> Hi,
>> I have found the dlls in solver folder, but I was another problem,
>> when build sw with debug information, but I couldn't found the dlls with
>> debug infomation, where are them?
>> there are the command I input in cygwin:
>> 1.cd main
>> 2.source winenv.Set.sh
>> 4.cd instsetoo_native
>> 5.build --from sw --prepare # removes old output trees and solver
>> 6.build debug=true --from sw
>>
>> Yi
>>
>>
>> At 2013-01-09 16:32:46,chengjh  wrote:
>> >Sure,the compiled object files can be found at ..\main\solver\350\
>> >wntmsci12.pro\workdir\CxxObject\sw\.,and dlls can be got
>> >from ..\main\solver\350\wntmsci12.pro\workdir\LinkTarget\Library..Thanks.
>> >
>> >On Wed, Jan 9, 2013 at 3:52 PM, Herbert Duerr  wrote:
>> >
>> >> On 09.01.2013 08:06, 2 wrote:
>> >>
>> >>>  when got my own build, I couldn't found the filefolder
>> wntmsci12.proin sw module which be found in sc module, could it be said
>> that my build
>> >>> failed ?
>> >>>
>> >>
>> >> That is no problem: The sw module has been converted to gbuild, so that
>> >> the files are now in main/solver/350/wntmsci12.pro instead of the
>> modules
>> >> wntmsci12.pro folder.
>> >>
>> >> Herbert
>> >>
>> >
>> >
>> >
>> >--
>> >
>> >Best Regards,Jianhong Cheng
>>
>
>
>
>-- 
>
>Best Regards,Jianhong Cheng

Re: Re: build problem

[chengjh]

I am not sure your step 4,5,6...After your step 2, you can go to sw module
and run "build debug=true" to do individual build with debug info once you
have done modifications in sw module,and then you will find
that breakpoints can be added to your modified files after the new built
dlls at ..\main\solver\350\wntmsci12.pro\workdir\LinkTarget\Library are
copied and pasted to your installation directory,such as
D:\OO34\Basis\program\...

On Thu, Jan 10, 2013 at 10:43 AM, 2  wrote:

> Hi,
> I have found the dlls in solver folder, but I was another problem,
> when build sw with debug information, but I couldn't found the dlls with
> debug infomation, where are them?
> there are the command I input in cygwin:
> 1.cd main
> 2.source winenv.Set.sh
> 4.cd instsetoo_native
> 5.build --from sw --prepare # removes old output trees and solver
> 6.build debug=true --from sw
>
> Yi
>
>
> At 2013-01-09 16:32:46,chengjh  wrote:
> >Sure,the compiled object files can be found at ..\main\solver\350\
> >wntmsci12.pro\workdir\CxxObject\sw\.,and dlls can be got
> >from ..\main\solver\350\wntmsci12.pro\workdir\LinkTarget\Library..Thanks.
> >
> >On Wed, Jan 9, 2013 at 3:52 PM, Herbert Duerr  wrote:
> >
> >> On 09.01.2013 08:06, 2 wrote:
> >>
> >>>  when got my own build, I couldn't found the filefolder
> wntmsci12.proin sw module which be found in sc module, could it be said
> that my build
> >>> failed ?
> >>>
> >>
> >> That is no problem: The sw module has been converted to gbuild, so that
> >> the files are now in main/solver/350/wntmsci12.pro instead of the
> modules
> >> wntmsci12.pro folder.
> >>
> >> Herbert
> >>
> >
> >
> >
> >--
> >
> >Best Regards,Jianhong Cheng
>



-- 

Best Regards,Jianhong Cheng

Re:Re: build problem

[2]

Hi,
I have found the dlls in solver folder, but I was another problem, when 
build sw with debug information, but I couldn't found the dlls with debug 
infomation, where are them?
there are the command I input in cygwin:   
1.cd main
2.source winenv.Set.sh
4.cd instsetoo_native
5.build --from sw --prepare # removes old output trees and solver
6.build debug=true --from sw

Yi


At 2013-01-09 16:32:46,chengjh  wrote:
>Sure,the compiled object files can be found at ..\main\solver\350\
>wntmsci12.pro\workdir\CxxObject\sw\.,and dlls can be got
>from ..\main\solver\350\wntmsci12.pro\workdir\LinkTarget\Library..Thanks.
>
>On Wed, Jan 9, 2013 at 3:52 PM, Herbert Duerr  wrote:
>
>> On 09.01.2013 08:06, 2 wrote:
>>
>>>  when got my own build, I couldn't found the filefolder wntmsci12.proin 
>>> sw module which be found in sc module, could it be said that my build
>>> failed ?
>>>
>>
>> That is no problem: The sw module has been converted to gbuild, so that
>> the files are now in main/solver/350/wntmsci12.pro instead of the modules
>> wntmsci12.pro folder.
>>
>> Herbert
>>
>
>
>
>-- 
>
>Best Regards,Jianhong Cheng

Re:Re: build problem

[2]

Hi Jianhong Cheng,
 Thank you, I got it.
 
Yi


At 2013-01-09 16:32:46,chengjh  wrote:
>Sure,the compiled object files can be found at ..\main\solver\350\
>wntmsci12.pro\workdir\CxxObject\sw\.,and dlls can be got
>from ..\main\solver\350\wntmsci12.pro\workdir\LinkTarget\Library..Thanks.
>
>On Wed, Jan 9, 2013 at 3:52 PM, Herbert Duerr  wrote:
>
>> On 09.01.2013 08:06, 2 wrote:
>>
>>>  when got my own build, I couldn't found the filefolder wntmsci12.proin 
>>> sw module which be found in sc module, could it be said that my build
>>> failed ?
>>>
>>
>> That is no problem: The sw module has been converted to gbuild, so that
>> the files are now in main/solver/350/wntmsci12.pro instead of the modules
>> wntmsci12.pro folder.
>>
>> Herbert
>>
>
>
>
>-- 
>
>Best Regards,Jianhong Cheng

Re:Re: build problem

[2]

Herbert,
 Thank you! I gain a lot from you


At 2013-01-09 15:52:47,"Herbert Duerr"  wrote:
>On 09.01.2013 08:06, 2 wrote:
>>  when got my own build, I couldn't found the filefolder wntmsci12.pro in 
>> sw module which be found in sc module, could it be said that my build failed 
>> ?
>
>That is no problem: The sw module has been converted to gbuild, so that 
>the files are now in main/solver/350/wntmsci12.pro instead of the 
>modules wntmsci12.pro folder.
>
>Herbert

Re: build problem

[chengjh]

Sure,the compiled object files can be found at ..\main\solver\350\
wntmsci12.pro\workdir\CxxObject\sw\.,and dlls can be got
from ..\main\solver\350\wntmsci12.pro\workdir\LinkTarget\Library..Thanks.

On Wed, Jan 9, 2013 at 3:52 PM, Herbert Duerr  wrote:

> On 09.01.2013 08:06, 2 wrote:
>
>>  when got my own build, I couldn't found the filefolder wntmsci12.proin 
>> sw module which be found in sc module, could it be said that my build
>> failed ?
>>
>
> That is no problem: The sw module has been converted to gbuild, so that
> the files are now in main/solver/350/wntmsci12.pro instead of the modules
> wntmsci12.pro folder.
>
> Herbert
>



-- 

Best Regards,Jianhong Cheng

Re: build problem

[Herbert Duerr]

On 09.01.2013 08:06, 2 wrote:

 when got my own build, I couldn't found the filefolder wntmsci12.pro in sw 
module which be found in sc module, could it be said that my build failed ?


That is no problem: The sw module has been converted to gbuild, so that 
the files are now in main/solver/350/wntmsci12.pro instead of the 
modules wntmsci12.pro folder.


Herbert

build problem

[2]

Hi,
when got my own build, I couldn't found the filefolder wntmsci12.pro in sw 
module which be found in sc module, could it be said that my build failed ?

Yi