Dear all,
we have successfully ported an application framework (based on CORBA) to
Windows using Cygwin last year. This porting works properly under
Windows XP, but we ran into some problems when we tried to use it under
Windows 7 (32-bits) not long ago.
While compiling ACE/TAO (Initial parts of the compilation work ok), at
some point it tries to execute the (compiled during the process) IDL
compiler tao_idl.exe, which randomly (more often than not) ends up in an
STATUS_ACCESS_VIOLATION message and, some of these times with an
additional comment saying "preprocessor 'g++' returned with an error"
which crashes the application. After this I ran tao_idl.exe by hand,
receiving the same outcome.
First I'll state that this is most probably not BLODA (unless some
default program that comes with W7 provokes it), since I started with a
fresh W7 installation made by myself on which I only installed Java JDK
and Cygwin along with some of its packages.
I've been looking around and found several supposed workaraounds to this
issue:
1.- peflags --tsaware=true app_name.exe
2.- Disable DEP (Data Execution Prevention)
3.- rebaseall -v
4.- rebaseall -v -T list_of_compiled_dlls
From this list only the last solution worked for me, but it is very
uncomfortable to have to run this in the middle of a compilation
process, since, first of all, we need to stop all the cygwin processes.
For ACE/TAO for example this would mean to compile it by sections, maybe
rebasing after each set of DLLs. This would require, for instance, a
batch (.bat or other windows based) script and several bash scripts to
be called by it.
The thing is that later, when compiling Python (we use a specific
version), a similar problem appeared (STATUS_ACCESS_VIOLATION messages
that finish with a "fork: child -1 - died waiting for longjmp before
initialization, retry 0, exit code 8800, errno 11", "error: Resource
temporarily unavailable") when linking using gcc.
Also I would think that the problem is gcc/g++ related due to both
problems comming from it, but in this scenario I can't understand at the
moment why the problem appears only when linking some libs and not
others and why is it solved when using rebaseall providing the list of
DLLs created during compilation time as opposed to doing this with the
system DLLs only.
Considering that the framework has a high number of modules(sets of libs
and executables) I find a problem having to rebaseall after the
compilation of each one.
We use gcc/g++ version (GCC) 4.3.4 20090804 (release) 1
I have three questions that you might ignore if there is an answer for
the underlying problem.
1.- For the external applications such as ACE/TAO or Python. What
can we do to avoid running in the aformentioned problem without having
to rebase in the middle of the compilation process? Looking at the
linker flags of both ACE/TAO and Python, they already use the
-Wl,--enable-auto-image-base linker flag.
2.- Is it enough for the DLLs if they are compiled using the
-Wl,--enable-auto-image-base linker flag? From the outcome I see from
ACE/TAO and Python it seems that it isn't enough. What else can we do?
3.- I know that WXP and W7 are very different, but is there
something specific that causes these problem on W7 and not on WXP? I've
been using Cygwin on WXP for some time and never had to rebase at all.
I prefered to leave out the snippets of code and errors to keep the mail
relatively short. If you want to have a look at any of them or want me
to show the output of a specific command, please let me know.
I appreciate your time reading this post and thank in advance any help
or comment that you might share.
Best regards,
Tomás Staig.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
