youda008 | 27 Jul 17:33 2015
Picon

-mwindows command line option for g++

Hi.
Can anyone explain me, what a g++ command line option "-mwindows" does? My IDE CodeBlocks adds it to the flags when compiling a project for some reason, and it ruins the final program. When i write a custom Makefile and delete this option, application works.
------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@...?subject=unsubscribe
Адель Хафизова | 26 Jul 00:45 2015
Picon

OpenMP static build (link pthread statically), what's the alternative?

I apologise very much for the late reply, I didn't have much access to the computer lately.
So, one more time.
I tried to create an .exe without any additional DLL dependencies so that OpenMP program could be launched on other Windows machines. To do so I compiled pthread statically with command:
make clean GC-static
Nevertheless, it produced libpthread-static.a, which size is 95 KB (to my mind, it is too small to be a full static library, it seems to be a wrapper, which calls in turn pthreadGC2.dll). 
The problem is just the same with undefined references to _imp__* while compiling via

ln.exe -s `g++ -print-file-name=libgomp.a`

g++ openmp.cpp -o openmp.exe -static -static-libgcc -static-libstdc++ -fopenmp -L.

Doing this

ln.exe -s `g++ -print-file-name=libgomp.a`

g++ openmp.cpp -o openmp.exe -static-libgcc -static-libstdc++ -fopenmp -L.

gives openmp.exe which is dependent from pthreadGC2.dll. The static library corresponding to pthreadGC2.dll should be libpthread.a or libpthread-static.a or something like that, but all attempts to create a truly static library end up with having the little wrapper library (as I suppose) which continues to call pthreadGC2.dll.

I definitely misunderstand something but still can't figure out what.

The source code is nothing special, just an example from the Internet

http://pastebin.com/r4pU7tsG

2015-07-02 3:58 GMT+04:00 Sergio NNX <sfhacker-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org>:
> Unfortunately, there are no updates, there are still undefined references errors which were described in
> the very first post.
I see. What's the alternative then?
I could have a 'closer' look at it. Can you provide a simple test source code in order to reproduce the problem?

Cheers.



--
Best regards,
Adel Khafizova


--
Best regards,
Adel Khafizova

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@...?subject=unsubscribe
Oleksiy Ch | 15 Jul 06:40 2015
Picon

what macros are generated by Mingw?

Hello,

I have a script that tests basic compiler parameters like name, version, standards compliance. I use a
simple header file with #ifdef statements.

>From the table at http://sourceforge.net/p/predef/wiki/Compilers/
there is only one macro '__MINGW32__' generated by Mingw that identifies it. Other version descrption
macros are included from headers "<stdlib.h>, <stdio.h>, <windows.h>, <windef.h>, and probably more".

Question. Are there version description macros generated by Mingw compiler itself, as other compilers
do, without the need to include any headers? And what are other compiler description macros generated by Mingw?

I'm not aware about the reason of including compiler related macros into system headers that have no
relation to a compiler itself, as far as I know. I think it may cause problems of identifying the compiler in
situation when I want to use different C library and/or don't want to include headers for some reason. If,
for example, I want to link with uClibc, I pass '-I/my_home/uClibc/include', Mingw loads different
headers that has no '__MINGW32_MAJOR_VERSION' and '__MINGW32_MINOR_VERSION' macros.

Thanks.
Oleksiy

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@...?subject=unsubscribe

Maxim Blumental | 12 Jul 02:50 2015
Picon

Conflicts in headers from mingw/include

Hello everyone!

I have a problem with my mingw which I faced when tried to build
libiconv. I got following errors:

c:\mingw\include\unistd.h:109:5: error: conflicting types for 'nanosleep'
 int nanosleep( const struct timespec *period, struct timespec *residual )
     ^
c:\mingw\include\unistd.h:105:5: note: previous declaration of
'nanosleep' was here
 int nanosleep( const struct timespec *, struct timespec * );

In the unistd.h header there is a line including time.h (105) and a
line which again declares it (109) which causes the conflict.
I installed only basic setup proposed by GUI mingw-get (specifically,
mingw32-base, g++, fortran) and msys 1.0.11 (not via gui).

So, what would you propose me to do? How can I cure the conflict in headers?
-- 

