Let me summarize what tono(takashi ono) has done:

Working on 1.1rc4 with mingw+tcsh he has built several modules up to xmlhelp. 
He may want to tell us here exactly what modules he has built and the system and
tools which he used.

Let me show you what he has found so far.

1) berkeleydb, one of the external projects, can't be used properly by clients.

2) MinGW's bintool has got a bug with --enable-runtime-pseudo-reloc. To
workaround this, bintool has to be patched and rebuilt.

3) WINAPI included in MinGW is not enough to build ooo.  It is necessary to port
some headers of Platform SDK and to create import libraries.  And also interface
IID entities need to be implemented to some WINAPI.

4) Many of Ole interface related modules handle COM object pointers with
comdef.h and ATL templates.  These templates must be ported.

5) They say that Windows import libraries can be used with MinGW's ld but this
is slightly difficult to do, which means it sometimes doesn't work.  We'd better
have a strategy to create import libraries with ar type archive.

6) dmake built with MinGW still doesn't work.  He uses dmake which was build for
MSVC+tcsh.  If MinGW built dmake works, we would have to change the strategy to
change makefiles.

7) If you define absolute pathes with /cygdrive/x/... format in parameters which
are provided to tools, MinGW tools and other tools which are build with MinGW
don't work.  There are some strategies to make those tools work such as using
the Perl wrapper or using cygdrive commands in makefiles to convert those pathes
to x:/... format.  The same strategy can be applied to set_soenv but in turn
environment variables which cygwin's tcsh uses don't accept x:/... format.  So
we can't convert all pathes to x:/... format at once.

He had temporary solutions to workaround the above questions.

He thinks there might be some porting issues which is as follows:

1) exception handling
Now he fully utilize gcc's exception handling but he is not sure that this works
with uno-bridge.

2) wchar_t
In gcc, it seems that wchar_t is not compatible with unsigned short int.  He
forcibly cast them.  Both of them have 2 byte length, which should be reconfirmed.

Created attachment 12596 [details]
tono's patch 1

Created attachment 12597 [details]
tono's patch 2

Created attachment 12598 [details]
tono's patch 3

reassigned.

Adding myself as cc

Please raise a separate issue for dmake and assign to Waratah.  I will look into
this.

> 6) dmake built with MinGW still doesn't work.  He uses dmake which was build for
> MSVC+tcsh.  If MinGW built dmake works, we would have to change the strategy to
> change makefiles.

This is the same problem as for the build with a MS compiler and either
the cygwin or the 4NT environment. If you want to use the unixy tools
and POSIX like paths you have to use the "normal" cygwin dmake version.

If you compile dmake with MinGW or in cygwin with "gcc -mno-cygwin", what
is the same, you have to use 4NT as the build shell, this is the way
Viktor started his MinGW port.

I definitely would like to (and will) help on this issue.

vq->waratah. This is not a fix to dmake, it is going throug all *.mk
and cleaning them from the assumption that "WNT" == "MS Compiler".

I'll dig out my patches, check if issue 13888 is still usefull, and see how
far I get with his patches.

A question: Is he using the Mingw standalone installation, or does he use
"gcc -mno-cygwin" and "g++ -mno-cygwin" ?

Volker

Hi, I would like to ask you to let me know which problems do we have with this
port and which modules are currently being ported. There could be modules, for
which we should take "unix" way of building, such as sal. As to winapi - that
could be exactly the case of the "Unix" way... The point is we don't need
anything windows-special under Unix, and the MinGW is rather Unix compliant.
Well, in order to avoid making changes in MinGW, I would suggest to consider the
Unix alternative...
I don't understand what does it mean "dmake doesn't work". Could you explain
more detailed?
As to path problem - there is already a tool solenv/bin/guw.pl, which supposed
to handle such problems...
As to uno bridge - I have raised this question, the Unix(linux) brigde port
should be the rigtht and not too complicated thing

Hi waratah, vq and vg,

I am asking tono about dmake and other questions vq and vg raised, please wait
for him.

vg, 
>Well, in order to avoid making changes in MinGW, 
>I would suggest to consider the Unix alternative...
Are you suggesting Unix(Linux)+MingGW can build ooo for Windows?
Have you tried this?

Not to detract from this important effort, but you might find it easier to build
with the free Digital Mars C++ compiler - a dedicated Windows compiler that
works with all Microsoft SDKs, STLport, etc.  It's totally free, lightning fast,
and much easier to use than MinGW.  The runtime libraries are open-source and
royalty free, as well as native Win32.  I say 'easier' mainly because DMC++ is
very compatible with MSVC++ which is currently used to build OOo on Win32. 
MinGW is not.

http://www.DigitalMars.com
http://biolpc22.york.ac.uk/wx/wxhatch/wxMSW_Compiler_choice.html

The technical support from Walter Bright (the author) is exceptional.  Compiler
performance and runtime speed performance are extremely good.

Hi, fellas

vq wrote...

>I'll dig out my patches, check if issue 13888 is still usefull, and see how
>far I get with his patches.

Thank you vq and I will check the issue later on.

>A question: Is he using the Mingw standalone installation, or does he use
>"gcc -mno-cygwin" and "g++ -mno-cygwin" ?

I installed Mingw gcc 3.3.1 and Cygwin in different directory trees and trying 
to build ooo setting Mingw path and using Cygwin's tcsh in a Cygwin window.

vg wrote ...

>Hi, I would like to ask you to let me know which problems do we have with this
>port and which modules are currently being ported. There could be modules, for

Currently the projects in the following list have been built, but none tested.
The list includes those projects that have nothing to do with the compilers.

UnoControls,XmlSearch,accessibility,berkeleydb,bitstream_vera_fonts,boost,
bridges,chaos,codemaker,comphelper,configmgr,cosv,cppu,cppuhelper,cpputools,
crashrep,curl,dtrans,embedserv,eventattacher,expat,external,extras,fileaccess,
fpicker,framework,freetype,helpcontent,i18n_simple,i18npool,i18nutil,icu,
idl,idlc,io,javaunohelper,jpeg,jurt,jut,jvmaccess,moz,nas,neon,offapi,
officecfg,offuh,package,psprint,python,pyuno,rdbmaker,readlicense_oo,regexp
registry,remotebridges,ridljar,rsc,rvpapi,sablot,sal,salhelper,sandbox
sax,scaddins,shell,sj2,so3,soltools,sot,stlport,stoc,store,svtools,sysui
toolkit,tools,transex3,ucb,ucbhelper,udkapi,unoil,unotools,unzip,uui,vcl,vos
wizards,xml2cmp,xmlhelp,xmlscript,zlib

>port and which modules are currently being ported. There could be modules, for
>which we should take "unix" way of building, such as sal. As to winapi - that
>could be exactly the case of the "Unix" way... The point is we don't need
>anything windows-special under Unix, and the MinGW is rather Unix compliant.
>Well, in order to avoid making changes in MinGW, I would suggest to consider 
>the
>Unix alternative...

In most projects, I have modified the make files to act "unix way". However, 
we have many windows specific modules. And of course the primitive actions 
which depend upon operating systems must use WINAPI in windows.

>I don't understand what does it mean "dmake doesn't work". Could you explain
>more detailed?

I do not know exactly but I suspect that it needs many modifications in files 
in solenv/inc/startup. Dmake.exe can be built but it builds nothing.

>As to path problem - there is already a tool solenv/bin/guw.pl, which supposed
>to handle such problems...

I know that but as I have chosen the strategy to use mixed path description 
(x:/.../.../ way), I had to rewrite the script. Actually I do not like to use 
perl wrapper and want to minimize the use. I believe once we can port dmake, 
we can get rid of the script.

All the Best,

Takashi Ono

>>A question: Is he using the Mingw standalone installation, or does he use
>>"gcc -mno-cygwin" and "g++ -mno-cygwin" ?
>
>I installed Mingw gcc 3.3.1 and Cygwin in different directory trees and trying 
>to build ooo setting Mingw path and using Cygwin's tcsh in a Cygwin window.

Just a comment on this. This is possibly not necessary the -mno-cygwin enables
the "MinGW engine". There _should_ be no differences.


>I know that but as I have chosen the strategy to use mixed path description 
>(x:/.../.../ way), I had to rewrite the script. Actually I do not like to use 
>perl wrapper and want to minimize the use. I believe once we can port dmake, 
>we can get rid of the script.
What do you mean by port dmake? As I tried last time the MinGW compiled
dmake works exactly like the one compiled with a MS compiler. Do you mean
teaching dmake to understand POSIX paths?

>>I installed Mingw gcc 3.3.1 and Cygwin in different directory trees and 
trying 
>>to build ooo setting Mingw path and using Cygwin's tcsh in a Cygwin window.
>
>Just a comment on this. This is possibly not necessary the -mno-cygwin enables
>the "MinGW engine". There _should_ be no differences.

Yeah but I still like vanilla.

>What do you mean by port dmake? As I tried last time the MinGW compiled
>dmake works exactly like the one compiled with a MS compiler. Do you mean
>teaching dmake to understand POSIX paths?

Actually I have not noticed that MinGW compiled dmake works, and that it 
exactly works as the one compiled with MSVC. If so, there may be some simpler 
strategy. Exactly my wish was to teach dmake to understand mixed paths and 
provide temporary file path in mixed path to commands.

Takashi Ono

