Re: [Mingw-w64-public] GCC C++0x
On Thu, Aug 26, 2010 at 7:18 AM, Kai Tietz wrote: > 2010/8/26 Ruben Van Boxem : >> >>> >>> but poking around, I do not find a "thread" file (the include file >>> for std::thread). >> >> it should be in: >> /libstdc++-v3/include/std >> >>> >>> My mingw gcc installation does have a "thread" file. (I realize that >>> it may be out of date, but it's all I have.) I see, as Ruben pointed >>> out, that it references (either directly or indirectly) >>> >>> __gthread_cond_t >>> __gthread_time_t >>> >>> (and related), and that these are not defined in gthr-win32.h. >> >> As I said, *time_t is easy, but *cond_t seems like a big problem, because >> the whole concept of threading is different and there's far from a 1-on-1 >> mapping of *cond_t to win32 API. Once we have that struct though, it should >> be quite straightforward to get the functions implemented. The gthr-win32.h >> header is located in >> >> gcc trunk/4.6 snapshot: >> gcc/gthr-win32.h >> gcc/config/i386/gthr-win32.c >> >> This last one will either need >> >>> >>> Do I take it correctly that the windows version of gthreads does >>> not implement all of the features in the linux/posix version, and >>> that some of these features are needed by the gcc implementation >>> of std::thread? >>> >>> And that our discussion here is basically about sticking with the >>> existing gcc implementation of std::thread and getting it to work >>> on windows by adding the missing features to the windows >>> version of gthreads? >> >> Correct. > > As I said before, if those functions are implemented in > gcc/gthr-win32.h and gcc/config/i386/gthr-win32-c, then we can define > in gthr-win32.h the define to support CXX0X. > Adding GD to the list -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] import library overlap
On 30 August 2010 11:23, Kai Tietz wrote: > Well, this is a bit too much. Just make sure you specify on command > line (at end, or before -lkernel32 - if you specify it - the option > -ladvapi32. You can file a bug report for gcc, so I don't miss to > modify it for 4.6. Done: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45452 Cheers! Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] import library overlap
2010/8/30 Chris Sutcliffe :
> On 30 August 2010 10:42, Kai Tietz wrote:
>> 2010/8/30 Chris Sutcliffe :
>>> Is it possible to override / change the default link order (i.e. is it
>>> in a config file somewhere), or is it hard coded at compile time?
>>
>> Well, this is a suggested default by gcc (IMHO we should change here
>> order, or teach ld to know dependencies odering of import-libraries).
>> But of course by using 'gcc -o myapp.exe my-object-files -ladvapi32'
>> forces that advapi32 library gets linked before the default one.
>
> One other thought I had was specifying '-nodefaultlibs', but I think
> that may be a little extreme, given:
>
> -nodefaultlibs
> Do not use the standard system libraries when linking. Only the
> libraries you specify will be passed to the linker, options specifying
> linkage of the system libraries, such as -static-libgcc or
> -shared-libgcc, will be ignored. The standard startup files are used
> normally, unless -nostartfiles is used. The compiler may generate
> calls to memcmp, memset, memcpy and memmove. These entries are usually
> resolved by entries in libc. These entry points should be supplied
> through some other mechanism when this option is specified.
>
> from the desciption, I would need to add -lgcc_s, etc. Is there a
> less extreme option to only override kernel32, advapi, etc.?
>
> Thank you,
>
> Chris
>
> --
> Chris Sutcliffe
> http://emergedesktop.org
> http://www.google.com/profiles/ir0nh34d
>
Well, this is a bit too much. Just make sure you specify on command
line (at end, or before -lkernel32 - if you specify it - the option
-ladvapi32. You can file a bug report for gcc, so I don't miss to
modify it for 4.6.
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] import library overlap
On 30 August 2010 10:42, Kai Tietz wrote: > 2010/8/30 Chris Sutcliffe : >> Is it possible to override / change the default link order (i.e. is it >> in a config file somewhere), or is it hard coded at compile time? > > Well, this is a suggested default by gcc (IMHO we should change here > order, or teach ld to know dependencies odering of import-libraries). > But of course by using 'gcc -o myapp.exe my-object-files -ladvapi32' > forces that advapi32 library gets linked before the default one. One other thought I had was specifying '-nodefaultlibs', but I think that may be a little extreme, given: -nodefaultlibs Do not use the standard system libraries when linking. Only the libraries you specify will be passed to the linker, options specifying linkage of the system libraries, such as -static-libgcc or -shared-libgcc, will be ignored. The standard startup files are used normally, unless -nostartfiles is used. The compiler may generate calls to memcmp, memset, memcpy and memmove. These entries are usually resolved by entries in libc. These entry points should be supplied through some other mechanism when this option is specified. from the desciption, I would need to add -lgcc_s, etc. Is there a less extreme option to only override kernel32, advapi, etc.? Thank you, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Problem with math.h?
On Mon, Aug 30, 2010 at 6:04 PM, Vasilakis wrote: > On 8/30/2010 5:57 PM, Ozkan Sezer wrote: >> >> On Mon, Aug 30, 2010 at 5:49 PM, Vasilakis wrote: >>> >>> On 8/30/2010 5:33 PM, Ozkan Sezer wrote: On Mon, Aug 30, 2010 at 5:30 PM, Kai Tietz wrote: > > 2010/8/30 Vasilakis: >> >> I have a problem compiling an application under windows XPSP3 x86 >> with >> >> mingw-w32-bin_i686-mingw_20100711_sezero.zip + >> sezero_20100711_w32_runtime_update_3441.zip >> >> The exact error reads. >> >> >> >> e:\mingw\bin\../lib/gcc/i686-w64-mingw32/4.4.5/../../../../i686-w64-mingw32/include/math.h:384: >> error: expected unqualified-id before 'float' >> >> What does it mean? >> >> Thanks > > Hmm, the line you show is 'extern float __cdecl sinf(float _X);'. Now > is the question which float gcc is warning here about. If it is the > first, then you have possibly a define of extern (which is a bit > unlikely). My bets go for the second one and here the issue could be > that sinf is a define. To check use preprocessed headers (gcc -E) and > check what this line gets expanded to. > > Regards, > Kai > There is the signbit() macro just before that sinf() prototype. If there is some voodoo about that one in the user code, that can mess things up too? Yes, it would help if we see the preprocessed source. -- Ozkan >>> >>> Can you please tell me how to do it? I use the latest stable codeblocks >>> to >>> compile lsm_1_7_15_source.zip (Lionsnake modeller). with -E it compiles >>> fine, without it does not. >>> How can I instruct it to "generate preprocessed headers"? >>> >>> Thanks and sorry for my ignorance. >>> >> Well, with -E, it is not supposed to compile anything. >> Find out what the command line is for the particular source file. >> Suppose it is like: >> gcc -Dmydefine -Wall -c mysource.c -o mysource.o >> Now do: >> gcc -Dmydefine -Wall -E mysource.c> out.txt >> ... and inspect the generated out.txt to figure things out. >> >> -- >> Ozkan > > I will take a look later. Thank you very much for your advice. > OK, I downloaded that lsm_1_7_15_source.zip and it seems like the calc.h header in it is your problem: It defines sinf (and several others along with it) and it clashes with the system provided header. My suggestion would be removing those wrappers which are already provided by the system headers. -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Problem with math.h?
On 8/30/2010 5:57 PM, Ozkan Sezer wrote: > On Mon, Aug 30, 2010 at 5:49 PM, Vasilakis wrote: >> On 8/30/2010 5:33 PM, Ozkan Sezer wrote: >>> On Mon, Aug 30, 2010 at 5:30 PM, Kai Tietz >>> wrote: 2010/8/30 Vasilakis: > I have a problem compiling an application under windows XPSP3 x86 with > > mingw-w32-bin_i686-mingw_20100711_sezero.zip + > sezero_20100711_w32_runtime_update_3441.zip > > The exact error reads. > > > e:\mingw\bin\../lib/gcc/i686-w64-mingw32/4.4.5/../../../../i686-w64-mingw32/include/math.h:384: > error: expected unqualified-id before 'float' > > What does it mean? > > Thanks Hmm, the line you show is 'extern float __cdecl sinf(float _X);'. Now is the question which float gcc is warning here about. If it is the first, then you have possibly a define of extern (which is a bit unlikely). My bets go for the second one and here the issue could be that sinf is a define. To check use preprocessed headers (gcc -E) and check what this line gets expanded to. Regards, Kai >>> There is the signbit() macro just before that sinf() prototype. If there >>> is some voodoo about that one in the user code, that can mess things up >>> too? Yes, it would help if we see the preprocessed source. >>> >>> -- >>> Ozkan >> Can you please tell me how to do it? I use the latest stable codeblocks to >> compile lsm_1_7_15_source.zip (Lionsnake modeller). with -E it compiles >> fine, without it does not. >> How can I instruct it to "generate preprocessed headers"? >> >> Thanks and sorry for my ignorance. >> > Well, with -E, it is not supposed to compile anything. > Find out what the command line is for the particular source file. > Suppose it is like: > gcc -Dmydefine -Wall -c mysource.c -o mysource.o > Now do: > gcc -Dmydefine -Wall -E mysource.c> out.txt > ... and inspect the generated out.txt to figure things out. > > -- > Ozkan I will take a look later. Thank you very much for your advice. -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Problem with math.h?
On Mon, Aug 30, 2010 at 5:49 PM, Vasilakis wrote: > On 8/30/2010 5:33 PM, Ozkan Sezer wrote: >> >> On Mon, Aug 30, 2010 at 5:30 PM, Kai Tietz >> wrote: >>> >>> 2010/8/30 Vasilakis: I have a problem compiling an application under windows XPSP3 x86 with mingw-w32-bin_i686-mingw_20100711_sezero.zip + sezero_20100711_w32_runtime_update_3441.zip The exact error reads. e:\mingw\bin\../lib/gcc/i686-w64-mingw32/4.4.5/../../../../i686-w64-mingw32/include/math.h:384: error: expected unqualified-id before 'float' What does it mean? Thanks >>> >>> Hmm, the line you show is 'extern float __cdecl sinf(float _X);'. Now >>> is the question which float gcc is warning here about. If it is the >>> first, then you have possibly a define of extern (which is a bit >>> unlikely). My bets go for the second one and here the issue could be >>> that sinf is a define. To check use preprocessed headers (gcc -E) and >>> check what this line gets expanded to. >>> >>> Regards, >>> Kai >>> >> There is the signbit() macro just before that sinf() prototype. If there >> is some voodoo about that one in the user code, that can mess things up >> too? Yes, it would help if we see the preprocessed source. >> >> -- >> Ozkan > > Can you please tell me how to do it? I use the latest stable codeblocks to > compile lsm_1_7_15_source.zip (Lionsnake modeller). with -E it compiles > fine, without it does not. > How can I instruct it to "generate preprocessed headers"? > > Thanks and sorry for my ignorance. > Well, with -E, it is not supposed to compile anything. Find out what the command line is for the particular source file. Suppose it is like: gcc -Dmydefine -Wall -c mysource.c -o mysource.o Now do: gcc -Dmydefine -Wall -E mysource.c > out.txt ... and inspect the generated out.txt to figure things out. -- Ozkan -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Problem with math.h?
On 8/30/2010 5:33 PM, Ozkan Sezer wrote: > On Mon, Aug 30, 2010 at 5:30 PM, Kai Tietz wrote: >> 2010/8/30 Vasilakis: >>> I have a problem compiling an application under windows XPSP3 x86 with >>> >>> mingw-w32-bin_i686-mingw_20100711_sezero.zip + >>> sezero_20100711_w32_runtime_update_3441.zip >>> >>> The exact error reads. >>> >>> e:\mingw\bin\../lib/gcc/i686-w64-mingw32/4.4.5/../../../../i686-w64-mingw32/include/math.h:384: >>> error: expected unqualified-id before 'float' >>> >>> What does it mean? >>> >>> Thanks >> Hmm, the line you show is 'extern float __cdecl sinf(float _X);'. Now >> is the question which float gcc is warning here about. If it is the >> first, then you have possibly a define of extern (which is a bit >> unlikely). My bets go for the second one and here the issue could be >> that sinf is a define. To check use preprocessed headers (gcc -E) and >> check what this line gets expanded to. >> >> Regards, >> Kai >> > There is the signbit() macro just before that sinf() prototype. If there > is some voodoo about that one in the user code, that can mess things up > too? Yes, it would help if we see the preprocessed source. > > -- > Ozkan Can you please tell me how to do it? I use the latest stable codeblocks to compile lsm_1_7_15_source.zip (Lionsnake modeller). with -E it compiles fine, without it does not. How can I instruct it to "generate preprocessed headers"? Thanks and sorry for my ignorance. -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] import library overlap
2010/8/30 Chris Sutcliffe :
> On 30 August 2010 10:21, Kai Tietz wrote:
>> The issue you see here is related to the default import library order
>> given by gcc. It uses "-luser32 -lkernel32 -ladvapi32 -lshell32" which
>> leads here to the issue. IMHO kernel32 should come last here.
>> Something like this is more correct "-lshell32 -ladvapi32 -luser32
>> -lkernel32"
>
> Is it possible to override / change the default link order (i.e. is it
> in a config file somewhere), or is it hard coded at compile time?
>
> Thank you,
>
> Chris
Well, this is a suggested default by gcc (IMHO we should change here
order, or teach ld to know dependencies odering of import-libraries).
But of course by using 'gcc -o myapp.exe my-object-files -ladvapi32'
forces that advapi32 library gets linked before the default one.
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] import library overlap
On 30 August 2010 10:21, Kai Tietz wrote: > The issue you see here is related to the default import library order > given by gcc. It uses "-luser32 -lkernel32 -ladvapi32 -lshell32" which > leads here to the issue. IMHO kernel32 should come last here. > Something like this is more correct "-lshell32 -ladvapi32 -luser32 > -lkernel32" Is it possible to override / change the default link order (i.e. is it in a config file somewhere), or is it hard coded at compile time? Thank you, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Problem with math.h?
On Mon, Aug 30, 2010 at 5:30 PM, Kai Tietz wrote: > 2010/8/30 Vasilakis : >> I have a problem compiling an application under windows XPSP3 x86 with >> >> mingw-w32-bin_i686-mingw_20100711_sezero.zip + >> sezero_20100711_w32_runtime_update_3441.zip >> >> The exact error reads. >> >> e:\mingw\bin\../lib/gcc/i686-w64-mingw32/4.4.5/../../../../i686-w64-mingw32/include/math.h:384: >> error: expected unqualified-id before 'float' >> >> What does it mean? >> >> Thanks > > Hmm, the line you show is 'extern float __cdecl sinf(float _X);'. Now > is the question which float gcc is warning here about. If it is the > first, then you have possibly a define of extern (which is a bit > unlikely). My bets go for the second one and here the issue could be > that sinf is a define. To check use preprocessed headers (gcc -E) and > check what this line gets expanded to. > > Regards, > Kai > There is the signbit() macro just before that sinf() prototype. If there is some voodoo about that one in the user code, that can mess things up too? Yes, it would help if we see the preprocessed source. -- Ozkan -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Problem with math.h?
2010/8/30 Vasilakis :
> I have a problem compiling an application under windows XPSP3 x86 with
>
> mingw-w32-bin_i686-mingw_20100711_sezero.zip +
> sezero_20100711_w32_runtime_update_3441.zip
>
> The exact error reads.
>
> e:\mingw\bin\../lib/gcc/i686-w64-mingw32/4.4.5/../../../../i686-w64-mingw32/include/math.h:384:
> error: expected unqualified-id before 'float'
>
> What does it mean?
>
> Thanks
Hmm, the line you show is 'extern float __cdecl sinf(float _X);'. Now
is the question which float gcc is warning here about. If it is the
first, then you have possibly a define of extern (which is a bit
unlikely). My bets go for the second one and here the issue could be
that sinf is a define. To check use preprocessed headers (gcc -E) and
check what this line gets expanded to.
Regards,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Problem with math.h?
I have a problem compiling an application under windows XPSP3 x86 with mingw-w32-bin_i686-mingw_20100711_sezero.zip + sezero_20100711_w32_runtime_update_3441.zip The exact error reads. e:\mingw\bin\../lib/gcc/i686-w64-mingw32/4.4.5/../../../../i686-w64-mingw32/include/math.h:384: error: expected unqualified-id before 'float' What does it mean? Thanks -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] import library overlap
2010/8/30 Chris Sutcliffe :
> On 30 August 2010 09:27, JonY wrote:
>> On 8/30/2010 21:00, Chris Sutcliffe wrote:
>>> The OpenProcessToken in particular has come to bite me in a bad way
>>> with Emerge Desktop. I ran in to this issue when using gendef to
>>> update the def files for w32api, in that I had to check for multiple
>>> export definitions of the same function and go to MSDN to determine
>>> which library is expected to export a given function.
>>
>> Thanks for the report. Do you have a list of symbols that are known to
>> conflict?
>
> Based on what I did with w32api:
>
> 2010-08-21 Chris Sutcliffe
>
> * lib/kernel32.def (CopyLZFile, GetExpandedNameA,
> GetExpandedNameW, LZClose,
> LZCopy, LZInit, LZOpenFileA, LZOpenFileW, LZRead, LZSeek,
> OpenProcessToken,
> OpenThreadToken, RegCloseKey, RegCreateKeyExA, RegCreateKeyExW,
> RegDeleteKeyExA, RegDeleteKeyExW, RegDeleteValueA, RegDeleteValueW,
> RegEnumKeyExA, RegEnumKeyExW, RegEnumValueA, RegEnumValueW,
> RegFlushKey,
> RegGetKeySecurity, RegLoadKeyA, RegLoadKeyW, RegNotifyChangeKeyValue,
> RegOpenCurrentUser, RegOpenKeyExA, RegOpenKeyExW,
> RegOpenUserClassesRoot,
> RegQueryInfoKeyA, RegQueryInfoKeyW, RegQueryValueExA, RegQueryValueExW,
> RegRestoreKeyA, RegRestoreKeyW, RegSetKeySecurity, RegSetValueExA,
> RegSetValueW, RegUnLoadKeyA, RegUnLoadKeyW, RtlCaptureStackBackTrace,
> RtlFillMemory, RtlMoveMemory, RtlZeroMemory, SetThreadToken): Remove
> conflicting definition.
> * lib/th32.def: Remove.
> * lib/ntdll.def (RtlUnwind): Remove conflicting definition.
> * lib/version.def (VerLanguageNameA, VerLanguageNameW): Remove
> conflicting
> definition.
>
> However, I did not regenerate all def files, so there may be others as well.
>
> Chris
>
> --
> Chris Sutcliffe
> http://emergedesktop.org
> http://www.google.com/profiles/ir0nh34d
The issue you see here is related to the default import library order
given by gcc. It uses "-luser32 -lkernel32 -ladvapi32 -lshell32" which
leads here to the issue. IMHO kernel32 should come last here.
Something like this is more correct "-lshell32 -ladvapi32 -luser32
-lkernel32"
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] import library overlap
On 30 August 2010 09:27, JonY wrote: > On 8/30/2010 21:00, Chris Sutcliffe wrote: >> The OpenProcessToken in particular has come to bite me in a bad way >> with Emerge Desktop. I ran in to this issue when using gendef to >> update the def files for w32api, in that I had to check for multiple >> export definitions of the same function and go to MSDN to determine >> which library is expected to export a given function. > > Thanks for the report. Do you have a list of symbols that are known to > conflict? Based on what I did with w32api: 2010-08-21 Chris Sutcliffe * lib/kernel32.def (CopyLZFile, GetExpandedNameA, GetExpandedNameW, LZClose, LZCopy, LZInit, LZOpenFileA, LZOpenFileW, LZRead, LZSeek, OpenProcessToken, OpenThreadToken, RegCloseKey, RegCreateKeyExA, RegCreateKeyExW, RegDeleteKeyExA, RegDeleteKeyExW, RegDeleteValueA, RegDeleteValueW, RegEnumKeyExA, RegEnumKeyExW, RegEnumValueA, RegEnumValueW, RegFlushKey, RegGetKeySecurity, RegLoadKeyA, RegLoadKeyW, RegNotifyChangeKeyValue, RegOpenCurrentUser, RegOpenKeyExA, RegOpenKeyExW, RegOpenUserClassesRoot, RegQueryInfoKeyA, RegQueryInfoKeyW, RegQueryValueExA, RegQueryValueExW, RegRestoreKeyA, RegRestoreKeyW, RegSetKeySecurity, RegSetValueExA, RegSetValueW, RegUnLoadKeyA, RegUnLoadKeyW, RtlCaptureStackBackTrace, RtlFillMemory, RtlMoveMemory, RtlZeroMemory, SetThreadToken): Remove conflicting definition. * lib/th32.def: Remove. * lib/ntdll.def (RtlUnwind): Remove conflicting definition. * lib/version.def (VerLanguageNameA, VerLanguageNameW): Remove conflicting definition. However, I did not regenerate all def files, so there may be others as well. Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] import library overlap
2010/8/30 JonY :
> On 8/30/2010 21:00, Chris Sutcliffe wrote:
>> The latest crt (at least the one in the Cygwin 'dist' release) has
>> conflicting exports:
>>
>> csutc...@eush65 /usr/x86_64-w64-mingw32/sys-root/mingw/lib
>> $ x86_64-w64-mingw32-nm.exe libadvapi32.a | grep -i OpenProc
>> T OpenProcessToken
>> I __imp_OpenProcessToken
>>
>> csutc...@eush65 /usr/x86_64-w64-mingw32/sys-root/mingw/lib
>> $ x86_64-w64-mingw32-nm.exe libkernel32.a | grep -i OpenProc
>> T OpenProcessToken
>> I __imp_OpenProcessToken
>> T OpenProcess
>> I __imp_OpenProcess
>>
>> The OpenProcessToken in particular has come to bite me in a bad way
>> with Emerge Desktop. I ran in to this issue when using gendef to
>> update the def files for w32api, in that I had to check for multiple
>> export definitions of the same function and go to MSDN to determine
>> which library is expected to export a given function.
>>
>
> Thanks for the report. Do you have a list of symbols that are known to
> conflict?
>
>
> --
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
Hi Chris,
I suspect that it is real conflict in terms of double definition. It
is more likely that you get failures when you link to kernel32 symbol
and then attempt to start your app on an OS without this export in
kernel32. So this issue could be solved also by different
import-library order. Am I right? As the linker won't cause here
double defined symbols AFAIK, as it choose always the first seen
symbol and resolve by it.
Cheers,
Kai
PS: To comment out OpenProcessToken in kernel32.def is fine by me
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] import library overlap
On 8/30/2010 21:00, Chris Sutcliffe wrote: > The latest crt (at least the one in the Cygwin 'dist' release) has > conflicting exports: > > csutc...@eush65 /usr/x86_64-w64-mingw32/sys-root/mingw/lib > $ x86_64-w64-mingw32-nm.exe libadvapi32.a | grep -i OpenProc > T OpenProcessToken > I __imp_OpenProcessToken > > csutc...@eush65 /usr/x86_64-w64-mingw32/sys-root/mingw/lib > $ x86_64-w64-mingw32-nm.exe libkernel32.a | grep -i OpenProc > T OpenProcessToken > I __imp_OpenProcessToken > T OpenProcess > I __imp_OpenProcess > > The OpenProcessToken in particular has come to bite me in a bad way > with Emerge Desktop. I ran in to this issue when using gendef to > update the def files for w32api, in that I had to check for multiple > export definitions of the same function and go to MSDN to determine > which library is expected to export a given function. > Thanks for the report. Do you have a list of symbols that are known to conflict? -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] import library overlap
The latest crt (at least the one in the Cygwin 'dist' release) has conflicting exports: csutc...@eush65 /usr/x86_64-w64-mingw32/sys-root/mingw/lib $ x86_64-w64-mingw32-nm.exe libadvapi32.a | grep -i OpenProc T OpenProcessToken I __imp_OpenProcessToken csutc...@eush65 /usr/x86_64-w64-mingw32/sys-root/mingw/lib $ x86_64-w64-mingw32-nm.exe libkernel32.a | grep -i OpenProc T OpenProcessToken I __imp_OpenProcessToken T OpenProcess I __imp_OpenProcess The OpenProcessToken in particular has come to bite me in a bad way with Emerge Desktop. I ran in to this issue when using gendef to update the def files for w32api, in that I had to check for multiple export definitions of the same function and go to MSDN to determine which library is expected to export a given function. Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