---------------------
Sincerely yours,
Maxim Blumental

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@...?subject=unsubscribe

Andrew Spencer | 10 Jul 19:14 2015
Picon

Linking MS-MPI with MinGW (gfortran)

I am trying to cross-compile my MPI application, prog.exe, from Linux to Windows using a 32bit MinGW cross-compiler. I am trying to link with Microsoft-MPI.

To get my code to compile and link without complaints, in mpi.f90, I replaced INT_PTR_KIND() with 4 (or 8 yields the same results), then compile mpi.f90 with the flag -fdefault-integer-8. Then I link the resulting mpi.o file with my MPI application.

My MPI application now compiles and links without any complaints, but when I try to run the resulting executable under Windows (64bit 8.1 Pro), I get the error message "The procedure entry point mpi_init__ could not be located in the dynamic link library E:\prog.exe". Does anyone know what this means, and why I would get this message when the linker does not complain?

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@...?subject=unsubscribe
Varun Agrawal | 5 Jul 00:35 2015

Why program in MSYS depends upon msys-1.0.dll

Hi,

I am learning more about MinGW and I have a question regarding it.
MinGW compiled programs are supposed to run native without POSIX
emulation. So why all programs in msys package depends upon
"msys-1.0.dll"? The file description says "POSIX Emulation DLL".
Shouldn't they work without any external DLL?

Regards
Varun Agrawal

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@...?subject=unsubscribe

Edward Diener | 2 Jul 02:21 2015

Possibly wrong declarations for CryptEnumProviders in wincrypt.h

In the latest w32api-4.0.3-1-mingw32 in the wincrypt.h file the 
declarations for CryptEnumProviders are:

WINADVAPI BOOL WINAPI 
CryptEnumProvidersA(DWORD,DWORD*,DWORD,DWORD*,LPTSTR,DWORD*);
WINADVAPI BOOL WINAPI 
CryptEnumProvidersW(DWORD,DWORD*,DWORD,DWORD*,LPTSTR,DWORD*);

Should not the declarations be :

WINADVAPI BOOL WINAPI 
CryptEnumProvidersA(DWORD,DWORD*,DWORD,DWORD*,LPSTR,DWORD*);
WINADVAPI BOOL WINAPI 
CryptEnumProvidersW(DWORD,DWORD*,DWORD,DWORD*,LPWSTR,DWORD*);

?

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@...?subject=unsubscribe

Picon

Re: OpenMP static build (link pthread statically), any update?

Unfortunately, there are no updates, there are still undefined references errors which were described in the very first post. 

понедельник, 29 июня 2015 г. пользователь Sergio NNX написал:

Any update on this matter?

> Date: Thu, 25 Jun 2015 17:36:39 +0300
> From: eliz-mXXj517/zsQ@public.gmane.org
> To: mingw-users-5NWGOfrQmnegEbju0hdhLg@public.gmane.orgorge.net
> Subject: Re: [Mingw-users] OpenMP static build (link pthread statically)
>
> > Date: Thu, 25 Jun 2015 15:08:48 +0400
> > From: Адель Хафизова
> > <adelkhafizova-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >
> > I tried building pthreads statically with
> > make clean GC-static
> > The result was the same: libpthread.a produced with this build when linked
> > without -static gives pthreadGC2.dll dependency, with -static option it doesn't
> > link. Could you please give a general overview what to do to make this work?
>
> Please provide the details regarding "with -static option it doesn't
> link". What happens if you try? If there are error messages, please
> show them.


--
С уважением, 
Адель Хафизова

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@...?subject=unsubscribe
helferthomas | 29 Jun 16:05 2015
Picon

GetProcAdress can't find a symbol in a mingw generated library

Hi,

my name is Thomas Helfer. I am working on a code generator named mfront (http:/tfel.sourceforge.net). I
mostly work on POSIX systems and have few experience with windows development (no one is perfect).

I have found an interesting trouble while porting my software using MinGW. If my dll contains two exported
symbols named umatelasticty_BehaviourType and umatelasticity2_BehaviourType, then I can not use
GetProcAdress on the second symbol (missing symbols error message) and of course I can call it on the first
one without trouble. Tools like dlldepends, objdump does not show any significant difference between
those two symbols.

