Re: Building ORBit2 on Windows

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--34247938-1571750016-1272905493=:2029
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

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. =C2=A0When 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:=20
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\libgmodu=
le-2.0-0.dll
ModLoad: 63a40000 63a86000   Z:\WAM\Windows\ORBit2\test\everything\libgobje=
ct-2.0-0.dll
ModLoad: 65c40000 65c4f000   Z:\WAM\Windows\ORBit2\test\everything\libgthre=
ad-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=3D638fca10 ebx=3D6efcca12 ecx=3D638ec140 edx=3D6efcca00 esi=3D638fc000 =
edi=3D6efc8810
eip=3D7c917c92 esp=3D0022f688 ebp=3D0022f6bc iopl=3D0         nv up ei ng n=
z na po cy
cs=3D001b  ss=3D0023  ds=3D0023  es=3D0023  fs=3D003b  gs=3D0000           =
  efl=3D00010283
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 -=20
7c917c92 890f            mov     dword ptr [edi],ecx  ds:0023:6efc8810=3D6e=
fcc644
0:000> k
ChildEBP RetAddr=20
0022f6bc 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:

=2E.. [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
 =09=09http://www.gtk.org/download-windows.html
=2E..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.


 =09=09=09=09=09-bwb

 =09=09=09=09=09Brent Baccala
 [email protected]
--34247938-1571750016-1272905493=:2029
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
orbit-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/orbit-list
--34247938-1571750016-1272905493=:2029--