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 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)

[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 21 | 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 (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 21 | 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

[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 21 | 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

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 -j1make -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: 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 21 | 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 -j1make -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

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 21 | 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 21 | 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 -j1make -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

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 21 | 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 -j1make -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

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\rtlallocator.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:UserLoginreturnto=Main+Pagetype=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 h...@apache.org

 On 09.12.2013 17:46, Vadim Yedzinovich wrote:

 Hello Herbert,


 Commented:
 //namespace _STL
 //{
 ///** @internal */
 //templateclass T, class U
 //inline ::rtl::AllocatorU  __stl_alloc_rebind (::rtl::AllocatorT
  a, U const *)
 //{
 //return (::rtl::AllocatorU)(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 */
//templateclass T, class U
//inline ::rtl::AllocatorU  __stl_alloc_rebind (::rtl::AllocatorT
 a, U const *)
//{
//return (::rtl::AllocatorU)(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

[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

[Vadim Yedzinovich]

Hello Herbert,


Commented:
//namespace _STL
//{
///** @internal */
//templateclass T, class U
//inline ::rtl::AllocatorU  __stl_alloc_rebind (::rtl::AllocatorT
 a, U const *)
//{
//return (::rtl::AllocatorU)(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'

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 http://wntmsci12.pro

rm -rf solver/*/wntmsci12.pro http://wntmsci12.pro

rm -rf ../ext_libraries/*/wntmsci12.pro http://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
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\includexhash

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\includexhash

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\includexhash

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 kay.sch...@gmail.com wrote:



 On Fri, Jul 5, 2013 at 9:02 AM, Herbert Duerr h...@apache.org 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 http://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.orgdev-unsubscr...@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

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...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

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

[Kay Schenk]

On Fri, Jul 5, 2013 at 9:02 AM, Herbert Duerr h...@apache.org 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 http://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.orgdev-unsubscr...@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 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 jogischm...@gmail.com 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 jogischm...@gmail.com 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 jogischm...@gmail.com 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 jogischm...@gmail.com 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 jogischm...@gmail.com
 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

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 jogischm...@gmail.com 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

[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

[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 zheng.easy...@gmail.com 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 laoyi...@126.com

 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 chen...@apache.org 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 laoyi...@126.com 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 chen...@apache.org 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 h...@apache.org 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

[Fan Zheng]

Welcome!

2013/1/21 2 laoyi...@126.com

 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 zheng.easy...@gmail.com 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 laoyi...@126.com
 
  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 chen...@apache.org 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 laoyi...@126.com 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 chen...@apache.org 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 h...@apache.org
 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]

Herbert,
 Thank you! I gain a lot from you


At 2013-01-09 15:52:47,Herbert Duerr h...@apache.org 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:Re: build problem

[2]

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


At 2013-01-09 16:32:46,chengjh chen...@apache.org 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 h...@apache.org 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,
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 chen...@apache.org 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 h...@apache.org 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

[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 laoyi...@126.com 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 chen...@apache.org 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 h...@apache.org 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 chen...@apache.org 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 laoyi...@126.com 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 chen...@apache.org 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 h...@apache.org 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: 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