> Yeah but I still like vanilla.
The reason I started this way was, that I wanted to use the same build
environment as for the "tcsh with MS Compiler" setup. That way you need
cygwin anyway, and if you have cygwin you can also use "gcc -mno-cygwin".
And I like it ;-)

I'll look into the dmake issue and confirm (or not) that Mingw dmake is
100% compatible to the MS compiler case. It was as I did the port, but
that was last year ;-)

>The reason I started this way was, that I wanted to use the same build
>environment as for the "tcsh with MS Compiler" setup. That way you need
>cygwin anyway, and if you have cygwin you can also use "gcc -mno-cygwin".
>And I like it ;-)

We need Cygwin anyway, absolutely. We should concern which compiler 
environment is more reliable and up-to-date. Most probably cygwin compiler is 
more reliable but I do not know how w32api update is being ported into both 
environment. Maybe MinGW first?

>I'll look into the dmake issue and confirm (or not) that Mingw dmake is
>100% compatible to the MS compiler case. It was as I did the port, but
>that was last year ;-)

If the dmake built with MinGW is mostly the same as the one built with MSVC, 
it does not work well with tcsh and I think we should do some work with dmake 
anyway, am I wrong?

> We need Cygwin anyway, absolutely. We should concern which compiler 
> environment is more reliable and up-to-date. Most probably cygwin compiler is 
> more reliable but I do not know how w32api update is being ported into both 
> environment. Maybe MinGW first?
Don't get me wrong, I mean it doesn't matter. Setting the CC (and similar CXX)
variable to either <path to mingw-gcc> or "gcc -mno-cygwin" should not make any
difference. Each time a new Mingw version is released the cygwin packages
are updated (By the MinGW people). The only advantage I might see is that
the cygwin gcc can work with POSIX paths. So just use Mingw, I'll use
gcc -mno-cygwin, I'll see how far I get.

> If the dmake built with MinGW is mostly the same as the one built with MSVC, 
> it does not work well with tcsh and I think we should do some work with dmake 
> anyway, am I wrong?
Absolutely, that is the reason that the W32-tcsh build uses the cygwin
executable.

I'll have a look at the build dmake with Mingw issue now.

vq->tono: OK, I stumbled across a timezone problem, therefore it took a bit
longer. To build dmake with "gcc -mno-cygwin" do the following. Open a bash, go
to your OOo source directory, then:

$ cd dmake

$ CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin' TZ='' ./configure

$ make

Sorry, at the moment I don't have a pure MinGW installed, but just put
the names for the mingw-gcc compiler where I put the <g?? -mno-cygwin> .

You propably don't need the TZ='', but in a cygwin environment the
configure test for HAVE_UTIME_NULL fails because the mingw library is
not TZ aware.

Well, I have made up my mind not to stick to minimizing the use of perl 
wrapper script.

Anyway we have to use the script for the tools using PATH environment variable 
because converting PATH format is very complecated while single path parameter 
can be converted easily by invoking a cygpath command.

It may eliminate a quarter of patches in makefiles.

Takashi Ono

> Well, I have made up my mind not to stick to minimizing the use of perl 
> wrapper script.
As I invented it for the W32-tcsh (I should call it MSC-tcsh now ;-) ) I totally
agree with you. ;-)

> Anyway we have to use the script for the tools using PATH environment variable 
> because converting PATH format is very complecated while single path parameter 
> can be converted easily by invoking a cygpath command.
Yes.

Hi all,

it's alraedy a month passed since last comment in this issue. Are there some
problems where we could be helpful? 

I have "built" allthe project leaving some modules using OLE.

The setup does not work yet. There may be some unknown problems.

The following isuues are to be decided.

1. How to cope with bugs and missing APIs in w32api. Should we apply patches 
tp mingw headers or just modify ooo source files.

2. How to cope with the bug in --enable-runtime-pseudo-reloc. I have applied a 
patch ( https://sourceforge.net/tracker/?
func=detail&atid=302435&aid=844566&group_id=2435 ) to binutils but I am afraid 
the patch is not so sophisticated and may cause other bugs.

3. How to implement OLE without using ATL library. Currently I have no good 
solution.

4. How to implement C++ <-> uno bridge. I have enabled g++ native RTTI but I 
do not know it works well.

Hi,
I have talked to the projects owners about these problems, and here are the answers:
1. Apply patches is the preferable way. I think, the main idea of mingw is to
make it possible to build code written for windows with gcc compiler - so to
patch the compiler header would be the right way.
2. As far I have understood, the "--enable-runtime-pseudo-reloc" bug is just
about missing entries in library import table. I do not think that requires
sophisticated changes. What make you so distrustful? Do we have another choice?
3. OLE without using ATL library... Actually, this library functionality should
be implemented, but(!!) it's not vital for the office. So, we can just ignore
the modules where it's needed, and first just bring the office to fly. As soon
we achieved this goal, we can investigate this problem more closely.
4. As I already told, we should choose the UNIX way. If the hypotheses that
MinGW generate a similar code as GCC 3 is wright, than we may use (or try to
use) the linux bridge for GCC. It's located in
bridges/source/cpp_uno/gcc3_linux_intel
It's most likely working.
Vladimir

Hi, Vladimir,

Thank you for your help.

 >4. As I already told, we should choose the UNIX way. If the hypotheses that
 >MinGW generate a similar code as GCC 3 is wright, than we may use (or try to
 >use) the linux bridge for GCC. It's located in
 >bridges/source/cpp_uno/gcc3_linux_intel
 >It's most likely working.

The problem is that we have no dlopen function in win32. The unix c++ <-> uno 
bridge is using this to build hash table to identify exception type.

Takashi 

@tono:
The dlopen()/dlsym() functions are used to find the RTTI symbols for exception
throwing.  The dlopen() is just used to get the application handle.  Try to use
Windows API for this, e.g. LoadLibrary()/GetProcAddress().
[BTW: I was expecting that MinGW uses Windows kernel-based structured exception
handling (SEH), so that you ought to reuse/adopt the MS Visual C++ compiler
binding code from cpp_uno/msvc_w32_intel/except.cxx.]

Hi, dbo,

Unfortunately MingW does not seem to be using MS-Windows kernel based SEH.

>The dlopen()/dlsym() functions are used to find the RTTI symbols for exception
>throwing.  The dlopen() is just used to get the application handle.  Try to 
use
>Windows API for this, e.g. LoadLibrary()/GetProcAddress().

The problem is that we do not know the module name. I think we should always 
just "generate" rtti info for uno exceptions from the uno name.

I have made correction in c++ <-> uno bridges and the setup is now working. 
writer and calc seem to be working.

The left issues are as follows;

1. OLE
OLE is not implemented.

2. Title Bar problem
Probably from some poor porting, the captions in the title bars in all windows 
are garbled.

3. Threading in python
I have implemented POSIX threading in python but it requires distribution of 
the external library. I think we should implement windows native threading 
instead so that we can keep minimal set.

4. Porting strategy
Currrently I have made some modification in ooo sources to cover up mingw bugs 
and they have to be substituted by patches for mingw headers.

5. Based release
I am still working with 1.1 and the work should be transfered to 1.1.1

tono wrote:
> I have made correction in c++ <-> uno bridges
> and the setup is now working. 
> writer and calc seem to be working.

Wow!!! Great News!!!  You made it, tono!!!  Thank you very much.
Let us document all what you have done.
I really would like to help create the documentation.

Hi, fellas,

I have modified python to use NT native threading directly instead of through 
pthread library. Now I am free.

I am now seperating patches for mingw headers and transfering my works into 
1.1.1.

I had to implement a new tricky hack in dllentry in sal project as mingw has 
no hook point before calling static object constructors in initialization.

Although Ihave not discovered Title Bar Problems and OLE issue is not solved, 
I think I can disclose my local patches in a couple of weeks.

All the Best,

Takashi Ono

adding myself to CC 

Created attachment 14293 [details]
Patches for MINGW headers

Created attachment 14294 [details]
Patches for solenv

Created attachment 14295 [details]
Patches for project makefiles

Created attachment 14296 [details]
Patches for project source files, delivery lists, map files etc.

Created attachment 14297 [details]
Additional patch

Hi fellas,

I have got through with 1.1.1rc, reorganized my patches and uploaded them.

Although Title Bar problem and OLE issue are not solved yet, now I can build 
the installation set and it works.

Please note that I am installing mingw in a seperate tree and not using cygwin 
compiler when building projects. I have to use cygwin compiler when building 
dmake by adding cygwin path in bootstrap shell script.

Beside some patches for headers, I also rebuilt binutils in mingw tree with 
patches to avoid pseudo-runtime-reloc bug and rebuilt libmsvcrt.a.

Regards,

Takashi Ono

I have added a few files and some of them are based on existing files.

Please run following commands before applying my patches.

cp -p ${ORIGINAL_SRC_ROOT}/sal/systools/win32/uwinapi/uwinapi.dxp 
sal/systools/win32/uwinapi/uwinapi_mingw.dxp
cp -p ${ORIGINAL_SRC_ROOT}/sal/systools/win32/uwinapi/unicows.dxp 
sal/systools/win32/uwinapi/unicows_mingw.dxp
cp -p ${ORIGINAL_SRC_ROOT}/cppuhelper/source/gcc3_linux_intel.map 
cppuhelper/source/mingw.map
cp -p ${ORIGINAL_SRC_ROOT}/psprint/util/libpsp_linux.map 
psprint/util/libpsp_mingw.map
rm -rf bridges/source/cpp_uno/mingw_intel
cp -Rp ${ORIGINAL_SRC_ROOT}/bridges/source/cpp_uno/gcc3_linux_intel 
bridges/source/cpp_uno/mingw_intel

