--- Oscar Fuentes <ofv@...> wrote: > "Adriano dos Santos Fernandes"
<adrianosf@...> writes:
>
> > I'm create a patch to MinGW gcc 3.1 catch exceptions across EXE/DLLs
> > boundaries.
>
> I can't think of a proper inter-dll exception handling without fixing
> the "GCC 3.1 dynamic_cast fails with DLLs" bug reported by Colin
> Peters:
>
>
http://sourceforge.net/tracker/index.php?func=detail&aid=568054&group_id=2435&atid=102435
>
> Has this problem relation with sharing objects among dlls / exes?
>
Yes, the dynamic_cast issue is critical. Adriano's solution is simple and
really does the same thing as Jason Merrill's. I liked Jason's because it kept
the public interface clean. In any event, the ifdef __MINGW32__ is too
parochial and needs to be extended to other targets (Cygwin, at least,
Interix?, ARM with PE object format?). That is a detail that can be cleaned up
later. Jason's suggestion also fixed problems with multiple shared libs on
other non-PE targets.
> Danny, I saw your post on the gcc ml (which, sadly, seems that didn't
> attracted too much attention, at least on-line) and know you have a
> possible solution. Do you think that Adriano's approach is useful for
> the dynamic_cast issue? His solution is really simple and
> straightfordward.
It works.
Other details that needs to be sorted are (1) how to prevent adding the
overhead when -fno-exceptions is given explicitly or we are using C or Fortran
or other language where no-exceptions is the default (2) thread safety (3)
overhead when using static linkage. I'm still not convinced that this
approach is prefereable to a libgcc_s.dll approach.
What do others think?
Cheers
Danny
>
> Clueless,
Clue-challenged?
>
> --
> Oscar
>
http://www.sold.com.au - SOLD.com.au
- Find yourself a bargain!

I think I didn't make my self clear. I am not working under gnu
environment , that is , I don't use gnu c++ runtime , just using the gcc
compiler , I need to construct my own run time library, like crt0, so I
think I have to care about static variables initialization. Any ideas?
-----Original Message-----
From: Stephen M. Webb [mailto:stephenw@...]=20
Sent: =D0=C7=C6=DA=CE=E5 2002 06 28 23:52
To: longchuan; mingw-users@...
Subject: Re: [Mingw-users] about
__CTOR_LIST__,__CTOR_END__,__DTOR_END__,__DTOR_END__
Those symbols are a part of the C++ runtime. The only time you should=20
need to concern yourself about them is if you're hacking the C++=20
compiler or runtime yourself. You might want to start with a simpler=20
portion of the compiler if that's your interest.
The static variable construction takes place before main() is called,=20
and the compiler takes care of calling your statioc constructors and=20
destructors. You don't need to call them directly.

