mingw-users Mailing List for MinGW - Minimalist GNU for Windows

Hi,

I'm trying to send a SIGINT signal to a simple test program while 
debugging, but I can't make gdb to send the signal to it.

The following is the test program:

//  testsig.cpp ---------------------------------------------------------

#include <cstdio>
#include <signal.h>

static bool loop;
static void sigfunc(int);

int main(int argc, char **argv) {
    loop = true;
    if (signal(SIGINT,sigfunc) == SIG_ERR) {
        printf("Could not setup signal handler for SIGINT!\n");
        return -1;
    }
    printf("Waiting for SIGINT. Press Ctrl+C to exit.\n");
    while (loop);
    return 0;
}

static void sigfunc(int signo) {
    if (signo == SIGINT) {
        printf("SIGINT received!\n");
        loop = false;
    }
}

//--------------------------------------------------------------

The program works as expected when run in a console, it catches the 
Ctrl+C signal and correctly exits after printing "SIGINT received!".
But when I run it inside gdb, it doesn't receive the signal at all. I 
did tell gdb to let SIGINT pass, with no success.

The following is what I did in a debug session:

E:\Documentos\cpp\testescpp>gdb Debug\testsig.exe
GNU gdb 6.7.50.20071127
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(gdb) handle SIGINT pass
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) y