Regards,

Takashi Ono

Foryour information, MinGW-3.1.0-1.exe, gcc-core-3.3.1-20030804-1.tar.gz, gcc-
g++-3.3.1-20030804-1.tar.gz and w32api-2.5.tar.gz are installed in my 
environment for build.

For rebuilding binutils and libmsvcrt.a, MSYS-1.0.9.exe, msysDTK-1.0.1.exe, 
binutils-2.13.90-20030111-1-src.tar.gz and w32api-2.5-src.tar.gz are installed 
as well

Regards,

Takashi Ono

Congratulations!!!!!!!!

Do you already have filed a Joint Copyright Assignment?

If yes, Martin can we please get a cws to integrate this work?

vq wrote...
 >Congratulations!!!!!!!!

Thank you!

 >Do you already have filed a Joint Copyright Assignment?

Certainly yes, though I have not yet joined porting project.

Regards,

Takashi Ono

I have found out that Title Bar Problem is caused by linking unicows.dll to 
uwinapi.dll in sal project. As unicows.lib does not work with mingw, I have 
built import archives for unicows.dll but it is not working.

Actually linking with unicows.lib with MS linker does not link unicows.dll! 
Unicows.lib seems to be made with some tricks.

I have found libunicows project on the web. Shall we use this one?

Your comments will be appreciated.

Regards,

Takashi Ono

Hi tono,

> I have found libunicows project on the web. Shall we use this one?

That depends on their licence and if it works. ;)

This evening I'll try to build OOo following your instructions and patches.

Greetings,

    Volker

vq->tono: What commandline did you use to generate your winmingw.set?

 >> I have found libunicows project on the web. Shall we use this one?
 >That depends on their licence and if it works. ;)

As SourceForge was sleeping, I have not confirmed yet. The google cache says 
the licence is MIT licence.

Takashi Ono

 >vq->tono: What commandline did you use to generate your winmingw.set?

export PATH=${MINGW_HOME}/bin:$PATH
(cd config_office && ./configure --with-mingwin=yes --with-lang=JAPN --with-
jdk-home=${JV_HOME} --with-dict=ALL --with-ant-home=${ANT_HOME} --enable-
crashdump --enable-symbols=SMALL

Takashi Ono

Now I understand that unicows.lib is a static library with thunk codes rather 
than a simple import library. As uwinapi has thunk code internally, I think it 
better to implement "selective" thunk for unicows.dll inside uwinapi.dll 
instead of linking with unicows.lib (or libunicows.a).

Regards,

Takashi Ono

I'm streamlining the config_office patches at the moment. I'll open a new issue
when they work. I'm using the native Mingw compiler ATM, but in the end
it should also be possible to use gcc -mno-cygwin.

I think we need a different solution then patching the mingw include files,
eiher get the patches in the upstream mingw distribution, or create
an extra include file for mingw that we include via sal/inc/sal/config.h.

Volker

Hi!

The mingw_headers.patch fails because there is no include/winres.h.

From your patch I see (?) that you have created a winres.h by copying
winresrc.h.

Hi, where did you get your rc from?

I'm building on a MS compiler free system and therefore don't have a rc.exe.

Error:
guw.pl rc -DWIN32 -I -I.  -I. -I../inc -I../../../inc -I../../../WIN/inc
-I../../../wntgcci.pro/inc -I.
(snip)
../../../wntgcci.pro/misc/uwinapi_def.rc
Command: rc
Can't exec "rc": No such file or directory at
/cygdrive/d/w1/OOo111mingw/solenv/bin/guw.pl line 273.

Error: guw.pl: executing rc failed!

Error: guw.pl: executing rc failed!
dmake:  Error code 2, while making '../../../wntgcci.pro/bin/uwinapi.dll'
echo: No match.

ERROR: Error 65280 occurred while making
/cygdrive/d/w1/OOo111mingw/sal/systools/win32/uwinapi

tono -> vq

I have Winresrc.h and rc.exe in my PSDK tree. Don't you?

> I have Winresrc.h and rc.exe in my PSDK tree. Don't you?
Argh! Yes I have rc.exe. (But not in my path.)

I can tell you now, that it should be possible to use windres.exe from
MinGW or cygwin, but _tg_shl.mk produces lots -I. parameters, rc.exe can
work with them, windres cannot.

vq@openoffice.org wrote...
 >The mingw_headers.patch fails because there is no include/winres.h.

The patch should have been omitted from the mingw_headers.patch.

I decided to create it in solenv/inc at the last moment and added the patch in 
solenv_mingw.patch.

Sorry for my mistake.

I will update mingw_headers.patch.

Takashi Ono

Created attachment 14346 [details]
Patches for MINGW headers (updated)

Hi!

I'm stuck in sal a the moment, depending on the order of the build (build.lst
problem) I get either:
-----------
dlltool --input-def ../../../wntgcci.pro/misc/uwinapi.def --dllname uwinapi.dll
--kill-at --output-exp ../../../wntgcci.pro/misc/uwinapi.exp
guw.pl gcc -mno-cygwin -nostdlib -Wl,--enable-runtime-pseudo-reloc
-L../../../wntgcci.pro/lib -L../../../wntgcci.pro/slb -L. -L. -L
(snip)
-Wl,../../../wntgcci.pro/misc/uwinapi.exp -lmingw32 -lgcc -lunicows -lkernel32
-luser32 -ladvapi32 -lversion -lmsvcrt
-Wl,-Map,../../../wntgcci.pro/misc/uwinapi.map
Command: gcc
c:\MinGW\bin\..\lib\gcc-lib\mingw32\3.3.1\..\..\..\..\mingw32\bin\ld.exe: cannot
find -lunicows
dmake:  Error code 1, while making '../../../wntgcci.pro/bin/uwinapi.dll'
echo: No match.

ERROR: Error 65280 occurred while making
/cygdrive/d/w1/OOo111mingw/sal/systools/win32/uwinapi 
-----------
or
-----------
Making: ../../wntgcci.pro/obj/signal.obj
guw.pl gcc -mno-cygwin -fmessage-length=0 -c -Wall -I-I. -I. -I../inc
-I../../inc -I../../WIN/inc -I../../wntgcci.pro/inc -I.
-I/cygdrive/d/w1/OOo111mingw/solver/645/wntgcci.pro/inc/dont_use_stl
-I/cygdrive/d/w1/OOo111mingw/solver/645/wntgcci.pro/inc/external
-I/cygdrive/d/w1/OOo111mingw/solver/645/wntgcci.pro/inc
-I/cygdrive/d/w1/OOo111mingw/solenv/wntgcci/inc
-I/cygdrive/d/w1/OOo111mingw/solenv/inc -I/cygdrive/d/w1/OOo111mingw/res
-I/cygdrive/d/w1/OOo111mingw/solver/645/wntgcci.pro/inc/dont_use_stl
-I/cygdrive/c/j2sdk1.4.1_02/include/win32 -I/cygdrive/c/j2sdk1.4.1_02/include
-I/cygdrive/c/MinGW/include
-I/cygdrive/c/MinGW/lib/gcc-lib/mingw32/3.3.1/include
-I/cygdrive/c/MinGW/include/c++/3.3.1
-I/cygdrive/c/MinGW/include/c++/3.3.1/mingw32
-I'/cygdrive/d/psdk02_2003/include' -I. -I../../res -I.    -nostdinc -O3   -pipe
-march=pentiumpro -DWIN32 -DWINVER=0x0500 -D_WIN32_IE=0x400 -D_MT -D_DLL  -DWNT
-DWNT -DNT351 -DGCC -DC300 -DINTEL
-DGXX_INCLUDE_PATH=/cygdrive/c/MinGW/include/c++/3.3.1 -D_USE_NAMESPACE
-D_M_IX86 -DSTLPORT_VERSION=450 -D_STLP_USE_DYNAMIC_LIB -DCPPU_ENV=gcc3
-DSUPD=645 -DBUILD=8762 -DPRODUCT -DNDEBUG -DPRODUCT_FULL -DOSL_DEBUG_LEVEL=0
-DOPTIMIZE -DEXCEPTIONS_OFF -DCUI -DSOLAR_JAVA -DSRX645  -DMULTITHREAD  
-o../../wntgcci.pro/obj/signal.obj signal.c
(snip)
Command: gcc
In file included from signal.c:73:
../../inc/systools/win32/uwinapi.h:62:9: warning: #pragma once is obsolete
signal.c: In function `InitSignal':
signal.c:99: error: `pfn_ADDEREXCLUDEDAPPLICATIONW' undeclared (first use in
this function)
signal.c:99: error: (Each undeclared identifier is reported only once
signal.c:99: error: for each function it appears in.)
signal.c:99: error: parse error before "pfn"
signal.c:100: error: `pfn' undeclared (first use in this function)
signal.c:101: error: `pfn' used prior to declaration
signal.c:101: warning: implicit declaration of function `pfn'
signal.c: In function `ReportCrash':
signal.c:169: warning: unsigned int format, DWORD arg (arg 5)
signal.c:169: warning: unsigned int format, DWORD arg (arg 7)
signal.c: At top level:
signal.c:226: warning: static declaration for `SignalHandlerFunction' follows
non-static
signal.c: In function `SignalHandlerFunction':
signal.c:270: warning: suggest parentheses around && within ||
signal.c:294: warning: enumeration value `osl_Signal_ActIgnore' not handled in
switch
signal.c:294: warning: enumeration value `osl_Signal_Act_FORCE_EQUAL_SIZE' not
handled in switch
dmake:  Error code 1, while making '../../wntgcci.pro/obj/signal.obj'
dmake:  '../../wntgcci.pro/obj/signal.obj' removed.
echo: No match.