On June 28, 2002 10:05 am, longchuan wrote:
> Hello :
> Anyone tell some thing about
> __CTOR_LIST__,__CTOR_END__,__DTOR_END__,__DTOR_END__?
> Seems that I need to use those function pointers to
> perform static variables' initialization in __main. But I am not
> sure how they work with compiler . I copy a piece of code from gcc
> source libgcc.c to my lib source :
Those symbols are a part of the C++ runtime. The only time you should
need to concern yourself about them is if you're hacking the C++
compiler or runtime yourself. You might want to start with a simpler
portion of the compiler if that's your interest.
The static variable construction takes place before main() is called,
and the compiler takes care of calling your statioc constructors and
destructors. You don't need to call them directly.
An example might be as follows.
#include <iostream>
class StaticClass
{
public:
StaticClass() { std::cout << "StaticClass constructor\n"; }
~StaticClass() { std::cout << "StaticClass destructor\n"; }
};
StaticClass staticObject;
int
main(int argc, char* argv[])
{
std::coutr << "main()\n";
}
Build this using the g++ command so the C++ runtime is linked in ("g++
-o demo.exe demo.cpp"), run it, and the console output should be as
follows.
StaticClass constructor
main()
StaticClass destructor
> I wonder how the compiler considers the four variables, how it assigns
> static variables' constructors or destructor to the 4 points . Could
> anyone tell me or show me some documents or codes about that .
> I am working on win2k ,mingw gcc3.1 ,target is ix86.
To understand how the compiler knows to do this you'll have to study
all the gcc sources as well as the C++ library sources. I would
recommend at this point you simply trust it to do the right thing.
--
Stephen M. Webb

On Fri, Jun 28, 2002 at 03:15:46PM +0300, Nicolas Boretos wrote:
>Hi,
>
>A novice cross-compiler here.
>
>While trying to cross-compile some stuff (SUSE linux),
>
>I get thefollowing error
>
>ld" unrecognized option '--subsystem'
>ld use the --help option for usage
>
>/opt/mingw/bin/i386-mingwmsvc-dllwrap /opt/mingw/bin/i386-mingwmsvc-gcc
>exited with status 1
>make: ** [stublib] error 1
>
I don't know how this is happening (you didn't gave the command line..)
but it seems i386-mingwmsvc-dllwrap (or gcc) is using your system ld instead of
i386-mingwmsvc-ld. At any rate you can override which one is used by
careful (I don't recall which :) chosen options.
>If I take out the -mwindows from dllwrap I then get
>
>
>unrecognized option --base-file
>
>Dont know what this means...
>
>Anyway, I probably dont want to do this anyway...
>
>help would be appreciated...
José Fonseca

Hi,
A novice cross-compiler here.
While trying to cross-compile some stuff (SUSE linux),
I get thefollowing error
ld" unrecognized option '--subsystem'
ld use the --help option for usage
/opt/mingw/bin/i386-mingwmsvc-dllwrap /opt/mingw/bin/i386-mingwmsvc-gcc
exited with status 1
make: ** [stublib] error 1
If I take out the -mwindows from dllwrap I then get
unrecognized option --base-file
Dont know what this means...
Anyway, I probably dont want to do this anyway...
help would be appreciated...
regards,
nicolas boretos

Hello all!
Brian Palmer wrote:
> Another issue I am having with MinGW is that I specify my targets in
> the Makefile without the .exe suffix so that the same Makefile will
> work under Linux. I also don't specify the .exe suffix on the command
> line to gcc. DJGPP solves this problem by generating two outputs -
> "targetname" & "targetname.exe". MinGW just outputs "targetname.exe"
> which breaks the Makefile so that it always rebuilds the target. Can
> anyone suggest a solution to this?
Try with this Makefile. It works for me. Probably there are better/more
elegant solutions than this:-)
--- Makefile -------------------------
CC = gcc
CFLAGS = -Wall -s
RM = rm
# Testing for Win32
ifdef COMSPEC
exeext = .exe # Win32
else
exeext = .noexe # Just to see that it works on linux
#exeext = # Linux
endif
SRC = $(wildcard *.c)
TARGETS = $(SRC:.c=$(exeext))
all: $(TARGETS)
%$(exeext): %.c
$(CC) $(CFLAGS) -o $@ $<
clean:
-$(RM) -f *$(exeext)
--- end Makefile --------------------------
Hope it helps!
Francisco

----- Original Message -----=20
From: Brian Palmer=20
To: mingw-users@...=20
Sent: Thursday, June 27, 2002 1:31 PM
Subject: [Mingw-users] MinGW won't generate a valid binary image
I am writing a boot manager and I want it to be able to compile under =
all intel versions of gcc. It works fine under every port except the =
MinGW port. MinGW compiles and links the executable fine. But when I =
objcopy it to a binary file and try to boot it it just hangs somewhere =
in the code. Has anyone been able to generate a binary image from MinGW? =
If someone would like to take a look at my code or Makefile I will mail =
it to them.
=20
Another issue I am having with MinGW is that I specify my targets in =
the Makefile without the .exe suffix so that the same Makefile will work =
under Linux. I also don't specify the .exe suffix on the command line to =
gcc. DJGPP solves this problem by generating two outputs - "targetname" =
& "targetname.exe". MinGW just outputs "targetname.exe" which breaks the =
Makefile so that it always rebuilds the target. Can anyone suggest a =
solution to this?
You can define a macro (e.g., EXT) which is set to ".exe" for the =
Micro$oft world, and to nothing for the
unix world, and append that macro to your target name.=20
I am not subscribed to this mailing list so please copy me on all =
replies.
=20
Thanks
Brian