Signal        Stop      Print   Pass to program Description
SIGINT        Yes       Yes     Yes             Interrupt
(gdb) run
Starting program: E:\Documentos\cpp\testescpp/Debug\testsig.exe
Waiting for SIGINT. Press Ctrl+C to exit.
(Ctrl+C pressed...)
Program received signal SIGINT, Interrupt.
[Switching to thread 3840.0xf08]
0x7c87534d in KERNEL32!GetConsoleCharType (Quit (expect signal SIGINT 
when the p
rogram is resumed)
(gdb) signal SIGINT
Continuing with signal SIGINT.
(Ctrl+C pressed...)
Program received signal SIGINT, Interrupt.
[Switching to thread 3840.0xf08]
0x7c87534d in KERNEL32!GetConsoleCharType (Quit (expect signal SIGINT 
when the p
rogram is resumed)
(gdb) continue
Continuing.
(Ctrl+C pressed...)
[Switching to thread 3840.0xf1c]
0x7c810659 in KERNEL32!CreateThread () from 
D:\WINDOWS\system32\kernel32.dll
Quit (expect signal SIGINT when the program is resumed)
(gdb) info handle
Signal        Stop      Print   Pass to program Description

SIGHUP        Yes       Yes     Yes             Hangup
SIGINT        Yes       Yes     Yes             Interrupt
[...]
(gdb) kill
Kill the program being debugged? (y or n) y
(gdb) quit



So, I just can't send SIGINT to the program. But I'm no gdb expert, 
maybe I'm doing something wrong.

Does anyone know how to make it work?

Thanks,

Rafael Fernandes.

On Monday 31 March 2008 03:49, Erik de Castro Lopo wrote:
> Finally, for ftruncate(), there is a chsize() function that basically
> does the same, but it doesn't work for files larger than 2Gig.

There is an ftruncate() implementation in libmingwex.a, (which is a 
standard MinGW component library).  Danny added it, mid-2004, IIRC.  It 
too would likely have the 2Gb file size limitation, since I think it 
uses chsize() anyway, (I'm too lazy to check, at present).

Regards,
Keith.

On Mar 30, 2008, at 11:22 PM, John Brown wrote:
>
> Zack Morris wrote:
> [snip]
>
>> -luser32 is a useful tidbit. I am having trouble getting the linker
>> to use -mwindows, because it gives me an emulation warning and says
>> that only i386pe is allowed. I am able to get i386-mingw32-ld to link
>> if I use this:
>>
>> /usr/local/cross-tools/bin/i386-mingw32-ld -o /Users/zmorris/
>> Development/Windows/test-xcode/build/Release/test.exe -L/Users/ 
>> zmorris/
>> Development/Windows/test-xcode/build/Release -L/usr/local/cross- 
>> tools/
>> lib /Users/zmorris/Development/Windows/test-xcode/build/test.build/
>> Release/test.build/Objects-normal/i386/main.o /Users/zmorris/
>> Development/Windows/test-xcode/build/test.build/Release/test.build/
>> Objects-normal/i386/file2.o --subsystem windows -e _WinMain@16 -
>> luser32 -lddraw
>
> That should not be necessary, but if it works ...
>
> [snip]
>
>> ...
>
> MinGW is is a win32 port of gcc. Whatever gcc options you are used to
> having should be there. By the way, what is your cross-compiler's gcc
> version number?


Mingw's is:

gcc version 3.4.5 (mingw special)

Whereas I guess my Leopard gcc is 4.0.1?  That could explain some  
missing options.  I have it all working, I just had to use perl to  
parse yourapp.exe.LinkFileList into an array and then pass all of the  
files as a string to mingw's ld, and also strip out incompatible  
options.  I'm going to try to clean up the symlinking of gcc->mingw by  
putting those steps into a new build phase before the compile step I  
think, and then putting them back after the build finishes.  I wish I  
knew a way to just tell Xcode to use a different compiler, local to  
each project.

--Zack

Vincent Torri wrote:

> On Sun, 30 Mar 2008, Aaron W. LaFramboise wrote:

> afaik, fcntl is not declared in fcntl.h or io.h (mingw 5.1.3, candidate). 

Oops, you are completely correct.  fcntl.h only has the modes for open().

mrdev, you may need to do some porting work on your own then.  Depending 
  on what operation is being performed, you may be able to just comment 
the call out, or replace it with another appropriate call such as dup().

Thanks for various comments.

Now I understands the msys-*.dll license and needs.
I erase the msys-*.dll related files for my build environment.
With replacing msys-z.dll to static zlib, My problem is solved.

c.f.
I am still debugging gtk-vnc in my spare time.

Thanks
Atsushi SAKAI


"Tor Lillqvist" <tm...@ik...> wrote:

> 
> 
> 
> >  I think it is more likely that you really want a native version of zlib
> >  (e.g. libz.dll) as the other correspondent suggested. Google 'zlib
> >  mingwPORT'.
> 
> Or just use the official binary (zlib1.dll) conveniently provided at
> www.zlib.net?
> 
> I don't understand why one would desperately need to rebuilt zlib
> oneself, when there is a perfectly nice pre-built binary available?
> But then I am a lazy bastard... (Unless one wants to enhance it and/or
> need to debug it, etc.)
> 
> --tml
> 
> 
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
> 
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users

Hey,

On Sun, 30 Mar 2008, Aaron W. LaFramboise wrote:

> mrdev wrote:
>> Hi!
>> I'm using MinGW, and I need the following functions: fcntl(), ftruncate(),
>> sync() and bcopy(). These functions are missing in MinGW plataform.
>
> Sorry, only a small loose subset of POSIX functions are provided.
>
> fcntl() is in <fcntl.h> or <io.h>

afaik, fcntl is not declared in fcntl.h or io.h (mingw 5.1.3, candidate). 
I had to write a port of that function for my own purposes. But if it is 
defined in a lib, then, i would be glad to know :) I'm sure that my port 
is full of bugs :)

regards

Vincent Torri

Zack Morris wrote:
[snip]

> -luser32 is a useful tidbit. I am having trouble getting the linker
> to use -mwindows, because it gives me an emulation warning and says
> that only i386pe is allowed. I am able to get i386-mingw32-ld to link
> if I use this:
>
> /usr/local/cross-tools/bin/i386-mingw32-ld -o /Users/zmorris/
> Development/Windows/test-xcode/build/Release/test.exe -L/Users/zmorris/
> Development/Windows/test-xcode/build/Release -L/usr/local/cross-tools/
> lib /Users/zmorris/Development/Windows/test-xcode/build/test.build/
> Release/test.build/Objects-normal/i386/main.o /Users/zmorris/
> Development/Windows/test-xcode/build/test.build/Release/test.build/
> Objects-normal/i386/file2.o --subsystem windows -e _WinMain@16 -
> luser32 -lddraw

That should not be necessary, but if it works ...

[snip]

>
> The last thing I am having issues with is getting i386-mingw32-ld to
> read xcode's yourapp.exe.LinkFileList. This is just a list of all of
> the file.o that xcode compiled. I will probably make the ld.pl script
> read the LinkFileList and pass the lines as one line to i386-mingw32-
> ld, unless there is a command for mingw that allows you to pass a file
> containing a list of .o files, like the -filelist option in gcc.
> Either that or I will add a new build phase.
>

MinGW is is a win32 port of gcc. Whatever gcc options you are used to
having should be there. By the way, what is your cross-compiler's gcc
version number?
_________________________________________________________________
Windows Live Hotmail is giving away Zunes.
http://www.windowslive-hotmail.com/ZuneADay/?locale=en-US&ocid=TXT_TAGLM_Mobile_Zune_V3

On Mar 29, 2008, at 7:32 PM, John Brown wrote:
>
> Zack Morris wrote:
>
>> Ya true hmm, I just haven't worked much with configure or passing gcc
>> options directly. Well I have it all working from console, and am now
>> trying to integrate this with Xcode. I have done these steps so far  
>> to
>> swap mingw in for gcc, and tell Xcode what flags to pass to it:
>> ...
>
> I don't know anything abiyt Xcode, but:
> You should create symbolic links g++ and gcc, corresponding to i386- 
> mingw32-g++
> and  i386-mingw32-gcc respectively. If you are compiling
> C++ files, you should use g++, otherwise use gcc. gcc will work, but  
> you must
> add -lstdc++ to the command line. However, that is not the problem  
> (yet).
>
> It seems that your native ld is being called instead of the
> cross-compiler's ld.  You should probably create your symbolic links  
> in
> /usr/local/cross-tools/bin and then ensure that this directory  
> appears before
> /usr/bin (or any other directory that contains gcc) in your PATH.

Man, unbelievably, I spent a couple of hours researching and  
reinvented the wheel doing exactly this method.  The symlinks for  
xcode go in /Developer/usr/bin, and you have to point /Developer/usr/ 
bin/gcc-4.0 to /usr/local/cross-tools/bin/i386-mingw32-g++ and / 
Developer/usr/bin/ld to i386-mingw32-ld.  Unfortunately, mingw can't  
handle -arch, -F/ or -I/yourapp.exe.hmap.  I had to make a perl script  
to filter these out and then call mingw with the new arg list.

>> "_MessageBox", referenced from:
>> _WinMain in main.o
>> ld: symbol(s) not found
>> collect2: ld returned 1 exit status
>
> MessageBox is found in -luser32, which is part of w32api. I assume  
> that w32api
> is installed. You can search the MSDN Library to find out which  
> header and
> library files are needed for any Win32 API function.

-luser32 is a useful tidbit.  I am having trouble getting the linker  
to use -mwindows, because it gives me an emulation warning and says  
that only i386pe is allowed.  I am able to get i386-mingw32-ld to link  
if I use this:

/usr/local/cross-tools/bin/i386-mingw32-ld -o /Users/zmorris/ 
Development/Windows/test-xcode/build/Release/test.exe -L/Users/zmorris/ 
Development/Windows/test-xcode/build/Release -L/usr/local/cross-tools/ 
lib /Users/zmorris/Development/Windows/test-xcode/build/test.build/ 
Release/test.build/Objects-normal/i386/main.o  /Users/zmorris/ 
Development/Windows/test-xcode/build/test.build/Release/test.build/ 
Objects-normal/i386/file2.o --subsystem windows -e _WinMain@16 - 
luser32 -lddraw

The important parts being:

--subsystem windows
-e _WinMain@16
-luser32

>> I am still not absolutely certain that Xcode is using mingw. The - 
>> mwindows flag
>> should skip the need for main(), and I believe -lmingw32 should  
>> provide
>> MessageBox(). I am still missing something, but this whole process  
>> seems to
>> still be evolving, with several forums on the web offering  
>> different suggestions.
>>
>
> The -o flag does not belong in 'Other Linker Flags'. I don't think  
> that it is
> necessary to explicitly link to -lmingw32, and it may even be the  
> problem.

You were right about these two, they were making each file.o generated  
by xcode be 400k.  Now they are each under 4k.

The last thing I am having issues with is getting i386-mingw32-ld to  
read xcode's yourapp.exe.LinkFileList.  This is just a list of all of  
the file.o that xcode compiled.  I will probably make the ld.pl script  
read the LinkFileList and pass the lines as one line to i386-mingw32- 
ld, unless there is a command for mingw that allows you to pass a file  
containing a list of .o files, like the -filelist option in gcc.   
Either that or I will add a new build phase.

Thanx for all of your help,

--Zack

mrdev wrote:

> I'm using MinGW, and I need the following functions: fcntl(), ftruncate(),
> sync() and bcopy(). These functions are missing in MinGW plataform. 
> I would know what I can do? Sugestions?

Easy one first:

    static inline void bcopy (const void *src, void *dest, size_t n)
    {
        memcpy(dest, src, n) ;
    }

As for fcntl() and sync(), I don't believe that there is really an
equivalent on windows.

Finally, for ftruncate(), there is a chsize() function that basically
does the same, but it doesn't work for files larger than 2Gig.

However, I highly recommend that you do not use any of the microsoft
supplied POSIX API calls. I have over the years found numerous very
obscure corner case bugs in the microsoft implementations. I blogged
the most recent one here:

    http://www.mega-nerd.com/erikd/Blog/Windiots/posix.html

which is present right up to and include windows XP.

What I did with my libsndfile project was create a set of wrapper
functions around the POSIX file I/O functions and then provide a
windows specific versions of all the wrapper functions using the
(particularly horrid) native windows file I/O API.

Feel free to have a look at file_io.c in libsndfile which is
released under the GNU LGPL. This file also documents some of
the other broken-ness I have found in the comments.

HTH,
Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"I have never met anyone who can do Scheme, Haskell, and C pointers
who can't pick up Java in two days, and create better Java code than
people with five years of experience in Java." --
http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html

mrdev wrote:
> Hi!
> I'm using MinGW, and I need the following functions: fcntl(), ftruncate(),
> sync() and bcopy(). These functions are missing in MinGW plataform. 

Sorry, only a small loose subset of POSIX functions are provided.

fcntl() is in <fcntl.h> or <io.h>

ftruncate is in <unistd.h>

sync() calls can probably be commented out.

Use C standard memcpy() instead instead BSD bcopy().

Hi!
I'm using MinGW, and I need the following functions: fcntl(), ftruncate(),
sync() and bcopy(). These functions are missing in MinGW plataform. 
I would know what I can do? Sugestions?
Thanks in advanced!
-- 
View this message in context: http://www.nabble.com/functions-missing-tp16386002p16386002.html
Sent from the MinGW - User mailing list archive at Nabble.com.

Zack Morris wrote:

> Ya true hmm, I just haven't worked much with configure or passing gcc
> options directly. Well I have it all working from console, and am now
> trying to integrate this with Xcode. I have done these steps so far to
> swap mingw in for gcc, and tell Xcode what flags to pass to it:
>
> cd /usr/bin
> sudo mv gcc gccBACKUP
> sudo ln -s /usr/local/cross-tools/bin/i386-mingw32-g++ gcc
> // go into project settings:
> Architectures: i386 (might be $(NATIVE_ARCH) on intel)
> Valid Architectures: i386 x86_64
> Header Search Paths: /Users/zmorris/Development/Windows/DXSDK/include
> Library Search Paths: /usr/local/cross-tools/lib
> Other Linker Flags: -mwindows -g -o -lmingw32 -lddraw
>
> So far it allllmost works, but I am getting:
>
> ld: warning in /usr/local/cross-tools/lib/libddraw.a, file is not of required architecture
> "_main", referenced from:
> start in crt1.10.5.o

I don't know anything abiyt Xcode, but:
You should create symbolic links g++ and gcc, corresponding to i386-mingw32-g++
and  i386-mingw32-gcc respectively. If you are compiling
C++ files, you should use g++, otherwise use gcc. gcc will work, but you must
add -lstdc++ to the command line. However, that is not the problem (yet).

It seems that your native ld is being called instead of the
cross-compiler's ld.  You should probably create your symbolic links in
/usr/local/cross-tools/bin and then ensure that this directory appears before
/usr/bin (or any other directory that contains gcc) in your PATH.

> "_MessageBox", referenced from:
> _WinMain in main.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status

MessageBox is found in -luser32, which is part of w32api. I assume that w32api
is installed. You can search the MSDN Library to find out which header and
library files are needed for any Win32 API function.
>
> I am still not absolutely certain that Xcode is using mingw. The -mwindows flag
>  should skip the need for main(), and I believe -lmingw32 should provide
> MessageBox(). I am still missing something, but this whole process seems to
> still be evolving, with several forums on the web offering different suggestions.
>

The -o flag does not belong in 'Other Linker Flags'. I don't think that it is
necessary to explicitly link to -lmingw32, and it may even be the problem.

> FYI, I understand this is a potentially painful path I am on, but I want to
> understand what is happening at a low level. I also have MS Visual C++
> Express in parallels and am building a project in parallel on both sides.
> It's just quicker for me to work in my native environment is all, and then
> debug in the visual c++ IDE when I need to.
>
> Thanx,
>
> --Zack
>

_________________________________________________________________
Windows Live Hotmail is giving away Zunes.
http://www.windowslive-hotmail.com/ZuneADay/?locale=en-US&ocid=TXT_TAGLM_Mobile_Zune_V3

On Saturday, March 29, 2008, at 06:34AM, "Tuomo Latto" <dj...@ik...> wrote:
>zm...@ma... wrote:
>> On Mar 28, 2008, at 9:48 PM, John Brown wrote:
>>> Assuming that libXXX.a is in the directory specified by -L, then write
>>> '-lXXX' instead of 'libXXX.a'. If you want, you can also write
>>> '/full/path/to/libXXX.a'
>> 
>> Amazing, just amazing :)  This is an important enough point, that it  
>> might be nice to have an errata or FAQ about it, because I seriously  
>> spent all of yesterday searching for how to do this.  Thank you very  
>> much for your prompt response!
>
>This is sort of assumed to be known, since it belongs to the category
>of "basic gcc usage" rather than to MinGW specifics or common gotchas.
>It is such a basic piece of information that it really isn't even a FAQ.
>That is, I can't remember anyone asking about it before.