ERROR: Error 65280 occurred while making /cygdrive/d/w1/OOo111mingw/sal/osl/w32
dmake:  Error code 1, while making 'build_all'
echo: No match.
-----------

I guess the first error is the "--enable-runtime-pseudo-reloc" problem in
binutils, I'll rebuild them now with the patch.

OK, nice to have the new binutils, but that wasn't the problem.

unicows.lib was missing, I added the lib directory of the PSDK
(version 02/2003, which one do you use?) to the end of LIB and ILIB,
but now I get:

------
guw.pl gcc -mno-cygwin -nostdlib -Wl,--enable-runtime-pseudo-reloc
-L../../../wntgcci.pro/lib -L../../../wntgcci.pro/slb -L. -L. -L
-L/cygdrive/d/w1/OOo111mingw/solver/645/lib 
(snip)
../../../wntgcci.pro/misc/uwinapi_res.o
-Wl,../../../wntgcci.pro/misc/uwinapi.exp -lmingw32 -lgcc -lunicows -lkernel32
-luser32 -ladvapi32 -lversion -lmsvcrt
-Wl,-Map,../../../wntgcci.pro/misc/uwinapi.map
Command: gcc
..\..\..\wntgcci.pro\misc\uwinapi.exp(.edata+0x38):fake: undefined reference to
`AddFontResourceW@4'
..\..\..\wntgcci.pro\misc\uwinapi.exp(.edata+0x3c):fake: undefined reference to
`AddJobW@20'
..\..\..\wntgcci.pro\misc\uwinapi.exp(.edata+0x40):fake: undefined reference to
`AddPortW@12'
(snip)
..\..\..\wntgcci.pro\misc\uwinapi.exp(.edata+0x7d4):fake: undefined reference to
`midiInGetErrorTextW@12'
..\..\..\wntgcci.pro\misc\uwinapi.exp(.edata+0x7d8):fake: undefined reference to
`sndPlaySoundW@8'
dmake:  Error code 1, while making '../../../wntgcci.pro/bin/uwinapi.dll'
echo: No match.

ERROR: Error 65280 occurred while making
/cygdrive/d/w1/OOo111mingw/sal/systools/win32/uwinapi
dmake:  Error code 1, while making 'build_all'
echo: No match.
------

Any hints? These missing symbols look like the ones you add with your patch
to sal/systools/win32/uwinapi/unicows_mingw.dxp.

vq@openoffice.org wrote...
 >unicows.lib was missing, I added the lib directory of the PSDK
 >(version 02/2003, which one do you use?) to the end of LIB and ILIB,

We cannot link uwinapi with unicows.lib. As I wrote, I made libunicows.a as an 
import archive. It does not work but at least we can proceed with build.

I added new makefiles.mk in external/unicows, which will create libunicows.a. 
Don't you have it built?
 
Best Regards,

Takashi Ono

> I added new makefiles.mk in external/unicows, which will create libunicows.a.
> Don't you have it built?

There is a dependency missing in sal:
--- sal/prj/build.lst	16 Jul 2003 17:22:09 -0000	1.15
+++ sal/prj/build.lst	6 Apr 2004 17:43:01 -0000
@@ -1,4 +1,4 @@
-sa	sal	:	xml2cmp NULL 
+sa	sal	:	xml2cmp external NULL  

With this it builds sal/systools/win32/uwinapi but breaks then in sal/osl/w32
when compiling signal.c.

Hi again, sorry for the noise, I lost my patches to mingw/include/ somehow.
After reapplying them the build continues.

Apropos patch, your new mingw_headers.patch gives:
patching file include/winres.h
patch: **** unexpected end of file in patch

No wonder, you just cut of the last lines.

> The mingw_headers.patch fails because there is no include/winres.h.
> From your patch I see (?) that you have created a winres.h by copying
> winresrc.h.
But my lines above mean that there was no winres.h in my c:/mingw/include
directory. I copied include/winresrc.h to include/winres.h and then your
(old) patch applied cleanly.

I tripped over another problem.

Project udkapi starts the fresh build idlc.exe, but idlc.exe seems to use uwinapi
and I get a popup box which says:

Header: idlc.exe - Entry Point Not Found
Window: The procedure entry point BeginUpdateResourceA could ot be located
in the dynamic link library unicows.dll.

I'll start a fresh rebuild from scratch ....

I created issue 27582 for the integration of the patches to config_office/ .

vq->tono: Any idea concerning the idlc.exe popup box?

Created attachment 14458 [details]
Patches for MINGW headers (updated April 10,2004)

Created attachment 14459 [details]
Patches for project makefiles (updated April 10,2004)

Created attachment 14460 [details]
Patches for solenv (updated April 10,2004)

Created attachment 14461 [details]
Patches for project source files, delivery lists, map files etc.

I have corrected winres.h patch.

I also implemented unicows thunk codings in 
sal/systools/win32/uwinapi/ResolbeThunk.cpp and removed wrong patches in 
external project.

Either libunicows.a or unicows.lib is no longer needed in mingw build and 
removed from framework project as well.

>vq
I suspect idlc.exe popup problem should also resolved.

Best Regards,

Takashi Ono

Curvirgo, a member of the ja mingw port team, have just found that
cws_srx645_mingw was tagged.  Does it have all 1.1.1 modules and files with all
updated patches applied?  

> Curvirgo, a member of the ja mingw port team, have just found that
> cws_srx645_mingw was tagged.  Does it have all 1.1.1 modules and files with all
> updated patches applied?

No, nothing is committed right now. I requested this cws from Martin to commit
checked and approved patches.

The patches have to be split to more reasonable sizes and reviewed.
I'll commit the config_office part (issue 27582) shortly and will
continue with solenv.

I'd appreciate help in splitting up the patches in smaller units
to let the review process progress faster.

vq->tono: My build stopped in shell with the error below. I found
a binutils problem in the web, see
<http://sources.redhat.com/ml/binutils/2001-07/msg00113.html>
but this patch doesn't help.

Any hints are appreciated!

------------------------------
Making: ../../../wntgcci.pro/bin/shlxthdl.dll
guw.pl /cygdrive/c/MinGW/bin/gcc -c
-o../../../wntgcci.pro/slo/shlxthdl_version.obj -DWNT 
-I../../../wntgcci.pro/inc /cygdrive/d/w1/OOo111mingw/solenv/src/version.c
Command: /cygdrive/c/MinGW/bin/gcc
guw.pl rc -DWIN32 -I -I.  -I. -I../inc -I../../../inc -I../../../WIN/inc
-I../../../wntgcci.pro/inc -I.
-I/cygdrive/d/w1/OOo111mingw/solver/645/wntgcci.pro/inc/stl
-I/cygdrive/d/w1/OOo111mingw/solver/645/wntgcci.pro/inc/external
-I/cygdrive/d/w1/OOo111mingw/solver/645/wntgcci.pro/inc
-I/cygdrive/d/w1/OOo111mingw/solenv/wntgcci/inc
-I/cygdrive/d/w1/OOo111mingw/solenv/inc -I/cygdrive/d/w1/OOo111mingw/res
-I/cygdrive/d/w1/OOo111mingw/solver/645/wntgcci.pro/inc/stl
-I/cygdrive/c/j2sdk1.4.1_02/include/win32 -I/cygdrive/c/j2sdk1.4.1_02/include
-I/cygdrive/c/MinGW/include
-I/cygdrive/c/MinGW/lib/gcc-lib/mingw32/3.3.1/include
-I/cygdrive/c/MinGW/include/c++/3.3.1
-I/cygdrive/c/MinGW/include/c++/3.3.1/mingw32
-I'/cygdrive/d/psdk02_2003/include'     -I. -I../../../res -I. 
../../../wntgcci.pro/misc/shlxthdl_def.rc
Command: rc
cat ../../../wntgcci.pro/res/49/shlxthdl.res
../../../wntgcci.pro/misc/shlxthdl_def.res > ../../../wntgcci.pro/misc/shlxthdl.res
windres ../../../wntgcci.pro/misc/shlxthdl.res
../../../wntgcci.pro/misc/shlxthdl_res.o
c:\MinGW\bin\windres.exe: ../../../wntgcci.pro/misc/shlxthdl.res: unexpected end
of file
dmake:  Error code 1, while making '../../../wntgcci.pro/bin/shlxthdl.dll'
echo: No match.

ERROR: Error 65280 occurred while making
/cygdrive/d/w1/OOo111mingw/shell/source/win32/shlxthandler
--------------------------------------------------

vq@openoffice.org wrote...
 >vq->tono: My build stopped in shell with the error below. I found
 >a binutils problem in the web, see
 ><http://sources.redhat.com/ml/binutils/2001-07/msg00113.html>
 >but this patch doesn't help.
 >
 >Any hints are appreciated!

tono->vq: I have to apologize not to have mentioned winres.exe modification.

I made modification so that winres can process concatenated .res files (with 
multiple resource headers). Microsoft tools can handle them as valid .res 
files, winres cannot.

In the meantime, the issue can be solved by modifying solenv/inc/_?tg_
(app|shl).mk.
I wonder whether is the more sophisticated solution.

Anyways I will upload the patch for winres.

Regards,

Takashi Ono

I started my mingw ooo building on Windows98SE.
;)
./configure --with-mingwin=yes
produced:
checking for gawk... gawk
checking for gawk... /bin/gawk
checking for sed... /bin/sed
checking the operating system... configure: error: MINGW32_98-4.10
operating system is not suitable to build OpenOffice.org!

What is the operating system requirement for mingw ooo building?

vq@openoffice.org wrote...
 >vq->tono: My build stopped in shell with the error below. I found
 >a binutils problem in the web, see
 ><http://sources.redhat.com/ml/binutils/2001-07/msg00113.html>
 >but this patch doesn't help.
 >
 >Any hints are appreciated!

tono->vq: I have to apologize not to have mentioned winres.exe modification.

I made modification so that winres can process concatenated .res files (with 
multiple resource headers). Microsoft tools can handle them as valid .res 
files, winres cannot.

In the meantime, the issue can be solved by modifying solenv/inc/_?tg_
(app|shl).mk.
I wonder whether is the more sophisticated solution.

Anyways I will upload the patch for winres.

Regards,

Takashi Ono

Created attachment 14477 [details]
Patch for windres.exe

With your patch the build continued.

I found another requirement, the build requires MASM, I'll update
the config_office patch, but then the build stopped again in
 setup2/source/custom/moffice
with the error below. I'am using binutils-2.13.90-20030111-1-src.tar.gz
patched with pseudo-reloc.diff and resres.c.patch.

Ideas?

-------------------------------------------------- 
cat ../../../wntgcci.pro/misc/mig645gi_def.res >
../../../wntgcci.pro/misc/mig645gi.res
windres ../../../wntgcci.pro/misc/mig645gi.res
../../../wntgcci.pro/misc/mig645gi_res.o
guw.pl /cygdrive/c/MinGW/bin/gcc -nostdlib -Wl,--enable-runtime-pseudo-reloc
-L../../../wntgcci.pro/lib -L../../../wntgcci.pro/slb -L. -L. -L
-L/cygdrive/d/w1/OOo111mingw/solver/645/lib
-L/cygdrive/d/w1/OOo111mingw/solver/645/wntgcci.pro/lib
-L/cygdrive/d/w1/OOo111mingw/solenv/wntgcci/lib -L/cygdrive/c/j2sdk1.4.1_02/lib
-L/cygdrive/c/MinGW/lib -Wl,--enable-stdcall-fixup -mconsole -shared --warn-once
/cygdrive/c/MinGW/lib/dllcrt2.o -o../../../wntgcci.pro/bin/mig645gi.dll
../../../wntgcci.pro/slo/mig_dflt_version.obj
../../../wntgcci.pro/slo/mig_dflt_description.obj
../../../wntgcci.pro/slo/arch.obj ../../../wntgcci.pro/slo/sifsys.obj
../../../wntgcci.pro/slo/winos.obj ../../../wntgcci.pro/misc/mig645gi_res.o
../../../wntgcci.pro/slo/moffice.obj ../../../wntgcci.pro/slo/migplug.obj
../../../wntgcci.pro/slo/sicustom.obj
-Wl,../../../wntgcci.pro/lib/libmig645gi.exp -lunzipdll_static -lvcl645gi
-ltl645gi -lcppuhelper3gcc3 -lcppu -lsal -luwinapi -ladvapi32 -lgdi32 -lshell32
-lole32 -luuid -lversion -lwinmm -lstlport_gcc -lstdc++ -lmingw32 -lgcc
-lmoldname -luwinapi -lm -lkernel32 -luser32 -lmsvcrt -lcrtdll -lmingwthrd
-Wl,-Map,../../../wntgcci.pro/misc/mig645gi.map
Command: /cygdrive/c/MinGW/bin/gcc
Info: resolving __timezone by linking to __imp___timezone (auto-import)
fu000001.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname'
fu000002.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname'
nmth000000.o(.idata$4+0x0): undefined reference to `_nm___timezone'
dmake:  Error code 1, while making '../../../wntgcci.pro/bin/mig645gi.dll'
echo: No match.

