Page 1 of 1

Compiling cygwin setup with rbuild

Posted: Fri Jul 03, 2009 9:15 pm
by jeanmichel.123

I'd like to compile cygwin setup with rbuild, because I do not know how to compile program for windows platform outside of ReactOS rbuild system.

I made one rbuild file, to describe this cygwin setup project. With this file, I can compile each file and most of symbols, but have some link errors. How to solve them are there any missing libraries?

link errors are: undefined reference to `BZ2_bzDecompressEnd@4' undefined reference to `BZ2_bzDecompress@4' undefined reference to `BZ2_bzDecompressInit@12' undefined reference to `IID_IShellLinkA' undefined reference to `CLSID_ShellLink' undefined reference to `IID_IPersistFile' undefined reference to `_imp__vsnprintf'

Posted: Sat Jul 04, 2009 5:57 am
by hto
I believe you should use cygwin's own build system, rather then invent something else. There should be documentation on how to build it.

Re: Compiling cygwin setup with rbuild

Posted: Sat Jul 04, 2009 9:16 am
by jeanmichel.123
I tried it before, but it did not compile as well as with rbuild.

Documentation said:

2) Configure using the following set of options.
$ ./configure -C --disable-shared --host=i686-pc-mingw32 \
--build=i686-pc-cygwin CC="gcc -mno-cygwin" CXX="g++ -mno-cygwin"
If you plan to do any work on the setup build system, you will
probably want to add "--enable-maintainer-mode".

3) $ make

I believe to remember that to use it on linux, I removed the --host=i686-pc-mingw32 and -mno-cygwin. But nothing compiled.

In all cases, I am interested to understand what those errors mean.

Z2_bzDecompressEnd BZ2_bzDecompress BZ2_bzDecompressInit are present in lib/3rdparty/bzip2/ .
So I believe there is only little configuration to change to make it link. Might be some C/C++ mangling issue?

_imp__vsnprintf is required because of a call to vsnprintf. Moreover vsnprintf is yet present in msvcrt. So, why this _imp__ is added at begining of symbol? Does imp mean import?

For the IID_IShellLinkA, CLSID_ShellLink, and IID_IPersistFile, I have no idea what the issue is.

Posted: Sat Jul 04, 2009 10:28 am
by hto
What you tried to do is absolutely wrong. First, the system on which you're building is not i686-pc-cygwin, so do not use --build=i686-pc-cygwin. Second, do not remove --host=i686-pc-mingw32, that's the system for which you're building. Third, CC and CXX should be cross-compilers (mingw32-gcc, mingw32-g++), not the system compilers. Also ensure that cross-compilers and cross-binutils are in your PATH. Fourth, it may be required to build a package in a directory which is different from its source directory.

Re: Compiling cygwin setup with rbuild

Posted: Mon Jul 13, 2009 10:19 am
by jeanmichel.123
I solved those 3 links issues but I am confused with CRT linking.

3 link issues were solved the following
-1-: I do not link any more with the lib/3rdparty/bzlib, which seams to me too much kernel specific.
I prefer to recompile standard bzlib and zlib from the internet.
-2-: I temporary removed lines and 25, so I do not require symbols IID_IShellLinkA, CLSID_ShellLink, and IID_IPersistFile anymore.
-3-: I temporary removed calls to vsnprintf in

Now on unclear bases, rbuild sometimes tries to link with both crt and msvcrt failing with double atexit symbol (in both crt libraries).
Othertimes, it sometimes successfully makes an exe, but this exe fails both winth wine 0.9x and ReactOS.

About redundant crt, I understand that it tries to link with msvcrt as I specified it in my rbuild file. However, I do not understand why it tries to link with some mingw crt... Any idea?

About obtained exe file, I did not investigate it very much. It fails in msvcrt lconv init function under wine, and with a not understandable backtrace under ReactOS.

First, I would like to solve this CRT linking...

Posted: Mon Jul 13, 2009 10:47 am
by hto
If you prefer some nonstandard way of building, than you're on your own…

Re: Compiling cygwin setup with rbuild

Posted: Mon Jul 13, 2009 8:48 pm
by jeanmichel.123
I just discovered how mingw32-ld is launched,
unfortunately it looks like it requires some libraries to support some C++ stuff and entry point.

And I am afraid it is too much complexity for me to understand.
Moreover, I wonder why libmingw32 is from 2007... I am about to wonder if RosBe is correctly installed, but do not know if there is something to check...

I assume the best way is to compile according to your advice, ie according to cygwin documentation, but I believe it is preferable for that method to be run from a windows environment.

Arguments passed to mingw32-ld was such as:

Code: Select all

/usr/RosBE/i386/lib/gcc/mingw32/4.1.3/../../../../mingw32/lib/libstdc++.a \
 /usr/RosBE/i386/lib/gcc/mingw32/4.1.3/libgcc.a \
 /usr/RosBE/i386/lib/gcc/mingw32/4.1.3/../../../../mingw32/lib/libmingw32.a \
 /usr/RosBE/i386/lib/gcc/mingw32/4.1.3/../../../../mingw32/lib/libcoldname.a \
 /usr/RosBE/i386/lib/gcc/mingw32/4.1.3/../../../../mingw32/lib/libmingwex.a \
obj-i386/lib/3rdparty/mingw/mingw_common.a \
obj-i386/dll/win32/user32/libuser32.a \
obj-i386/dll/win32/advapi32/libadvapi32.a \
obj-i386/dll/win32/shell32/libshell32.a \
obj-i386/dll/win32/gdi32/libgdi32.a \
obj-i386/dll/win32/ole32/libole32.a \
obj-i386/dll/win32/ws2_32/libws2_32.a \
obj-i386/dll/win32/comctl32/libcomctl32.a \
obj-i386/dll/win32/msvcrt/libmsvcrt.a \
obj-i386/dll/win32/kernel32/libkernel32.a \
obj-i386/dll/win32/msvcrt/libmsvcrt.a \
obj-i386/lib/debugsup/debugsup_ntdll.a \


-rw-r--r-- 1 root root 3136044 2009-03-30 22:58 /usr/RosBE/i386/lib/gcc/mingw32/4.1.3/libgcc.a
-rw-r--r-- 1 jmg  jmg    80600 2007-08-04 01:08 /usr/RosBE/i386/lib/gcc/mingw32/4.1.3/../../../../mingw32/lib/libcoldname.a
-rw-r--r-- 1 jmg  jmg     7514 2007-08-04 01:08 /usr/RosBE/i386/lib/gcc/mingw32/4.1.3/../../../../mingw32/lib/libmingw32.a
-rw-r--r-- 1 jmg  jmg   278438 2007-08-04 01:08 /usr/RosBE/i386/lib/gcc/mingw32/4.1.3/../../../../mingw32/lib/libmingwex.a
-rw-r--r-- 1 root root 1851140 2009-03-30 22:59 /usr/RosBE/i386/lib/gcc/mingw32/4.1.3/../../../../mingw32/lib/libstdc++.a

Posted: Mon Jul 13, 2009 9:07 pm
by hto
Where are these setup.exe sources, I will try to cross-compile them to see, is it really so difficult.

Re: Compiling cygwin setup with rbuild

Posted: Mon Jul 13, 2009 10:35 pm
by jeanmichel.123
I did not say it is so difficult,

source is here:

Re: Compiling cygwin setup with rbuild

Posted: Tue Jul 14, 2009 6:53 pm
by jeanmichel.123
In fact this «multiple definition of `atexit'» occurs as soon as both c++ and msvcrt are used.
for instance with following rbuild and C++ file:

Code: Select all

<?xml version="1.0"?>
<!DOCTYPE module SYSTEM "../../../tools/rbuild/project.dtd">
<module name="myapp" type="win32cui" installbase="system32" installname="myapp.exe" unicode="no" allowwarnings="true">
        <include base="myapp">.</include>

Code: Select all

#include <stdio.h>
class toto   {    public:
  toto()    {      printf ("hellow world\n");    }
  ~toto()  {      printf ("good bye\n");          }
toto a;  toto z; int r=0;       int main()  {    return r;  }
I just read in the react OS news something which might be related:
«A part of writing an operating system is including all the necessary bits and pieces that software will eventually need. One of these pieces is a C++ runtime library. Currently ReactOS uses the libstdc++ that comes with GCC, but this will not be sustainable if the project hopes to add support for MSVC and possibly other compilers. To that end, KJK::Hyperion has been advocating the inclusion of STLport, an open source C++ library that is compatible with a wide range of compilers. This is still in the discussion and planning stage, but there does not appear to be any major issues with the inclusion. Besides the portability advantage, using STLport would allow the developers to move the Standard Template Library to a DLL instead of the current static library, which would help decrease the size of any C++ heavy applications that might be added to ReactOS. Once support for MSVC is done it might be possible to relax the current rules regarding C++ usage, though risking a break with GCC compatibility will make any such move tricky.»

Posted: Wed Jul 15, 2009 4:25 am
by hto
Successfully cross-compiled that setup.exe. For some reason, setup.exe crashed thrice because was unable to find OpenProcessToken, AllocateAndInitializeSid, and CloseServiceHandle functions in advapi.dll (bug in ntdll.dll?) After commenting out calls to these functions and recompiling, setup.exe started, downloaded packages and installed them, but crashed at the end.