Ya true hmm, I just haven't worked much with configure or passing gcc options directly.  Well I have it all working from console, and am now trying to integrate this with Xcode.  I have done these steps so far to swap mingw in for gcc, and tell Xcode what flags to pass to it:

cd /usr/bin
sudo mv gcc gccBACKUP
sudo ln -s /usr/local/cross-tools/bin/i386-mingw32-g++ gcc
// go into project settings:
Architectures: i386 (might be $(NATIVE_ARCH) on intel)
Valid Architectures: i386 x86_64
Header Search Paths: /Users/zmorris/Development/Windows/DXSDK/include
Library Search Paths: /usr/local/cross-tools/lib
Other Linker Flags: -mwindows -g -o -lmingw32 -lddraw

So far it allllmost works, but I am getting:

ld: warning in /usr/local/cross-tools/lib/libddraw.a, file is not of required architecture
  "_main", referenced from:
      start in crt1.10.5.o
  "_MessageBox", referenced from:
      _WinMain in main.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

I am still not absolutely certain that Xcode is using mingw.  The -mwindows flag should skip the need for main(), and I believe -lmingw32 should provide MessageBox().  I am still missing something, but this whole process seems to still be evolving, with several forums on the web offering different suggestions.

FYI, I understand this is a potentially painful path I am on, but I want to understand what is happening at a low level.  I also have MS Visual C++ Express in parallels and am building a project in parallel on both sides.  It's just quicker for me to work in my native environment is all, and then debug in the visual c++ IDE when I need to.