ERROR: Error 65280 occurred while making
/cygdrive/d/w1/OOo111mingw/setup2/source/custom/moffice
dmake:  Error code 1, while making 'build_all'
echo: No match.

-------------------------------------------------- 

tono->vq: You have to rebuild libmsvcrt.a in mingw winapi with patched binutils.

Hi,
the is a branch cws_src680_mingwcws, based on src680, the next release. Of
cause, it will contain all 1.1.1 modules and files... I'm responsible for this
port,so this week I'm planning to apply patches and review the changes. Please
contact me, if there is any problems.

vg->vq the problem with the SRX645 branched version is that it's -apparently-
not gone be merged in SRC680 (next release). So, we should apply the patches to
the SRC680 sources, even if it's not so convenient.
What to do: just let me know which modules are sufficient for the port, and I'll
ensure right branch for them.

> vg->vq the problem with the SRX645 branched version is that it's -apparently-
> not gone be merged in SRC680 (next release). So, we should apply the patches
> to the SRC680 sources, even if it's not so convenient.

@vg: Sorry, this mail took ~12h until it reached me. As I wrote in the meantime
in dev@porting, I don't have a problem with cws_srx645_mingw *NOT* being
integrated at in SRX645. But at the moment I'm toying with 600kb patches
and filterdiff to manage this stuff. I'd really like to commit Takashis
patches and the few changes I made into that cws. It will be buildable from
the beginning, that is something that we won't have when we start with any
SRC680 branch.

And it is always easy to generate patchsets by diffing the cws against its
 _ANCHOR. Let me repeat: Working without a cvs repository sucks!

> What to do: just let me know which modules are sufficient for the port,
> and I'll ensure right branch for them.

The following, plus config_office is the list of patched modules:
(lsdiff --strip=1 MW.diff | sed 's/\/.*//'|sort|uniq)
UnoControls
accessibility
autodoc
automation
basic
berkeleydb
boost
bridges
codemaker
comphelper
configmgr
connectivity
cosv
cppuhelper
crashrep
curl
dbaccess
desktop
dmake
dtrans
embedserv
eventattacher
expat
extensions
external
fileaccess
filter
forms
fpicker
framework
goodies
i18n
i18n_simple
i18npool
i18nutil
icu
idl
idlc
io
javaunohelper
jpeg
jurt
jvmaccess
lingucomponent
linguistic
moz
neon
np_sdk
odk
offmgr
package
padmin
psprint
python
pyuno
regexp
registry
remotebridges
rsc
sablot
sal
salhelper
sax
sc
scaddins
sch
scp
scptools
sd
setup2
sfx2
shell
sj2
so3
solenv
soltools
starmath
stlport
stoc
store
svtools
svx
sw
sysui
testtools
tools
ucb
ucbhelper
udm
unotools
unzip
vcl
vos
xml2cmp
xmlhelp
xmloff
xmlscript
zlib 

khirano wrote:
> I started my mingw ooo building on Windows98SE.
> ... configure: error: MINGW32_98-4.10

I was trying to build ooo on msys.  This is wrong.
I didn't read tono's comment correctly.
The correct way to do is as follows:

1) build dmake with cygwin's gcc.
2) change the PATH to /cygdrive/c/MinGW/bin (in my case)
3) then build ooo with mingw's gcc on cygwin

This worked and dmake started building ooo!!  Wow!
This was the first time for me to hit dmake on Windows98SE.  Impressive.;)

Now the build stopped at soltools/ldump.
Couldn't compile hashtbl.cxx.