I am writing a boot manager and I want it to be able to compile under
all intel versions of gcc. It works fine under every port except the
MinGW port. MinGW compiles and links the executable fine. But when I
objcopy it to a binary file and try to boot it it just hangs somewhere
in the code. Has anyone been able to generate a binary image from MinGW?
If someone would like to take a look at my code or Makefile I will mail
it to them.
Another issue I am having with MinGW is that I specify my targets in the
Makefile without the .exe suffix so that the same Makefile will work
under Linux. I also don't specify the .exe suffix on the command line to
gcc. DJGPP solves this problem by generating two outputs - "targetname"
& "targetname.exe". MinGW just outputs "targetname.exe" which breaks the
Makefile so that it always rebuilds the target. Can anyone suggest a
solution to this?
I am not subscribed to this mailing list so please copy me on all
replies.
Thanks
Brian

This may be a silly mistake on my part, as I've never tried creating
DLLs before.
I'm trying to compile a DLL with mingw that contains
DllRegisterServer(). I have a precompiled version (probably built
with VC++) on which I can happily run "regsvr32 csp.dll". regsvr32
succeeds, and everything works fine.
When I compile the same source with mingw, I get mangled symbols --
DllRegisterServer@... instead of DllRegisterServer. When I run
regsvr32 csp.dll on the mingw dll, I get an error:
csp.dll was loaded, but the DllRegisterServer entry point was not
found.
=20
DllRegisterServer may not be exported, or a corrupt version of
csp.dll may be in memory. Consider using PView to detect and remove
it.
There is no C++ source in the DLL, and I am running only gcc, not
g++. I believe that this means that there should be no name mangling
going on. The commands run are:
gcc -I../sdkinc -c -o csp.o csp.c
gcc -I../sdkinc -c -o autoreg.o autoreg.c
dllwrap --export-all-symbols --output-def newcsp.def csp.o autoreg.o\
-o csp.dll
The newcsp.def file contains an EXPORTS section with all the function
names in the dll, but all mangled, ending in '@' followed by an
integer. So the symbols are being exported, and presumably the reason
regsvr32 can't find DllRegisterServer is because of the name mangling.
Does anyone have any ideas? Can I disable name mangling somehow? Or
am I completely wrong about the name mangling being the cluprit?
Thanks in advance for your assistance. CCs would be appreciated, as
I'm not a regular subscriber.
--=20
Best of luck,
Mark Schreiber

"Sternbach, William [IT]" <william.sternbach@...> writes:
> Hello,
>
> I am currently using the old version of gcc version 2.95.3_6.
>
> It seems to be very stable and bulletproof.
>
> How does the new version of gcc version 3 compare with the
> older gcc version 2.95.3_6 in terms of number of bugs the compiler has?
Well, speaking as a C++ programmer, it's quite better than
2.95. However, I don't care about "bugs", I care about *my* bugs :-)
I'm trying to say that you should take a look at the gcc bug database
available from gcc.gnu.org for checking that there are no known
showstoppers on the features you use.
> What are the advantages of upgrading to gcc 3?
Again, as a C++ programmer:
1. Improved C++ standards compliance.
2. Better code generation.
3. The compiler is from 2 to 4 times slower, so you can take longer
coffe breaks <grin>
There are some MinGW specific issues when exporting certain kind of
classes in dll's. Somehow I thought that this problem existed on gcc
2.95.x too, but as it seems that it's the principal bug that keeps gcc
3.1 from being released officialy, I may be wrong.
--
Oscar

Hi,
we need a canadian cross gcc. It should run under Win32 plattforms and genrate code
for an embedded PowerPC linux target.
Normally I never would ask such a question since native developement or a least under Linux
is my favorite, but now an application requires developement under Win32.
1) Are there any binary distribution available that could help me ?
2) Did anybody build such a gcc in the last time ?
3) Is it hard ? :-)
4) Where can I get some hints ?
Matthias

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details