Re: [Mingw-w64-public] Compiling win32 compiler fails
On Thu, Dec 24, 2009 at 9:22 AM, Kai Tietz wrote:
> Ok, I see. I added to the comment that this just happens on
> cross-compile. Btw gendef should work as native build on linux, too.
> There shouldn't be any dependencies to Windows specific runtime.
Almost true... :)
Attached a patch.
Alon.
diff --git a/Makefile.am b/Makefile.am
index 1fe0933..8ccf260 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3,6 +3,6 @@ bin_PROGRAMS = gendef
gendef_LIBS = @LIBMANGLE_LIB@
gendef_CPPFLAGS = @LIBMANGLE_CPPFLAGS@
gendef_LDFLAGS = @LIBMANGLE_LDFLAGS@
-gendef_SOURCES = src/gendef.h src/gendef.c src/gendef_def.c
+gendef_SOURCES = src/gendef.h src/gendef.c src/gendef_def.c src/compat_string.c
gendef_CFLAGS = -O3 -g -Werror -Wall -Wextra
diff --git a/configure.ac b/configure.ac
index 3d00cab..85dbc35 100644
--- a/configure.ac
+++ b/configure.ac
@@ -32,7 +32,7 @@ AC_TYPE_UINT8_T
# is not available, it places in config.h the define of malloc as
# rpl_malloc. By this linkage could fail on cross-compiles.
#AC_FUNC_MALLOC
-AC_CHECK_FUNCS([memset strdup strrchr])
+AC_CHECK_FUNCS([memset strdup strrchr strlwr])
# Check for libmangle
libmangle_h=no
diff --git a/src/compat-string.h b/src/compat-string.h
new file mode 100644
index 000..769f750
--- /dev/null
+++ b/src/compat-string.h
@@ -0,0 +1,8 @@
+#ifndef __COMPAT_STRING_H
+#define __COMPAT_STRING_H
+
+#ifndef HAVE_STRLWER
+char *strlwr(char *s);
+#endif /* HAVE_STRLWER */
+
+#endif /* __COMPAT_STRING_H */
diff --git a/src/compat_string.c b/src/compat_string.c
new file mode 100644
index 000..fbf36d9
--- /dev/null
+++ b/src/compat_string.c
@@ -0,0 +1,19 @@
+#ifdef CONFIG_H
+#include
+#endif
+
+#ifndef HAVE_STRLWER
+
+#include
+#include "compat-string.h"
+
+char *strlwr(char *s) {
+ while(*s != '\x0') {
+ *s = tolower(*s);
+ s++;
+ }
+
+ return s;
+}
+
+#endif /* HAVE_STRLWER */
diff --git a/src/gendef.c b/src/gendef.c
index 6addc14..c5afd8a 100644
--- a/src/gendef.c
+++ b/src/gendef.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include "compat-string.h"
#include "gendef.h"
#ifdef HAVE_LIBMANGLE_H
#include
diff --git a/src/gendef_def.c b/src/gendef_def.c
index 156369a..09ac82e 100644
--- a/src/gendef_def.c
+++ b/src/gendef_def.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include "compat-string.h"
#include "gendef.h"
typedef struct sImpDef {
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev ___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Compiling win32 compiler fails
2009/12/23 Alon Bar-Lev :
> Oh... For the comment I understand that you did not fully understand
> the reason for failure...
>
> For testing if the malloc is gnu malloc or not a autoconf must try to
> *RUN* a program...
> ---
> int
> main ()
> {
> return ! malloc (0);
> ;
> return 0;
> }
> ---
>
> The problem is that when you cross compile autoconf cannot run any
> program, so it cannot detect malloc variant. So using this macro
> usually breaks cross compiling.
>
> Now I understand why I have some issues that you don't have... you run
> on Windows while I cross-compile all my programs in Linux... :)
>
> Alon.
>
> On Wed, Dec 23, 2009 at 3:29 PM, Kai Tietz wrote:
>> 2009/12/23 Alon Bar-Lev :
>>> On Wed, Dec 23, 2009 at 3:03 PM, Kai Tietz wrote:
The change about malloc isn't used AFAICS, but well I want to keep it,
as we plan to improve the conditional header includes in future.
Does this line leads to an build error for you?
>>>
>>> Yes... It is needed.
>>> Once the autoconf detects that gnu malloc is not available, it place
>>> #define malloc rpl_malloc in config.h.
>>> You do not have rpl_malloc in sources so linkage fail.
>>>
>>> Alon.
>>>
>>
>> Ok fixed. Thanks for the explaination.
>>
>> Cheers,
>> Kai
>>
>> --
>> | (\_/) This is Bunny. Copy and paste
>> | (='.'=) Bunny into your signature to help
>> | (")_(") him gain world domination
>>
>
Ok, I see. I added to the comment that this just happens on
cross-compile. Btw gendef should work as native build on linux, too.
There shouldn't be any dependencies to Windows specific runtime.
Cheers,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] problems with dllimport / dllexport
Hello Chris,
2009/12/23 Chris Sutcliffe :
> Hi Kai,
>
>> Ah, as you describe this, I am remembering, that there is a patch for
>> C++ FE pending (it is a bug), that the namespace should be able to
>> contain the dllexport/dllimport here.
>
> Fair enough, hopefully the patch will make it in to mainline gcc/g++.
Yes, if you could prepare a testcase for the scenario you have, I will
try to push a patch for this, or at least open a bug report on gcc's
bugzilla.
>> So this issue is most likely related to this. Maybe generate your
>> import-library by using export-all? Does this help?
>
> I tried -Wl,--export-all-symbols but that causes issues with the
> tinyxml library I have embedded in one of the libraries. Is there a
> way I can do an export-all per file?
Hmm, maybe on object level this should be possible, but it is a bit unhandy.
>> PS: Somehow it looks like that mingw.org has no real interest in
>> fixing the mingwm10.dll issue. But well, I tried to help.
>
> Indeed, it really is disheartening. The person I was most hoping
> would respond is Aaron, but it looks like he's MIA again.
>
> Similar can be said for the GDB question I posted. It really seems
> like there is little interest in MinGW from the rest of the mingw.org
> team at this point. Is there any interest in me packaging GDB for
> mingw-w32? I can take a stab at packaging it for mingw-w64 as well
> (but I don't have a 64-bit machine to test it on).
Yes, it would be good to provide a mingw-w32 version of gdb, too. In
general it would be good to have somebody taking care about regular
updates for gdb. So a mingw-w32 package would be most welcome.
Cheers,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] problems with dllimport / dllexport
Hi Kai, > Ah, as you describe this, I am remembering, that there is a patch for > C++ FE pending (it is a bug), that the namespace should be able to > contain the dllexport/dllimport here. Fair enough, hopefully the patch will make it in to mainline gcc/g++. > So this issue is most likely related to this. Maybe generate your > import-library by using export-all? Does this help? I tried -Wl,--export-all-symbols but that causes issues with the tinyxml library I have embedded in one of the libraries. Is there a way I can do an export-all per file? > PS: Somehow it looks like that mingw.org has no real interest in > fixing the mingwm10.dll issue. But well, I tried to help. Indeed, it really is disheartening. The person I was most hoping would respond is Aaron, but it looks like he's MIA again. Similar can be said for the GDB question I posted. It really seems like there is little interest in MinGW from the rest of the mingw.org team at this point. Is there any interest in me packaging GDB for mingw-w32? I can take a stab at packaging it for mingw-w64 as well (but I don't have a 64-bit machine to test it on). Cheers! Chris -- Chris Sutcliffe http://emergedesktop.org -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Simplifying new def addition
2009/12/23 Alon Bar-Lev :
> Hello,
>
> Just an idea... I had to add pdh.def into current build.
>
> Steps:
> 1. Add pdh.def into mingw-w64-crt/lib32
> 2. Add the following to mingw-w64-crt/Makefile.am
> cat << __EOF__ >> mingw-w64-crt/Makefile.am
> if LIB32
> lib32_SCRIPTS += lib32/libpdh.a
> endif
> __EOF__
> 3. Do autoreconf
>
> It would be great if this process was much simpler... Add pdh.def into
> mingw-w64-crt/lib32 and that's it.
> Of course this applies for "simple" defs.
>
> It can be done easily using autoconf... It can do something like:
>
> autoconf:
> ---
> LIB32_LIBS="$(echo $((cd mingw-w64-crt && find lib32 -name '*.def' ) |
> sed 's#\([^/]*\)\.def#lib\1.a#'))"
> AC_SUBST([LIB32_LIBS])
> ---
> automake:
> ---
> lib32_SCRIPTS = @LIB32_LIBS@
> ---
>
> What do you think?
> Alon.
>
> --
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
Well, in general this would be a good thing. There is just one nit,
which needs here special care. For some .def files we add additional
object files, which possibly won't work then anymore. Well, I am not
an autotools expert (for this mainly NightStrike is responsible), but
to simplify our build would be indeed something I would be
appreciated.
Cheers,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Simplifying new def addition
Hello, Just an idea... I had to add pdh.def into current build. Steps: 1. Add pdh.def into mingw-w64-crt/lib32 2. Add the following to mingw-w64-crt/Makefile.am cat << __EOF__ >> mingw-w64-crt/Makefile.am if LIB32 lib32_SCRIPTS += lib32/libpdh.a endif __EOF__ 3. Do autoreconf It would be great if this process was much simpler... Add pdh.def into mingw-w64-crt/lib32 and that's it. Of course this applies for "simple" defs. It can be done easily using autoconf... It can do something like: autoconf: --- LIB32_LIBS="$(echo $((cd mingw-w64-crt && find lib32 -name '*.def' ) | sed 's#\([^/]*\)\.def#lib\1.a#'))" AC_SUBST([LIB32_LIBS]) --- automake: --- lib32_SCRIPTS = @LIB32_LIBS@ --- What do you think? Alon. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Compiling win32 compiler fails
Oh... For the comment I understand that you did not fully understand
the reason for failure...
For testing if the malloc is gnu malloc or not a autoconf must try to
*RUN* a program...
---
int
main ()
{
return ! malloc (0);
;
return 0;
}
---
The problem is that when you cross compile autoconf cannot run any
program, so it cannot detect malloc variant. So using this macro
usually breaks cross compiling.
Now I understand why I have some issues that you don't have... you run
on Windows while I cross-compile all my programs in Linux... :)
Alon.
On Wed, Dec 23, 2009 at 3:29 PM, Kai Tietz wrote:
> 2009/12/23 Alon Bar-Lev :
>> On Wed, Dec 23, 2009 at 3:03 PM, Kai Tietz wrote:
>>> The change about malloc isn't used AFAICS, but well I want to keep it,
>>> as we plan to improve the conditional header includes in future.
>>> Does this line leads to an build error for you?
>>
>> Yes... It is needed.
>> Once the autoconf detects that gnu malloc is not available, it place
>> #define malloc rpl_malloc in config.h.
>> You do not have rpl_malloc in sources so linkage fail.
>>
>> Alon.
>>
>
> Ok fixed. Thanks for the explaination.
>
> Cheers,
> Kai
>
> --
> | (\_/) This is Bunny. Copy and paste
> | (='.'=) Bunny into your signature to help
> | (")_(") him gain world domination
>
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Compiling win32 compiler fails
2009/12/23 Alon Bar-Lev :
> On Wed, Dec 23, 2009 at 3:03 PM, Kai Tietz wrote:
>> The change about malloc isn't used AFAICS, but well I want to keep it,
>> as we plan to improve the conditional header includes in future.
>> Does this line leads to an build error for you?
>
> Yes... It is needed.
> Once the autoconf detects that gnu malloc is not available, it place
> #define malloc rpl_malloc in config.h.
> You do not have rpl_malloc in sources so linkage fail.
>
> Alon.
>
Ok fixed. Thanks for the explaination.
Cheers,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Compiling win32 compiler fails
2009/12/23 Alon Bar-Lev :
> Great!
> It works.
Thanks for testing. I will apply it to v1.0 branch and trunk.
> But... Why there is a huge difference between lib64 and lib32 libraries?
> I see that lib32 contains only 142 libraries while lib64 contains 2042.
>
> For example libpdh is missing in lib32.
Well, for 64-bit we generated those import libraries by gendef tool.
For 32-bit we took as initial set the .def files from mingw.org (we
extended already some of them). So if you want to have specific import
libraries generated, feel free to use our gendef tool on this DLL and
review if the imports described are matching. If you want to provide
your generated .def file(s) and that it becomes part of default crt
build, be welcome to post the .def file for x86.
Cheers,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Compiling win32 compiler fails
Great!
It works.
But... Why there is a huge difference between lib64 and lib32 libraries?
I see that lib32 contains only 142 libraries while lib64 contains 2042.
For example libpdh is missing in lib32.
On Wed, Dec 23, 2009 at 12:57 PM, Kai Tietz wrote:
> 2009/12/22 Kai Tietz :
>> 2009/12/22 Alon Bar-Lev :
>>> On Tue, Dec 22, 2009 at 9:53 PM, Kai Tietz wrote:
2009/12/22 Alon Bar-Lev :
> Hi,
>
> I think that i686-w64-mingw32 should be supported, right?
> At least it would be great if it is as this project is much more
> maintained and complete than mingw32.
>
> While trying to do so, I get the following... And indeed the
> declaration is duplicated.
> I tested both v1.0 and trunk snapshots, gcc is 4.4.2.
>
> x86_64-w64-mingw32 compiles OK.
>
> /var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/mingw64-runtime-20091222/work/sysroot/usr/i686-w64-mingw32/include/intrin.h:585:
> error: conflicting types for ‘_mm_shuffle_ps’
> /usr/lib/gcc/i686-w64-mingw32/4.4.2/include/xmmintrin.h:716: note:
> previous definition of ‘_mm_shuffle_ps’ was here
> make[1]: *** [intrincs/lib32_libmingwex_a-readfsword.o] Error 1
> make[1]: *** Waiting for unfinished jobs
> In file included from intrincs/readfsbyte.c:1:
> /var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/mingw64-runtime-20091222/work/sysroot/usr/i686-w64-mingw32/include/intrin.h:585:
> error: conflicting types for ‘_mm_shuffle_ps’
> /usr/lib/gcc/i686-w64-mingw32/4.4.2/include/xmmintrin.h:716: note:
> previous definition of ‘_mm_shuffle_ps’ was here
> make[1]: *** [intrincs/lib32_libmingwex_a-readfsbyte.o] Error 1
> In file included from intrincs/readfsdword.c:1:
> /var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/mingw64-runtime-20091222/work/sysroot/usr/i686-w64-mingw32/include/intrin.h:585:
> error: conflicting types for ‘_mm_shuffle_ps’
> /usr/lib/gcc/i686-w64-mingw32/4.4.2/include/xmmintrin.h:716: note:
> previous definition of ‘_mm_shuffle_ps’ was here
> make[1]: *** [intrincs/lib32_libmingwex_a-readfsdword.o] Error 1
> make[1]: Leaving directory
> `/var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/mingw64-runtime-20091222/work/trunk/mingw-w64-crt'
> make: *** [all] Error 2
>
> --
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
Yes, i686 should be supported and I am curious about this warning, but
well, you are using 4.4.2 gcc.
I'll try to find out where this issue comes from and then prepare a
fix for this.
Cheers,
Kai
>>>
>>> Which gcc should I use?
>>>
>>
>> Well, 4.4.2 isn't bad. But the upcoming 4.4.3 has some bug-fixes maybe
>> worth to have.
>>
>> Cheers,
>> Kai
>
> So ... The issue is reasoned by a prototype. This function has args
> (__m128,__m128,int const) and not as we wrote (__m128,__m128,unsigned
> int).
>
> Does the following patch fixes your problem? (I tried to reproduce
> this error, but hadn't luck.
>
> Cheers,
> Kai
>
> Index: intrin.h
> ===
> --- intrin.h (revision 1670)
> +++ intrin.h (working copy)
> @@ -582,7 +582,7 @@
> __MACHINEX86X_NOWIN64(__m64 _mm_cvtt_ps2pi(__m128))
> __MACHINEX86X_NOIA64(__m128 _mm_cvt_si2ss(__m128,int))
> __MACHINEX86X_NOWIN64(__m128 _mm_cvt_pi2ps(__m128,__m64))
> - __MACHINEX86X_NOIA64(__m128 _mm_shuffle_ps(__m128,__m128,unsigned int))
> + __MACHINEX86X_NOIA64(__m128 _mm_shuffle_ps(__m128,__m128,int const))
> __MACHINEX86X_NOIA64(__m128 _mm_unpackhi_ps(__m128,__m128))
> __MACHINEX86X_NOIA64(__m128 _mm_unpacklo_ps(__m128,__m128))
> __MACHINEX86X_NOIA64(__m128 _mm_loadh_pi(__m128,__m64 const*))
>
>
>
> --
> | (\_/) This is Bunny. Copy and paste
> | (='.'=) Bunny into your signature to help
> | (")_(") him gain world domination
>
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-publ
Re: [Mingw-w64-public] problems with dllimport / dllexport
2009/12/23 Chris Sutcliffe :
> Hi Kai,
>
>> I didn't noticed this change in behavior. Could you provide to me some
>> small testcase by which I can reproduce this?
>
> I'll create a simple test case over the holidays. As it stands today,
> I see it with my Emerge Desktop application, but it by no means is a
> simple test case.
>
>> The only thing you should be aware is, that by using shared C++ you
>> get linker warnings about autoimports, when you didn't specified
>> --enable-autoimports for linker. Did it helps if you specify option
>> -static?
>
> I see the C++ import warnings, and as you mentioned I addressed them
> by adding -Wl,--enable-auto-import but it did not help the problem of
> undefined references that I'm seeing. The issue is actually the
> classes being export by Emerge Desktop's shared libraries, for
> example:
>
> ../.objs64/Release/emergeTasks/Config.o:Config.cpp:(.text+0xef):
> undefined reference to `_imp___ZN16BasePositionPageD1Ev'
> ../.objs64/Release/emergeTasks/Config.o:Config.cpp:(.text+0x11f):
> undefined reference to `_imp___ZN12SchemeEditorD1Ev'
> ../.objs64/Release/emergeTasks/Config.o:Config.cpp:(.text+0x882):
> undefined reference to
> `_imp___ZN16BasePositionPageC1ENSt3tr110shared_ptrI12BaseSettingsEEj'
> ../.objs64/Release/emergeTasks/Config.o:Config.cpp:(.text+0x90b):
> undefined reference to `_imp___ZN12SchemeEditorC1EP6HWND__'
>
> Where BasePositionPage, SchemeEditor and BaseSettings are exported
> classes from Emerge Desktop's shared libraries.
>
> Hrm interestingly enough, all the undefined references I'm seeing
> are from exported classes, exported functions seem to be fine.
> Perhaps this is an issue with dllexport / dllimport and C++ classes?
>
> Cheers!
>
> Chris
>
> --
> Chris Sutcliffe
> http://emergedesktop.org
>
> --
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
Ah, as you describe this, I am remembering, that there is a patch for
C++ FE pending (it is a bug), that the namespace should be able to
contain the dllexport/dllimport here.
So this issue is most likely related to this. Maybe generate your
import-library by using export-all? Does this help?
Cheers,
Kai
PS: Somehow it looks like that mingw.org has no real interest in
fixing the mingwm10.dll issue. But well, I tried to help.
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Compiling win32 compiler fails
On Wed, Dec 23, 2009 at 3:03 PM, Kai Tietz wrote: > The change about malloc isn't used AFAICS, but well I want to keep it, > as we plan to improve the conditional header includes in future. > Does this line leads to an build error for you? Yes... It is needed. Once the autoconf detects that gnu malloc is not available, it place #define malloc rpl_malloc in config.h. You do not have rpl_malloc in sources so linkage fail. Alon. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Compiling win32 compiler fails
2009/12/23 Alon Bar-Lev :
> OK.
> Thanks.
>
> I had to fixup the gendef...
>
> 1. You check for gnu compliant malloc but not define the rpl_malloc,
> so I removed this check.
> 2. You treat warnings as errors and do not eliminate unused parameters.
Thanks for reporting this warning. I committed an altered version
(some additional parameter checks, which don't hurt here).
The change about malloc isn't used AFAICS, but well I want to keep it,
as we plan to improve the conditional header includes in future.
Does this line leads to an build error for you?
Cheers,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] problems with dllimport / dllexport
Hi Kai, > I didn't noticed this change in behavior. Could you provide to me some > small testcase by which I can reproduce this? I'll create a simple test case over the holidays. As it stands today, I see it with my Emerge Desktop application, but it by no means is a simple test case. > The only thing you should be aware is, that by using shared C++ you > get linker warnings about autoimports, when you didn't specified > --enable-autoimports for linker. Did it helps if you specify option > -static? I see the C++ import warnings, and as you mentioned I addressed them by adding -Wl,--enable-auto-import but it did not help the problem of undefined references that I'm seeing. The issue is actually the classes being export by Emerge Desktop's shared libraries, for example: ../.objs64/Release/emergeTasks/Config.o:Config.cpp:(.text+0xef): undefined reference to `_imp___ZN16BasePositionPageD1Ev' ../.objs64/Release/emergeTasks/Config.o:Config.cpp:(.text+0x11f): undefined reference to `_imp___ZN12SchemeEditorD1Ev' ../.objs64/Release/emergeTasks/Config.o:Config.cpp:(.text+0x882): undefined reference to `_imp___ZN16BasePositionPageC1ENSt3tr110shared_ptrI12BaseSettingsEEj' ../.objs64/Release/emergeTasks/Config.o:Config.cpp:(.text+0x90b): undefined reference to `_imp___ZN12SchemeEditorC1EP6HWND__' Where BasePositionPage, SchemeEditor and BaseSettings are exported classes from Emerge Desktop's shared libraries. Hrm interestingly enough, all the undefined references I'm seeing are from exported classes, exported functions seem to be fine. Perhaps this is an issue with dllexport / dllimport and C++ classes? Cheers! Chris -- Chris Sutcliffe http://emergedesktop.org -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Compiling win32 compiler fails
OK.
Thanks.
I had to fixup the gendef...
1. You check for gnu compliant malloc but not define the rpl_malloc,
so I removed this check.
2. You treat warnings as errors and do not eliminate unused parameters.
Attached is a patch.
Alon
On Wed, Dec 23, 2009 at 2:28 PM, Kai Tietz wrote:
> 2009/12/23 Alon Bar-Lev :
>> Great!
>> It works.
>
> Thanks for testing. I will apply it to v1.0 branch and trunk.
>
>> But... Why there is a huge difference between lib64 and lib32 libraries?
>> I see that lib32 contains only 142 libraries while lib64 contains 2042.
>>
>> For example libpdh is missing in lib32.
>
> Well, for 64-bit we generated those import libraries by gendef tool.
> For 32-bit we took as initial set the .def files from mingw.org (we
> extended already some of them). So if you want to have specific import
> libraries generated, feel free to use our gendef tool on this DLL and
> review if the imports described are matching. If you want to provide
> your generated .def file(s) and that it becomes part of default crt
> build, be welcome to post the .def file for x86.
>
> Cheers,
> Kai
>
> --
> | (\_/) This is Bunny. Copy and paste
> | (='.'=) Bunny into your signature to help
> | (")_(") him gain world domination
>
gendef.patch
Description: Binary data
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev ___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Compiling win32 compiler fails
2009/12/22 Kai Tietz :
> 2009/12/22 Alon Bar-Lev :
>> On Tue, Dec 22, 2009 at 9:53 PM, Kai Tietz wrote:
>>> 2009/12/22 Alon Bar-Lev :
Hi,
I think that i686-w64-mingw32 should be supported, right?
At least it would be great if it is as this project is much more
maintained and complete than mingw32.
While trying to do so, I get the following... And indeed the
declaration is duplicated.
I tested both v1.0 and trunk snapshots, gcc is 4.4.2.
x86_64-w64-mingw32 compiles OK.
/var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/mingw64-runtime-20091222/work/sysroot/usr/i686-w64-mingw32/include/intrin.h:585:
error: conflicting types for ‘_mm_shuffle_ps’
/usr/lib/gcc/i686-w64-mingw32/4.4.2/include/xmmintrin.h:716: note:
previous definition of ‘_mm_shuffle_ps’ was here
make[1]: *** [intrincs/lib32_libmingwex_a-readfsword.o] Error 1
make[1]: *** Waiting for unfinished jobs
In file included from intrincs/readfsbyte.c:1:
/var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/mingw64-runtime-20091222/work/sysroot/usr/i686-w64-mingw32/include/intrin.h:585:
error: conflicting types for ‘_mm_shuffle_ps’
/usr/lib/gcc/i686-w64-mingw32/4.4.2/include/xmmintrin.h:716: note:
previous definition of ‘_mm_shuffle_ps’ was here
make[1]: *** [intrincs/lib32_libmingwex_a-readfsbyte.o] Error 1
In file included from intrincs/readfsdword.c:1:
/var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/mingw64-runtime-20091222/work/sysroot/usr/i686-w64-mingw32/include/intrin.h:585:
error: conflicting types for ‘_mm_shuffle_ps’
/usr/lib/gcc/i686-w64-mingw32/4.4.2/include/xmmintrin.h:716: note:
previous definition of ‘_mm_shuffle_ps’ was here
make[1]: *** [intrincs/lib32_libmingwex_a-readfsdword.o] Error 1
make[1]: Leaving directory
`/var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/mingw64-runtime-20091222/work/trunk/mingw-w64-crt'
make: *** [all] Error 2
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and
easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>>
>>> Yes, i686 should be supported and I am curious about this warning, but
>>> well, you are using 4.4.2 gcc.
>>> I'll try to find out where this issue comes from and then prepare a
>>> fix for this.
>>>
>>> Cheers,
>>> Kai
>>
>> Which gcc should I use?
>>
>
> Well, 4.4.2 isn't bad. But the upcoming 4.4.3 has some bug-fixes maybe
> worth to have.
>
> Cheers,
> Kai
So ... The issue is reasoned by a prototype. This function has args
(__m128,__m128,int const) and not as we wrote (__m128,__m128,unsigned
int).
Does the following patch fixes your problem? (I tried to reproduce
this error, but hadn't luck.
Cheers,
Kai
Index: intrin.h
===
--- intrin.h(revision 1670)
+++ intrin.h(working copy)
@@ -582,7 +582,7 @@
__MACHINEX86X_NOWIN64(__m64 _mm_cvtt_ps2pi(__m128))
__MACHINEX86X_NOIA64(__m128 _mm_cvt_si2ss(__m128,int))
__MACHINEX86X_NOWIN64(__m128 _mm_cvt_pi2ps(__m128,__m64))
-__MACHINEX86X_NOIA64(__m128 _mm_shuffle_ps(__m128,__m128,unsigned int))
+__MACHINEX86X_NOIA64(__m128 _mm_shuffle_ps(__m128,__m128,int const))
__MACHINEX86X_NOIA64(__m128 _mm_unpackhi_ps(__m128,__m128))
__MACHINEX86X_NOIA64(__m128 _mm_unpacklo_ps(__m128,__m128))
__MACHINEX86X_NOIA64(__m128 _mm_loadh_pi(__m128,__m64 const*))
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