Thanx,

--Zack

Chris Wilson wrote:

> Not that I know, I think MSVCRT is not POSIX compliant in this regard.

<pedant mode="on">
Sorry, "%lld", "%lli" etc are part of the 1999 ISO C Standard.
</pedant>

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"Attacks by Microsoft Chairman Bill Gates on the GNU General
Public License, under which much open source and free software is
distributed, have been driven by a fear that the GPL creates a
domain of software that Microsoft cannot privatize and control"
   -- Richard Stallman

Paul Hargreaves schrieb:
>
> I guess there isn't a portable way of doing this then that will work 
> the same on non-msvcrt without #IFDEFs?
>
You can use uint64_t (#include <stdint.h>) instead of unsigned long long 
and then use the PRIu64 macro (#include <inttypes.h>):

uint64_t o = 901
printf("o = %"PRIu64"\n", o);


Peter

On Saturday 29 March 2008 18:54, Chris Wilson wrote:
> > Thanks for this; I guess there isn't a portable way of doing this
> > then that will work the same on non-msvcrt without #IFDEFs?
>
> Not that I know, I think MSVCRT is not POSIX compliant in this
> regard.

Define this ONCE, in a header...

#ifdef _WIN32
# define LL_FMT "I64"
#else
# define LL_FMT "ll"
#endif

then, at point of use...

printf( "Here is a long long number: %"LL_FMT"u\n", long_long_value );

> I've replaced all printfs with std::ostream in my code. Much more
> verbose, but more flexible and 100% portable.

Ok for C++; you're stumped if you are writing C.

Regards,
Keith.

>> Thanks for this; I guess there isn't a portable way of doing this
then 
>> that will work the same on non-msvcrt without #IFDEFs?
>
>Not that I know, I think MSVCRT is not POSIX compliant in this regard.

Shocker ;-)

>I've replaced all printfs with std::ostream in my code. Much more
verbose, 
>but more flexible and 100% portable.

A quick google shows this is C++ and not C? I'll do some more digging
anyway - just starting to play around in anger with C so enjoying the
learning code.

>Also, please don't top post to mailing lists (if your crackberry can't
do 
>real inline replies, please don't use it to post to mailing lists).

Bah. It doesn't seem to want to do inlines - won't let me add text below
the reply line. Something else to look at in my spare time so back into
Outlook.

Thanks for the pointers btw.

Regards

Paul

Confidentiality Notice: This e-mail message, including any attachment is for the sole use of the intended recipient(s) and may contain confidential and privileged information.  Any unauthorized review, use disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

Hi Paul,

> On Sat, 29 Mar 2008, Paul Hargreaves wrote:
> 
> >   printf("o=901 %i\n", (o==901));
> >   printf("i=902 %i\n", (i==902));
> >   printf("a=903 %i\n", (a==903));
> >   printf("Testing sizes o:%llu: i:%llu: a:%llu:\n", o, i, a);
> >   return 0;
> [...]
> > Compile this using gcc in mingw and you get the following odd results:
> > 
> > o=901 1
> > i=902 1
> > a=903 1
> > Testing sizes o:901: i:0: a:902:

I replied:

> You have to use %I64u as the format string for Microsoft's libc (msvcrt).

On Sat, 29 Mar 2008, Paul Hargreaves wrote:

> Thanks for this; I guess there isn't a portable way of doing this then 
> that will work the same on non-msvcrt without #IFDEFs?

Not that I know, I think MSVCRT is not POSIX compliant in this regard.

I've replaced all printfs with std::ostream in my code. Much more verbose, 
but more flexible and 100% portable.

Also, please don't top post to mailing lists (if your crackberry can't do 
real inline replies, please don't use it to post to mailing lists).

Cheers, Chris.
-- 
_____ __     _
\  __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer |
\ _/_/_/_//_/___/ | We are GNU : free your mind & your software |

Thanks for this; I guess there isn't a portable way of doing this then that will work the same on non-msvcrt without #IFDEFs?

Regards

Paul
Sent via BlackBerry

-----Original Message-----
From: min...@li... <min...@li...>
To: MinGW Users List <min...@li...>
Sent: Sat Mar 29 11:49:11 2008
Subject: Re: [Mingw-users] long long int printf query

Hi Paul,

On Sat, 29 Mar 2008, Paul Hargreaves wrote:

>   printf("o=901 %i\n", (o==901));
>   printf("i=902 %i\n", (i==902));
>   printf("a=903 %i\n", (a==903));
>   printf("Testing sizes o:%llu: i:%llu: a:%llu:\n", o, i, a);
>   return 0;
[...]
> Compile this using gcc in mingw and you get the following odd results:
> 
> o=901 1
> i=902 1
> a=903 1
> Testing sizes o:901: i:0: a:902:

You have to use %I64u as the format string for Microsoft's libc (msvcrt).

Cheers, Chris.
-- 
_____ __     _
\  __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer |
\ _/_/_/_//_/___/ | We are GNU : free your mind & your software |

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
MinGW-users mailing list
Min...@li...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

Confidentiality Notice: This e-mail message, including any attachment is for the sole use of the intended recipient(s) and may contain confidential and privileged information.  Any unauthorized review, use disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

Hi Paul,

On Sat, 29 Mar 2008, Paul Hargreaves wrote:

>   printf("o=901 %i\n", (o==901));
>   printf("i=902 %i\n", (i==902));
>   printf("a=903 %i\n", (a==903));
>   printf("Testing sizes o:%llu: i:%llu: a:%llu:\n", o, i, a);
>   return 0;
[...]
> Compile this using gcc in mingw and you get the following odd results:
> 
> o=901 1
> i=902 1
> a=903 1
> Testing sizes o:901: i:0: a:902:

You have to use %I64u as the format string for Microsoft's libc (msvcrt).

Cheers, Chris.
-- 
_____ __     _
\  __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer |
\ _/_/_/_//_/___/ | We are GNU : free your mind & your software |

I've been bashing my head against mingw. Specifically 64 bit longs don't
seem to always printf properly when compiled. Target machine is XP
Win32, but the CPU is athlon64.


Example code to demonstrate problem:

// Example of the unsigned long long int 
int main()
{
  unsigned long long int o; 
  unsigned long long int a;
  unsigned long long int i;
  o=901;
  i=902;
  a=903;
  printf("o=901 %i\n", (o==901));
  printf("i=902 %i\n", (i==902));
  printf("a=903 %i\n", (a==903));
  printf("Testing sizes o:%llu: i:%llu: a:%llu:\n", o, i, a);
  return 0;
}


Compile using cygwin:

$ ./a.exe
o=901 1
i=902 1
a=903 1
Testing sizes o:901: i:902: a:903:

All looks good.

Compile this using gcc in mingw and you get the following odd results:

o=901 1
i=902 1
a=903 1
Testing sizes o:901: i:0: a:902:


Hmm.. i shouldn't be 0 and a shouldn't be 902... and when tested against
specific values they are still being stored correctly.

Any suggestions on what I'm doing wrong?


Regards

Paul


Confidentiality Notice: This e-mail message, including any attachment is for the sole use of the intended recipient(s) and may contain confidential and privileged information.  Any unauthorized review, use disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

zm...@ma... wrote:
> On Mar 28, 2008, at 9:48 PM, John Brown wrote:
>> Assuming that libXXX.a is in the directory specified by -L, then write
>> '-lXXX' instead of 'libXXX.a'. If you want, you can also write
>> '/full/path/to/libXXX.a'
> 
> Amazing, just amazing :)  This is an important enough point, that it  
> might be nice to have an errata or FAQ about it, because I seriously  
> spent all of yesterday searching for how to do this.  Thank you very  
> much for your prompt response!

