Re: Building ORBit2 on Windows

From: Brent Baccala <cosine freesoft org>
To: orbit-list gnome org
Subject: Re: Building ORBit2 on Windows
Date: Mon, 03 May 2010 12:51:33 -0400 (EDT)

On Mon, 3 May 2010, Tor Lillqvist wrote:

I'm in the midst of implementing DII, so a distributed binary isn't good enough.


I don't understand what you mean with that? *what* distributed binary
isn't good enough for *what* purpose?


Well, I'm thinking of something like the files here:

http://ftp.gnome.org/pub/GNOME/binaries/win32/ORBit2

(which I've never tried to use), since my purpose is to implement DII,
so I need to modify the ORBit2 library itself.

4. Symlink all the DLLs into a .libs directory and add it to the path:


That is a quite strange thing to do. Firstly, there aren't really any
symlinks in the Unix sense on Windows, so what the "ln -s" command in
MSYS does is just create a copy. (In my personal opinion, it is
misleading to even provide such a "fallback" ln command. Reasonable
scripts and other mechanisms know that there are no symlinks on
Windows and do not even attempt to run ln -s.)


I'm using an SMB mount onto my Linux file system, so they actually are
symlinks.

5. Test it

make check


"make check" is supposed to be runnable right after building, without
having to "make install" first. (But like so many things when adapting
Unix-based tools to Windows, it is not necessarily always like that,
due to bugs in various places. Often it indeed is best to make sure
the DLLs that one have built are in PATH, even if that is supposed to
be automatically taken care of by the "make check" mechanisms.)


That was my whole reason for doing the symlinks.  Stick a bunch of
symlinks in one directory (on the Linux side), add it to the PATH (on
the Windows side), and then I've got all of my DLLs for "make check".

At this point, I can't start the server in test/everything.  When I
try to run it by hand, I get "The application failed to initialize
properly (0xc0000005)".


I *think* that could mean there is something seriously wrong happening
in the DllMain() code. Try add debugging printouts in it (in
src/orb/orb-core/corba-orb.c). On the other hand, if you are using the
master or ORBit2, the DllMain() is extremely simple (as DllMain
functions are supposed to be) and can't really be causing this
trouble. Maybe what it means is just that some DLL is missing from
PATH.


Here's more of what I've found out.  I installed the Windows debugging
tools and the Windows symbol tables, and they produced the following:

CommandLine: Z:\WAM\Windows\ORBit2\test\everything\server.exe
Symbol search path is: C:\WINDOWS\Symbols;c:\windows\symbols\dll

Executable search path is:ModLoad: 00400000 00455000 image00400000

ModLoad: 7c900000 7c9af000   ntdll.dll
ModLoad: 7c800000 7c8f6000   C:\WINDOWS\system32\kernel32.dll
ModLoad: 6efc0000 6efe9000   Z:\WAM\Windows\ORBit2\test\everything\libORBit-imodule-2-0.dll
ModLoad: 638c0000 639e8000   Z:\WAM\Windows\ORBit2\test\everything\libORBit-2-0.dll
ModLoad: 77dd0000 77e6b000   C:\WINDOWS\system32\ADVAPI32.DLL
ModLoad: 77e70000 77f02000   C:\WINDOWS\system32\RPCRT4.dll
ModLoad: 77fe0000 77ff1000   C:\WINDOWS\system32\Secur32.dll
ModLoad: 685c0000 686c2000   Z:\WAM\Windows\ORBit2\test\everything\libglib-2.0-0.dll
ModLoad: 77c10000 77c68000   C:\WINDOWS\system32\msvcrt.dll
ModLoad: 774e0000 7761d000   C:\WINDOWS\system32\OLE32.dll
ModLoad: 77f10000 77f59000   C:\WINDOWS\system32\GDI32.dll
ModLoad: 7e410000 7e4a1000   C:\WINDOWS\system32\USER32.dll
ModLoad: 7c9c0000 7d1d7000   C:\WINDOWS\system32\SHELL32.DLL
ModLoad: 77f60000 77fd6000   C:\WINDOWS\system32\SHLWAPI.dll
ModLoad: 71ab0000 71ac7000   C:\WINDOWS\system32\WS2_32.DLL
ModLoad: 71aa0000 71aa8000   C:\WINDOWS\system32\WS2HELP.dll
ModLoad: 6dd00000 6dd0f000   Z:\WAM\Windows\ORBit2\test\everything\libgmodule-2.0-0.dll
ModLoad: 63a40000 63a86000   Z:\WAM\Windows\ORBit2\test\everything\libgobject-2.0-0.dll
ModLoad: 65c40000 65c4f000   Z:\WAM\Windows\ORBit2\test\everything\libgthread-2.0-0.dll
(d18.cd0): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=638fca10 ebx=6efcca12 ecx=638ec140 edx=6efcca00 esi=638fc000 edi=6efc8810
eip=7c917c92 esp=0022f688 ebp=0022f6bc iopl=0         nv up ei ng nz na po cy
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010283
ntdll!LdrpSnapThunk+0xe1:

*** ERROR: Symbol file could not be found. Defaulted to export symbols for Z:\WAM\Windows\ORBit2\test\everything\libORBit-imodule-2-0.dll -7c917c92 890f mov dword ptr [edi],ecx ds:0023:6efc8810=6efcc644

0:000> k

ChildEBP RetAddr0022f6bc 7c91cfbc ntdll!LdrpSnapThunk+0xe1

0022f740 7c91d2fb ntdll!LdrpSnapIAT+0x20e
0022f76c 7c91d274 ntdll!LdrpHandleOneOldFormatImportDescriptor+0xcc
0022f784 7c91c1ce ntdll!LdrpHandleOldFormatImportDescriptors+0x1f
0022f800 7c91d7c6 ntdll!LdrpWalkImportDescriptor+0x19e
0022fa50 7c91d2cd ntdll!LdrpLoadImportModule+0x1c8
0022fa80 7c91d274 ntdll!LdrpHandleOneOldFormatImportDescriptor+0x5e
0022fa98 7c91c1ce ntdll!LdrpHandleOldFormatImportDescriptors+0x1f
0022fb14 7c921e25 ntdll!LdrpWalkImportDescriptor+0x19e
0022fc94 7c92108f ntdll!LdrpInitializeProcess+0xe02
0022fd1c 7c90e437 ntdll!_LdrpInitialize+0x183
00000000 00000000 ntdll!KiUserApcDispatcher+0x7

Now, I'm not quite sure how to read this.  Was it trying to load
libgthread when it died, or had it already loaded libgthread and was
on to the next thing?  In any event, libgthread (and everything else)
looks fine in DLL Walker.

I tried moving all of the symlinks to a subdirectory and then moving
them back one at a time.  At each step, I got a complaint like
"This application has failed to start because ***.dll was not found."
As soon as I got past gthread, it was back to the "0xc0000005" message.

In any event, this result led me to try building glib to see if it
would pass its "make check".  It doesn't get past configure:

... [snip] ...
checking for libintl.h... yes
checking for ngettext in libc... no
checking for bindtextdomain in -lintl... yes
checking for ngettext in -lintl... yes
checking for dgettext in -lintl... yes
checking for bind_textdomain_codeset... yes
checking for msgfmt... no
configure: error:
*** You must have either have gettext support in your C library, or use the
*** GNU gettext library. (http://www.gnu.org/software/gettext/gettext.html

Yes, I've installed gettext-runtime-0.17-1.zip and
gettext-runtime-dev-0.17-1.zip as listed at
		http://www.gtk.org/download-windows.html
...the same place where I got the binary DLLs for glib/gobject/gthread.

I guess another tack is to try compiling ORBit2 with older distributed
versions of the glib DLLs and see if it starts working at some point.


					-bwb

					Brent Baccala
					cosine freesoft org

Follow-Ups:
- Re: Building ORBit2 on Windows
  - From: Tor Lillqvist

References:
- Building ORBit2 on Windows
  - From: Brent Baccala
- Re: Building ORBit2 on Windows
  - From: Tor Lillqvist

[Date Prev][Date Next] [Thread Prev][Thread Next] [Thread Index] [Date Index] [Author Index]