Things get more interesting if I remove the source defining the first symbol. In this case, everything
works fine.

If needed, I can send a copy of the dll or any details if required to go further.

However, I though those first hints may help someone to the solution to my problem.

Thank for any help,

Sincerly,

Helfer Thomas

------------------------------------------------------------------------------
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical & virtual servers, alerts via email & sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@...?subject=unsubscribe

Адель Хафизова | 23 Jun 16:01 2015
Picon

OpenMP static build (link pthread statically)

Hi,
I am trying to build an OpenMP program statically with MinGW32 4.8.1.
Building it dynamically worked fine and I decided to get rid of dependencies.
objdump -p openmp.exe | grep.exe DLL


DLL Name: KERNEL32.dll 
DLL Name: msvcrt.dll 
DLL Name: msvcrt.dll 
DLL Name: libgcc_s_dw2-1.dll 
DLL Name: libgomp-1.dll 
DLL Name: libstdc++-6.dll 

After building with this command 

ln.exe -s `g++ -print-file-name=libgomp.a`

g++ openmp.cpp -o openmp.exe -static-libgcc -static-libstdc++ -fopenmp -L.

I got the following set of DLL's

DLL Name: pthreadGC2.dll 
DLL Name: KERNEL32.dll 
DLL Name: msvcrt.dll 
DLL Name: msvcrt.dll 

At this point I can't get rid of pthreadGC2.dll. Linking statically either makes no effect (.exe file still needs pthreadGC2.dll) or fails with errors:

ln.exe -s `g++ -print-file-name=libgomp.a`

g++ openmp.cpp -o openmp.exe -static-libgcc -static-libstdc++ -fopenmp -L.

C:\for_openmp_test/libgomp.a(env.o):(.text.startup+0xbfe): undefined reference to `_imp__pthread_attr_init'
C:\for_openmp_test/libgomp.a(env.o):(.text.startup+0xc13): undefined reference to _imp__pthread_attr_setdetachstate'
C:\for_openmp_test/libgomp.a(env.o):(.text.startup+0x3c): undefined reference to '_imp__pthread_attr_setstacksize'

After searching through the mailing list I have come across several possible solutions, but the treads are rather old.
My questions are:

1. Do I still need to somehow compile pthread statically? And libpthreadGC2.a is not actually a static library? If so, is there an updated instruction?

2. Are there any other libraries I need to actually make this work? In Linux it is said that pthread needs to be included with libc.a and won't link without it.

Thank you in advance. 

------------------------------------------------------------------------------
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical & virtual servers, alerts via email & sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@...?subject=unsubscribe
Ben Firth | 11 Jun 12:22 2015
Picon

Fortran DLL called by VBA crashing Excel

Hi,

I'm having trouble with some Fortran I've compiled as a DLL. When I call it via VBA, it crashes Excel instantly. The original Fortran is quite large, and requires a licence to some of it, so I've thrown together a simple function. It also crashes, although the crash isn't instant now - it manages to cycle through the "Excel has stopped working" messages. 

I think the original Fortran should work, because if I change the Function declaration to a Program, replace the function line with a command to write the value to an output file, and compile as .exe, it works. The same goes for my simple code.

My simple code is times2.for:

 FUNCTION TIMES2(VBANUM)
 REAL*8:: TIMES2, VBANUM
 !GCC$ ATTRIBUTES DLLEXPORT :: TIMES2
 !GCC$ ATTRIBUTES STDCALL :: TIMES2  
 TIMES2 = VBANUM * 2.
 END FUNCTION TIMES2

The minGW commands I used are as follows:

gfortran -fno-underscoring -c times2.for
gfortran -fno-underscoring times2.o -shared -o doubling.dll -Wl,--kill-at

Then the VBA is below:

Public Declare Function times2 Lib "C:\F\doubling.dll" (ByVal VBANUM As Double) As Double
Sub Twice()
Dim a As Double
a = Cells.Range("A1").Value
Cells.Range("A1").Value = times2(a)
End Sub

Now, I'm OK with VBA, have no experience with DLLs or minGW, and am trying to recall rudimentary Fortran that I learned 10 years ago, so take it slow, if you can.

Thanks for reading!
Ben
------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@...?subject=unsubscribe

Gmane