C:/cygwin/home/hirano/oo_1.1.1_src/soltools/ldump/hashtbl.cxx:191:
error: `strlen' undeclared (first use this function)
C:/cygwin/home/hirano/oo_1.1.1_src/soltools/ldump/hashtbl.cxx: In member
function `HashItem* HashTable::FindPos(const char*) const':
C:/cygwin/home/hirano/oo_1.1.1_src/soltools/ldump/hashtbl.cxx:280:
error: `strcmp' undeclared (first use this function)
C:/cygwin/home/hirano/oo_1.1.1_src/soltools/ldump/hashtbl.cxx: In member
function `void* HashTable::Find(const char*) const':
C:/cygwin/home/hirano/oo_1.1.1_src/soltools/ldump/hashtbl.cxx:338:
error: `strcmp' undeclared (first use this function)
C:/cygwin/home/hirano/oo_1.1.1_src/soltools/ldump/hashtbl.cxx: In member
function `void* HashTable::Delete(const char*)':
C:/cygwin/home/hirano/oo_1.1.1_src/soltools/ldump/hashtbl.cxx:356:
error: `strcmp' undeclared (first use this function)
C:/cygwin/home/hirano/oo_1.1.1_src/soltools/ldump/hashtbl.cxx: In member
function `void HashTable::SmartGrow()':
C:/cygwin/home/hirano/oo_1.1.1_src/soltools/ldump/hashtbl.cxx:391:
error: syntax error before `long'
dmake: Error code 1, while making '../wntgcci.pro/obj/hashtbl.obj'dmake:
'../wntgcci.pro/obj/hashtbl.obj' removed.
echo: No match.
ERROR: Error 65280 occurred while making
/home/hirano/oo_1.1.1_src/soltools/ldump
[hirano@aptiva ~/oo_1.1.1_src/soltools]$

Hi khirano,

What to do (short summary)

(You need to fullfil all requirements as for the W32-tcsh build, even MASM,
but you don't need the Microsoft compiler, see:
<http://tools.openoffice.org/dev_docs/build_windows_tcsh.html>) 

* Build patched binutils and libmsvcrt.a for MinGW.
  Patch with resres.c.patch and
<https://sourceforge.net/tracker/?func=detail&atid=302435&aid=844566&group_id=2435>
  
  (You need mingw-runtime-3.2-src.tar.gz and w32api-2.5-src.tar.gz)
  ((To build you need bison and flex, but remove them from the path before
    you start the OOo build.)

* Patch your mingw/include files with:
    mingw_headers.patch

* Patch your OOo sources with (only the newest versions):
    ldump_hashtbl_cxx_mingw.patch
    makefiles_mingw.patch
    solenv_mingw.patch
    others_mingw.patch

* Revert the patch for
    readlicence_oo and config_office, apply the patch from issue 27582.
    (You don't have to use the MW_config_office_neu2.diff patch, then you
     don't have to generate configure by yourself, but I enhanced the
     checks for the build requirement for MinGW already)

* Patch sal/prj with:
--- sal/prj/build.lst	16 Jul 2003 17:22:09 -0000	1.15
+++ sal/prj/build.lst	6 Apr 2004 17:43:01 -0000
@@ -1,4 +1,4 @@
-sa	sal	:	xml2cmp NULL 
+sa	sal	:	xml2cmp external NULL 
 sa	sal										usr1	-	all	sa_mkout NULL
 sa	sal\cpprt								nmake	-	u	sa_cpprt sa_util NULL
 sa	sal\systools\macxp_extras\x11osx			nmake	-	u	sa_mxpext_x11osx NULL

* start a bash, cd into your OOo source dir and then into config_office,
  create a new configure with autoconf.
$ config_office

$ autoconf

$ cd ..

I recommend that you use a path that is as short as possible, but that includes
the Platform SDK Bin directory, e.g.:
$ export
PATH=/bin:/cygdrive/c/WINNT/system32:/cygdrive/c/WINNT:/cygdrive/c/psdk02_2003/Bin

Now configure, e.g.:
./configure  --with-mingwin=/cygdrive/c/MinGW
--with-jdk-home=/cygdrive/c/j2sdk1.4.1_02
--with-ant-home=/cygdrive/c/ant-1.5.3-1 --with-psdk-home=/cygdrive/d/psdk02_2003

* Now start a tcsh
$ tcsh

* Set your environment variables:
$ source winmingw.set

* build dmake
$ ./bootstrap

* Rehash your path
$ rehash

* Build OOo
$ dmake

And now wait. ... I forgot to say, I finally stopped my efforts to build
on a system with only 256MB ram, the linking of project sw took too long,
because my physical memory was exhausted and the system was continously
swapping. I'll report back when my W2k with 512MB finishes the build.

Hmmm, my build on Win2k with 512MB also failed with the error below. Stdout
and stderr are a bit mixed up, but ld comlains:
 "ld.exe: out of memory allocating 44 bytes"

I'll update to the 2.15.90 binutils and try again.
vq->tono: What do you use as your build system?

Info: resolving _sRTF_MARGBSXN by linking to __imp__sRTF_MARGBSXN (auto-import)
Info: resolving _sRTF_HE
d:\MinGW\bin\..\lib\gcc-lib\mingw32\3.3.1\..\..\..\..\mingw32\bin\ld.exe: out of
memory allocating 44 bytes
ADER by linking to __imp__sRTF_HEADER (auto-import)
Info: resolving _sRTF_FOOTER by linking to __imp__sRTF_FOOTER (auto-import)
Info: resolving _sRTF_FLYPRINT by linking to __imp__sRTF_FLYPRINT (auto-import)
Info: resolving _sRTF_FLYOPAQUE by linking to __imp__sRTF_FLYOPAQUE (auto-import)
Info: resolving _sRTF_FLYPRTCTD by linking to __imp__sRTF_FLYPRTCTD (auto-import)
Info: resolving _sRTF_NOWRAP by linking to __imp__sRTF_NOWRAP (auto-import)
Info: resolving _sRTF_FLYMAINCNT by linking to __imp__sRTF_FLYMAINCNT (auto-import)
Info: resolving _sRTF_FLYVERT by linking to __imp__sRTF_FLYVERT (auto-import)
Info: resolving _sRTF_PVPARA by linking to __imp__sRTF_PVPARA (auto-import)
Info: resolving _sRTF_POSYT by linking to __imp__sRTF_POSYT (auto-import)
Info: resolving _sRTF_POSY by linking to __imp__sRTF_POSY (auto-import)
Info: resolving _sRTF_POSYC by linking to __imp__sRTF_POSYC (auto-import)
Info: resolving _sRTF_POSYB by linking to __imp__sRTF_POSYB (auto-import)
Info: resolving _sRTF_PVMRG by linking to __imp__sRTF_PVMRG (auto-import)
Info: resolving _sRTF_PVPG by linking to __imp__sRTF_PVPG (auto-import)
Info: resolving _sRTF_FLYHORZ by linking to __imp__sRTF_FLYHORZ (auto-import)
Info: resolving _sRTF_PHCOL by linking to __imp__sRTF_PHCOL (auto-import)
Info: resolving _sRTF_POSXI by linking to __imp__sRTF_POSXI (auto-import)
Info: resolving _sRTF_POSXL by linking to __imp__sRTF_POSXL (auto-import)
dmake:  Error code 1, while making '../wntgcci.pro/bin/sw645gi.dll'
echo: No match.

ERROR: Error 65280 occurred while making /cygdrive/e/w1/cws_srx645_mingw/sw/util
dmake:  Error code 1, while making 'build_all'

tono->vq: My system is WinXpPro SP1 with 512MB RAM.

hi tono and vq,

Can you show us results by performing:?
ls -la ${ORIGINAL_SRC_ROOT}/solver/645/wntgcci.pro/bin
ls -la ${ORIGINAL_SRC_ROOT}/solver/645/wntgcci.pro/lib

Created attachment 14538 [details]
ls -la solver/645/wntgcci.pro/bin

Created attachment 14539 [details]
ls -la solver/645/wntgcci.pro/lib

My build finally finished, my virtual memory was too small.

Hi VQ,
From your 
ls -la solver/645/wntgcci.pro/bin and
ls -la solver/645/wntgcci.pro/lib, 
I learned that you created files in April,(Calc told me ;)
606,035,710 bytes (578MB) under bin
181,059,847 bytes (173MB) under lib.
If you strip them, how much will you get?
Wow!Wee!Anyway, it's huge.  Why?
My Windows98SE box has got only 256MB Mem.
I have to go get another 256MB Mem then.
;)
This is a BIG requirement though.

 

Hi vq and tono,

How much disk space would MinGW build eat up?
All wntgcci.pro (including installation sets) and solver.
Can you estimate?

And can you tell me your build order or the order of projects (modules) to be
built with MinGW+tcsh?

> And can you tell me your build order or the order of projects (modules) to
> be built with MinGW+tcsh?
Just startt dmake in your OOo_source_dir, or if you really want to now, cd into
instsetoo and type:

build --all --show

This will show you all that will be build, and the build order.

After a final complete build I committed the following patches to
cws_srx645_mingw. This cws should now be buildable with MinGW without
extra patches to the OOo source.

ldump_hashtbl_cxx_mingw.patch (2004/04/02)
makefiles_mingw.patch (2004/04/10) (Without odk and readlicense_oo.)
solenv_mingw.patch (2004/04/10)
others_mingw.patch (2004/04/10) (Without config_office, readlicense_oo
                                 and testtools.)

MW_config_office_neu2.diff (issue 27582)
MW_sal_prj.diff
MW_odk_neu.diff
javaunohelper_source.diff

The patches above base on Takashi Ono's work, but the SRX645 moved on a bit.

Created attachment 14586 [details]
Patch for sal

Created attachment 14587 [details]
Patch for odk

Created attachment 14588 [details]
Patch for javaunohelper

VQ!, Thanks for the cws_srx645_mingw tree patched.
I downloaded the tree and started my build.
soltoos was built but got an Error below.
Can this be ignored?

=============
Building project soltools
=============
/home/hirano/oo_1.1.1_src/soltools/winunistd
-------------
/home/hirano/oo_1.1.1_src/soltools/mkdepend
-------------
/home/hirano/oo_1.1.1_src/soltools/javadep
-------------
/home/hirano/oo_1.1.1_src/soltools/cpp
-------------
/home/hirano/oo_1.1.1_src/soltools/support
-------------
/home/hirano/oo_1.1.1_src/soltools/ldump
-------------
/home/hirano/oo_1.1.1_src/soltools/giparser
-------------
deliver -- version: 1.50.8.2
COPY: ../wntgcci.pro/bin/cpp ->
/home/hirano/oo_1.1.1_src/solver/645/wntgcci.pro/bin/cpp.lcc
deliver: /home/hirano/oo_1.1.1_src/soltools/prj/d.lst: ERROR: can't copy
../wntgcci.pro/bin/cpp: No such file or directory
Statistics:
Files copied: 0
Files unchanged/not matching: 36

vq->khirano:
> COPY: ../wntgcci.pro/bin/cpp ->
> /home/hirano/oo_1.1.1_src/solver/645/wntgcci.pro/bin/cpp.lcc
> deliver: /home/hirano/oo_1.1.1_src/soltools/prj/d.lst: ERROR: can't copy
> ../wntgcci.pro/bin/cpp: No such file or directory

This is normal, deliver doesn't know if the program need .exe or not,
so it tries to copy both. One of the atempts must fail.

How far is your build?

I set up a webpage with a few build instructions, see:
<http://tools.openoffice.org/dev_docs/build_windows_mingw.html>

Changes and corrections are welcome!

I have only built helpcontent, xml2cmp, python, external, soltools, stlport,
freetype, cosv, np_sdk, zlib, jpeg, boost, readlicense_oo, bitstream_vera_fonts,
virgule.

I am not sure I've got the right libmsvcrt.a.

I am still staying at sal.

Making: ../../../wntgcci.pro/bin/uwinapi.dll
guw.pl /cygdrive/c/MinGW/bin/gcc -c
-o../../../wntgcci.pro/slo/uwinapi_version.obj -DWNT  -I../../../wntgcci.pro/inc
/home/hirano/oo_1.1.1_src/solenv/src/version.c
Command: /cygdrive/c/MinGW/bin/gcc
guw.pl rc -DWIN32 -I -I.  -I. -I../inc -I../../../inc -I../../../WIN/inc
-I../../../wntgcci.pro/inc -I.
-I/home/hirano/oo_1.1.1_src/solver/645/wntgcci.pro/inc/stl
-I/home/hirano/oo_1.1.1_src/solver/645/wntgcci.pro/inc/external
-I/home/hirano/oo_1.1.1_src/solver/645/wntgcci.pro/inc
-I/home/hirano/oo_1.1.1_src/solenv/wntgcci/inc
-I/home/hirano/oo_1.1.1_src/solenv/inc -I/home/hirano/oo_1.1.1_src/res
-I/home/hirano/oo_1.1.1_src/solver/645/wntgcci.pro/inc/stl
-I/cygdrive/c/jdk/include/win32 -I/cygdrive/c/jdk/include
-I/cygdrive/c/MinGW/include
-I/cygdrive/c/MinGW/lib/gcc-lib/mingw32/3.3.1/include
-I/cygdrive/c/MinGW/include/c++/3.3.1
-I/cygdrive/c/MinGW/include/c++/3.3.1/mingw32 -I'/cygdrive/c/PSDK/include'    
-I. -I../../../res -I.  ../../../wntgcci.pro/misc/uwinapi_def.rc
Command: rc
fatal error RC1109: 
dmake:  Error code 1, while making '../../../wntgcci.pro/bin/uwinapi.dll'
echo: No match.

ERROR: Error 65280 occurred while making
/home/hirano/oo_1.1.1_src/sal/systools/win32/uwinapi
[hirano@aptiva ~/oo_1.1.1_src/sal]$

> I am not sure I've got the right libmsvcrt.a.
You won't find a problem until linking the big projects: sw,sc,(?).

> Command: rc
> fatal error RC1109: 
Do you google?
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/html/rc1109.asp

Check why.

Thanks VQ,

It says:
Resource Compiler Fatal Error RC1109
error creating resource-name
Could not create specified .RES file. Make sure it is not being created on a
read-only drive. Use the /V option to find out whether the file is being created.

Can this be worked around?  Or is this THE END of my build on Windows98SE?

vq->khirano: I already read that error description, I meant you should
check why rc cannot create that file. ;-)

No idea why this fails for you, sorry.

khirano->vq:

> ../../../wntgcci.pro/misc/uwinapi_def.rc
> Command: rc
> fatal error RC1109:

This means that rc can't compile uwinapi_def.rc because no resources found in
the RC file, and that RES file and OBJ file can not be made.

Can you show me your uwiapi_def.rc?

My uwiapi_def.rc contains only four lines.
#define VERVARIANT 8769
#define ORG_NAME uwinapi.dll
#define INTERNAL_NAME uwinapi
#include "shlinfo.rc"


 

> This means that rc can't compile uwinapi_def.rc because no resources found in
> the RC file, and that RES file and OBJ file can not be made.
? I'm not sure, but I doubt that is true.

> Can you show me your uwiapi_def.rc?
> 
> My uwiapi_def.rc contains only four lines.
> #define VERVARIANT 8769
> #define ORG_NAME uwinapi.dll
> #define INTERNAL_NAME uwinapi
> #include "shlinfo.rc"

#define VERVARIANT 8769
#define ORG_NAME uwinapi.dll
#define INTERNAL_NAME uwinapi
#include "shlinfo.rc"

The same. Do you have a different rc.exe in your path?

I have three rc.exe.

1)$ ls /cygdrive/c/98DDK/bin/win98/bin16/Rc.exe 
/cygdrive/c/98DDK/bin/win98/bin16/Rc.exe
2)$ ls /cygdrive/c/98DDK/bin/win98/rc.exe
/cygdrive/c/98DDK/bin/win98/rc.exe
3)$ ls /cygdrive/c/PSDK/Bin/RC.Exe 
/cygdrive/c/PSDK/Bin/RC.Exe

2) and 3) are in my path.

/cygdrive/c/98DDK/bin/win98/rc.exe is used to compile uwiapi_def.rc.

When I use /cygdrive/c/PSDK/Bin/RC.Exe manually, I was told "upgrade your
Windows system."

tono -> khirano

I have confirmed that 98DDK/bin/win98/rc.exe works on WinXPpro.

I will check if it works on Win98.

Best Regards,

Takashi Ono

tono -> khirano

The rc.exe included in Win98DDK (Version 5.00.1803.1)seems to work well on my 
PC. It never complains with RC1109.

Usually the message "error creating [resource-name]" follows RC1109. What does 
it show at your site?

Takashi Ono

oo_1.1.1_src/sal]$ /cygdrive/c/98DDK/bin/win98/rc.exe
wntgcci.pro/misc/uwinapi_def.rc
fatal error RC1109: 
oo_1.1.1_src/sal]$ 

Unfortunately no message after RC1109.

*** Issue 13889 has been marked as a duplicate of this issue. ***

Hi Everyone,
Long time no see. ;-)

Shall we make a mingw-porting effort for 680 codeline, OpenOffice.org 2.0?
What do you think?
A new issue should be opened for the mingw-porting for 680 codeline?
Any idea?

Hi khirano,

I'm for it, but I'm waiting for a review of the sal patch in issue 29615.

Maybe you could bother Hennes a bit.

Hi, fellas,

I have found out some bugs in my work.

1) Thunking code to unicows.dll in uwinapi was completely not working and 
therefore the code did not work on Win98.

2) Optimization hint to the compiler should not be pentiumpro. I myself am 
still using K6-III machine. It should be pentium.

3) Defining WINVER symbol should be located in CFLAGS make variable, instead 
of in CFLAGSMT, etc. It is overridden in some project and it will not work if 
the definition is in other make variable. It caused no break in building 
because of some errors in MinGW header modification but caused trouble at 
runtime in Win98.

Therefore, I have made some changes in winuser.h MinGW header file, 
solenv/inc/wnt.mk and some files in sal/systools/win32/uwinapi.

I will attach new patch files.

Created attachment 17661 [details]
Patches for MINGW headers (updated September 12,2004)

Created attachment 17662 [details]
Patches for solenv (updated September 12,2004)

Created attachment 17663 [details]
Patches for project source files, delivery lists, map files etc. (Updated Spetember 12, 2004

Tono, great you continue working on this!

But your new patches don't apply to the cws_srx645_mingw branch. Would it be
possible for you to submit the patches against that cvs branch.

This would make the integration much, much easier.

Thanks!

Hi Tono and vq,

I tried an installation set (Japanese) built with MinGW+tcsh by Tono.
Only oleautobridge.uno.dll and so_activex.dll are missing but it works great!
The size of the zipped installation set is 78M, right?, Tono?
This is a great work!

Thanks!

tono->vq

How can I place modification for MinGW headers?

Others are as follows.

cvs -q diff solenv\inc\wnt.mk sal\systools\win32\uwinapi\uwinapi_mingw.dxp 
sal\systools\win32\uwinapi\ResolveThunk.cpp sal\systools\win32
\uwinapi\DllMain.cpp (in directory C:\TEMP\)
Index: solenv/inc/wnt.mk
===================================================================
RCS file: /cvs/tools/solenv/inc/wnt.mk,v
retrieving revision 1.52.26.2.22.4
diff -r1.52.26.2.22.4 wnt.mk
513,515c513,515
< CFLAGS+=-nostdinc
< CFLAGSCC=-pipe -march=pentiumpro
< CFLAGSCXX=-pipe -march=pentiumpro -fno-for-scope -fpermissive
---
> CFLAGS+=-nostdinc -DWIN32 -DWINVER=0x0500 -D_WIN32_IE=0x400
> CFLAGSCC=-pipe -march=pentium
> CFLAGSCXX=-pipe -march=pentium -fno-for-scope -fpermissive
519,524c519,524
< CFLAGSOBJGUIST=-DWIN32 -DWINVER=0x0500 -D_WIN32_IE=0x400 -D_DLL
< CFLAGSOBJCUIST=-DWIN32 -DWINVER=0x0500 -D_WIN32_IE=0x400 -D_DLL
< CFLAGSOBJGUIMT=-DWIN32 -DWINVER=0x0500 -D_WIN32_IE=0x400 -D_MT -D_DLL
< CFLAGSOBJCUIMT=-DWIN32 -DWINVER=0x0500 -D_WIN32_IE=0x400 -D_MT -D_DLL
< CFLAGSSLOGUIMT=-DWIN32 -DWINVER=0x0500 -D_WIN32_IE=0x400 -D_MT -D_DLL
< CFLAGSSLOCUIMT=-DWIN32 -DWINVER=0x0500 -D_WIN32_IE=0x400 -D_MT -D_DLL
---
> CFLAGSOBJGUIST=-D_DLL
> CFLAGSOBJCUIST=-D_DLL
> CFLAGSOBJGUIMT=-D_MT -D_DLL
> CFLAGSOBJCUIMT=-D_MT -D_DLL
> CFLAGSSLOGUIMT=-D_MT -D_DLL
> CFLAGSSLOCUIMT=-D_MT -D_DLL
Index: sal/systools/win32/uwinapi/uwinapi_mingw.dxp
===================================================================
RCS file: /cvs/porting/sal/systools/win32/uwinapi/Attic/uwinapi_mingw.dxp,v
retrieving revision 1.1.2.2
diff -r1.1.2.2 uwinapi_mingw.dxp
63,79c63,79
< DllGetVersion
< CommandLineToArgvW
< CopyFileExA
< CopyFileExW
< CreateToolhelp32Snapshot
< DrawStateW
< EnumProcesses
< GetDiskFreeSpaceExA
< GetDiskFreeSpaceExW
< GetLogicalDriveStringsW
< GetLongPathNameA
< GetLongPathNameW
< GetModuleFileNameExA
< GetModuleFileNameExW
< GetProcessId
< GetUserDomainA
< GetUserDomainW
---
> DllGetVersion@4
> CommandLineToArgvW@8
> CopyFileExA@24
> CopyFileExW@24
> CreateToolhelp32Snapshot@8
> DrawStateW@40
> EnumProcesses@12
> GetDiskFreeSpaceExA@16
> GetDiskFreeSpaceExW@16
> GetLogicalDriveStringsW@8
> GetLongPathNameA@12
> GetLongPathNameW@12
> GetModuleFileNameExA@16
> GetModuleFileNameExW@16
> GetProcessId@4
> GetUserDomainA@8
> GetUserDomainW@8
84,107c84,107
< MoveFileExA
< MoveFileExW
< Process32First
< Process32FirstW
< Process32Next
< Process32NextW
< FindFirstVolumeA
< FindFirstVolumeW
< FindNextVolumeA
< FindNextVolumeW
< FindVolumeClose
< FindFirstVolumeMountPointA
< FindFirstVolumeMountPointW
< FindNextVolumeMountPointA
< FindNextVolumeMountPointW
< FindVolumeMountPointClose
< GetVolumeNameForVolumeMountPointA
< GetVolumeNameForVolumeMountPointW
< DeleteVolumeMountPointA
< DeleteVolumeMountPointW
< GetVolumePathNameA
< GetVolumePathNameW
< SetVolumeMountPointA
< SetVolumeMountPointW
---
> MoveFileExA@12
> MoveFileExW@12
> Process32First@8
> Process32FirstW@8
> Process32Next@8
> Process32NextW@8
> FindFirstVolumeA@8
> FindFirstVolumeW@8
> FindNextVolumeA@12
> FindNextVolumeW@12
> FindVolumeClose@4
> FindFirstVolumeMountPointA@12
> FindFirstVolumeMountPointW@12
> FindNextVolumeMountPointA@12
> FindNextVolumeMountPointW@12
> FindVolumeMountPointClose@4
> GetVolumeNameForVolumeMountPointA@12
> GetVolumeNameForVolumeMountPointW@12
> DeleteVolumeMountPointA@4
> DeleteVolumeMountPointW@4
> GetVolumePathNameA@12
> GetVolumePathNameW@12
> SetVolumeMountPointA@8
> SetVolumeMountPointW@8
Index: sal/systools/win32/uwinapi/ResolveThunk.cpp
===================================================================
RCS file: /cvs/porting/sal/systools/win32/uwinapi/ResolveThunk.cpp,v
retrieving revision 1.3.248.1
diff -r1.3.248.1 ResolveThunk.cpp
99c99,101
< extern "C" extern FARPROC _PfnLoadUnicows;
---
> extern "C" {
> extern HMODULE hModuleUnicowsDLL;
> }
103,106c105
< 	FARPROC	lpfnResult = GetProcAddress( LoadLibraryA( lpLibFileName ), 
lpFuncName );
< 
< 	if ( !lpfnResult )
< 		lpfnResult = GetProcAddress( _PfnLoadUnicows(), lpFuncName );
---
> 	FARPROC	lpfnResult = (((LONG)GetVersion()&0x800000ff) == 0x80000004) ? 
GetProcAddress( hModuleUnicowsDLL, lpFuncName ) : GetProcAddress( LoadLibraryA
( lpLibFileName ), lpFuncName );
Index: sal/systools/win32/uwinapi/DllMain.cpp
===================================================================
RCS file: /cvs/porting/sal/systools/win32/uwinapi/DllMain.cpp,v
retrieving revision 1.3
diff -r1.3 DllMain.cpp
153c153,246
< extern "C" FARPROC _PfnLoadUnicows = (FARPROC)LoadUnicowsLibrary;
---
> extern "C" {
> FARPROC _PfnLoadUnicows = (FARPROC)LoadUnicowsLibrary;
> }
> 
> #ifdef __MINGW32__
> 
> extern "C" {
> 
> typedef void (*func_ptr) (void);
> extern func_ptr __CTOR_LIST__[];
> extern func_ptr __DTOR_LIST__[];
> 
> static void do_startup(void);
> static void do_cleanup(void);
> 
> HMODULE hModuleUnicowsDLL;
> 
> void
> __do_global_dtors (void)
> {
>   static func_ptr *p = __DTOR_LIST__ + 1;
> 
>   /*
>    * Call each destructor in the destructor list until a null pointer
>    * is encountered.
>    */
>   while (*p)
>     {
>       (*(p)) ();
>       p++;
>     }
> }
> 
> void
> __do_global_ctors (void)
> {
>   unsigned long nptrs = (unsigned long) __CTOR_LIST__[0];
>   unsigned i;
> 
>   /*
>    * If the first entry in the constructor list is -1 then the list
>    * is terminated with a null entry. Otherwise the first entry was
>    * the number of pointers in the list.
>    */
>   if (nptrs == static_cast<unsigned long>(-1))
>     {
>       for (nptrs = 0; __CTOR_LIST__[nptrs + 1] != 0; nptrs++)
> 	;
>     }
> 
>   /* 
>    * Go through the list backwards calling constructors.
>    */
>   for (i = nptrs; i >= 1; i--)
>     {
>       __CTOR_LIST__[i] ();
>     }
> 
>   /*
>    * Register the destructors for processing on exit.
>    */
>   atexit (__do_global_dtors);
> }
> 
> static int initialized = 0;
> 
> void
> __main (void)
> {
>   if (!initialized)
>     {
>       initialized = 1;
>       do_startup();
>       __do_global_ctors ();
>     }
> }
> 
> static void do_startup( void )
> {
> 	if (((LONG)GetVersion()&0x800000ff) == 0x80000004)
>         {
> 		hModuleUnicowsDLL = LoadUnicowsLibrary();
> 		if (hModuleUnicowsDLL)
> 			atexit(do_cleanup);
> 	}
> }
> 
> void do_cleanup( void )
> {
> 	FreeLibrary(hModuleUnicowsDLL);
> }
> }
> 
> #endif

Thanks, I will commit the patches later today.

> How can I place modification for MinGW headers?

The patching of the MinGW headers is done by external/mingwheaders, but you
don't need to bother to create a patch for the patchfile there, I will
just replace the old patchfile with the new header patchfile.

Uhh, it looks like I have to resync the cws_srx645_mingw branch to the latest
srx645 milestone ... I hope I find some time soon.

I think this is completed.  PLease add a status.

see last comment

>> ------- Additional comments from waratah
>> I think this is completed.  PLease add a status.
>------- Additional comments from vg
>see last comment
Indeed, that was a question. Three issues this issue depends on are not closed.
Why did you close it?

Retargeting

I have stared to work with 680 codeline.

Currently no significant changes. So many patches are required especially for 
windows only sources. Many are not compatible with gcc or standard c++.

As the number of projects depends on mozilla increased, I am trying to build 
mozzilla as well.

Still OLE and ATL library is the largest issue.

I also tried newer binutils package (2.15.91) but dlltool and windres still 
have the same problems.

For sal issue, I will comment on #29615.



Takashi Ono (tono)

the issue is out-of-date, there are later issues...

close issue