This is sort of assumed to be known, since it belongs to the category
of "basic gcc usage" rather than to MinGW specifics or common gotchas.
It is such a basic piece of information that it really isn't even a FAQ.
That is, I can't remember anyone asking about it before.

However, digging around a bit, I see
"How do I specify the libraries to be searched by the linker?"
in the FAQ (http://www.mingw.org/MinGWiki/index.php/FAQ).

Of course, had you looked inside some simple Makefiles or searched
for various command lines instead of documentation, you probably would
have found this nugget a lot earlier.
Or maybe googled for "+gcc +linking" to find "An Introduction to GCC
  - Linking with external libraries" 
(http://www.network-theory.co.uk/docs/gccintro/gccintro_17.html).


-- 
Tuomo

... Imagine my delight/surprise/embarrassment to find the exact answer
     to my question when I typed :help submatch()!    -- on vi...@vi...

On Mar 28, 2008, at 9:48 PM, John Brown wrote:
>
> zmorris wrote:
>
> [snip]
>
>>
>> I am trying to compile a simple test.c file with (all one line):
>>
>> /usr/local/cross-tools/bin/i386-mingw32-g++    -I"/Users/zmorris/
>> Development/Windows/DXSDK/include"    -L"/usr/local/cross-tools/
>> lib"    -mwindows -g -o test.exe test.c libddraw.a
>>
>
> [snip]
>
> Assuming that libXXX.a is in the directory specified by -L, then write
> '-lXXX' instead of 'libXXX.a'. If you want, you can also write
> '/full/path/to/libXXX.a'

Amazing, just amazing :)  This is an important enough point, that it  
might be nice to have an errata or FAQ about it, because I seriously  
spent all of yesterday searching for how to do this.  Thank you very  
much for your prompt response!

--Zack

zmorris wrote:

[snip]

>
> I am trying to compile a simple test.c file with (all one line):
>
> /usr/local/cross-tools/bin/i386-mingw32-g++    -I"/Users/zmorris/
> Development/Windows/DXSDK/include"    -L"/usr/local/cross-tools/
> lib"    -mwindows -g -o test.exe test.c libddraw.a
>

[snip]

Assuming that libXXX.a is in the directory specified by -L, then write
'-lXXX' instead of 'libXXX.a'. If you want, you can also write
'/full/path/to/libXXX.a'


_________________________________________________________________
Watch “Cause Effect,” a show about real people making a real difference.  Learn more.
http://im.live.com/Messenger/IM/MTV/?source=text_watchcause

Hi, I have a mac development environment set up with mingw, parallels,  
and winxp, to compile windows directx apps from the mac console and  
eventually in xcode.

I used this page to get started, it works great:

http://www.libsdl.org/extras/win32/cross/README.txt

I am trying to compile a simple test.c file with (all one line):

/usr/local/cross-tools/bin/i386-mingw32-g++    -I"/Users/zmorris/ 
Development/Windows/DXSDK/include"    -L"/usr/local/cross-tools/ 
lib"    -mwindows -g -o test.exe test.c libddraw.a

The include portion is where I manually copied the windows DXSDK into  
my development folder to get the directx headers, and is working  
perfectly to give me ddraw.h etc, but for the life of me I can't get  
the -L option to work.  If I copy libddraw.a manually into my local  
directory, it compiles fine.  I am not using a configure script.  I  
have scoured google for hours.  I hardly ever ask mailing lists, but I  
think this is something that most people will encounter their first  
time compiling so hopefully the answer can go into the archives.  Is  
there another command like LDFLAGS, LIBPATH etc that will get this  
working?

Thanx!

--Zack