On 9/7/2010 10:07, Xiaofan Chen wrote:
> On Tue, Sep 7, 2010 at 9:40 AM, JonY wrote:
>> I think I can see where the problem is, but I'm still guessing at this
>> point.
>>
>> TDM multilib has lib and lib32, but your non-multilib has lib and lib64, and
>> they are not linked. I suppose the fix is t
On 9/6/2010 8:05 PM, Xiaofan Chen wrote:
> Sorry I am not a compiler expert here. What is the difference between a
> multilib x86_64-w64-mingw32 compiler and a multilib i686-w64-mingw32
> compiler?
One defaults to the 32-bit target (i686-w64-mingw32), and the other
defaults to the 64-bit target
On Tue, Sep 7, 2010 at 9:40 AM, JonY wrote:
> I think I can see where the problem is, but I'm still guessing at this
> point.
>
> TDM multilib has lib and lib32, but your non-multilib has lib and lib64, and
> they are not linked. I suppose the fix is to move all the contents in lib
> (or lib64) to
On Mon, Sep 6, 2010 at 11:15 PM, John E. / TDM wrote:
> It is correct that TDM64 GCC does not include a "lib64" directory of any
> sort (symlink or copy). I've simply never found it necessary when building
> GCC or any of the other software I build on a regular basis.
>
> Since GCC searches the "
On 9/6/2010 21:13, Kai Tietz wrote:
> 2010/9/6 Xiaofan Chen:
>> On Mon, Sep 6, 2010 at 7:26 PM, JonY wrote:
>>> Are you using a multilib setup? There should not be a lib64 directory around
>>> for non-multilib toolchains.
>>>
>>> If you are using a multilib setup, lib is where the arch default lib
On 9/7/2010 09:37, Xiaofan Chen wrote:
> On Tue, Sep 7, 2010 at 8:12 AM, JonY wrote:
>>> My problem is that libtool was pointing to lib64 directory in the 64bit
>>> cross build (under Linux or 32bit Windows) cases. I need to check again
>>> under 32bit Win 7 with TDM.
>>>
>>> I just checked under
On Tue, Sep 7, 2010 at 8:12 AM, JonY wrote:
>> My problem is that libtool was pointing to lib64 directory in the 64bit
>> cross build (under Linux or 32bit Windows) cases. I need to check again
>> under 32bit Win 7 with TDM.
>>
>> I just checked under Windows 7 64bit and TDM64 is okay there
>> wit
On 9/7/2010 01:34, Mario Emmenlauer wrote:
>
> Hi,
>
> On 09/06/2010 04:52 PM, JonY wrote:
>> On 9/6/2010 19:50, Mario Emmenlauer wrote:
On 9/6/2010 15:52, Mario Emmenlauer wrote:
> I'm the original author of the issue [0] that Ismail referenced. During
> the last months since my repor
On 9/7/2010 07:53, Xiaofan Chen wrote:
> On Mon, Sep 6, 2010 at 11:15 PM, John E.> wrote:
>
>> It is correct that TDM64 GCC does not include a "lib64" directory of any
>> sort (symlink or copy). I've simply never found it necessary when building
>> GCC or any of the other software I build on a reg
On Mon, Sep 6, 2010 at 11:15 PM, John E. / TDM wrote:
> It is correct that TDM64 GCC does not include a "lib64" directory of any
> sort (symlink or copy). I've simply never found it necessary when building
> GCC or any of the other software I build on a regular basis.
>
> Since GCC searches the "
Hi,
On 09/06/2010 04:52 PM, JonY wrote:
> On 9/6/2010 19:50, Mario Emmenlauer wrote:
>>> On 9/6/2010 15:52, Mario Emmenlauer wrote:
I'm the original author of the issue [0] that Ismail referenced. During
the last months since my report, I've repeatedly re-tried numerous
times,
1. Now that we have a strnlen() implementation, I think we can also
remove the #if 0 out in tchar.h for it (I forgot doing so last time.)
2. We only have _mbstrnlen_l in msvcrt.def but we prototype both of
_mbstrnlen() and _mbstrnlen_l() in stdlib.h. We can macroize the
former to wrap onto the la
On 9/6/2010 9:56 AM, Ozkan Sezer wrote:
>>> On Mon, Sep 6, 2010 at 6:35 PM, John E. / TDM wrote:
Here is a correct (albeit slightly less performant than assembly) strnlen
implementation:
size_t strnlen(const char* s, size_t maxlen)
{
const char* s2 = s;
whi
On Mon, Sep 6, 2010 at 6:49 PM, Kai Tietz wrote:
> 2010/9/6 Ozkan Sezer :
>> On Mon, Sep 6, 2010 at 6:35 PM, John E. / TDM wrote:
>>> On 9/6/2010 6:14 AM, Ozkan Sezer wrote:
strnlen doesn't exist in msvcrt.dll from x86-winxp
we can implement it roughly like:
size_t
2010/9/6 Ozkan Sezer :
> On Mon, Sep 6, 2010 at 6:35 PM, John E. / TDM wrote:
>> On 9/6/2010 6:14 AM, Ozkan Sezer wrote:
>>>
>>> strnlen doesn't exist in msvcrt.dll from x86-winxp
>>>
>>> we can implement it roughly like:
>>>
>>> size_t __cdecl strnlen (const char *s, size_t maxlen)
>>> {
>>> s
On Mon, Sep 6, 2010 at 6:35 PM, John E. / TDM wrote:
> On 9/6/2010 6:14 AM, Ozkan Sezer wrote:
>>
>> strnlen doesn't exist in msvcrt.dll from x86-winxp
>>
>> we can implement it roughly like:
>>
>> size_t __cdecl strnlen (const char *s, size_t maxlen)
>> {
>> size_t siz = __builtin_strlen(s);
>
On 9/6/2010 6:14 AM, Ozkan Sezer wrote:
> strnlen doesn't exist in msvcrt.dll from x86-winxp
>
> we can implement it roughly like:
>
> size_t __cdecl strnlen (const char *s, size_t maxlen)
> {
>size_t siz = __builtin_strlen(s);
>if (siz> maxlen) siz = maxlen;
>return siz;
> }
This i
On 9/6/2010 8:49 AM, JonY wrote:
> On 9/6/2010 19:40, Xiaofan Chen wrote:
>> On Mon, Sep 6, 2010 at 7:26 PM, JonY wrote:
>>> Are you using a multilib setup? There should not be a lib64 directory around
>>> for non-multilib toolchains.
>> I also just tried TDM64 and it does not have lib64 direct
On 9/6/2010 19:50, Mario Emmenlauer wrote:
>
> Hi,
>
>> On 9/6/2010 15:52, Mario Emmenlauer wrote:
>>> I'm the original author of the issue [0] that Ismail referenced. During
>>> the last months since my report, I've repeatedly re-tried numerous
>>> times,
>>> but failed to build the canadian cross
On 9/6/2010 19:40, Xiaofan Chen wrote:
> On Mon, Sep 6, 2010 at 7:26 PM, JonY wrote:
>> Are you using a multilib setup? There should not be a lib64 directory around
>> for non-multilib toolchains.
>
> I have tried different binary downloads. The one from MinGW-w64 Sourceforge
> site and the one fr
2010/9/6 Xiaofan Chen :
> On Mon, Sep 6, 2010 at 7:26 PM, JonY wrote:
>> Are you using a multilib setup? There should not be a lib64 directory around
>> for non-multilib toolchains.
>>
>> If you are using a multilib setup, lib is where the arch default libraries
>> are. For x86_64-w64-mingw32, lib
On Mon, Sep 6, 2010 at 7:26 PM, JonY wrote:
> Are you using a multilib setup? There should not be a lib64 directory around
> for non-multilib toolchains.
>
> If you are using a multilib setup, lib is where the arch default libraries
> are. For x86_64-w64-mingw32, lib points to lib64.
>
BTW, for T
On Mon, Sep 6, 2010 at 3:22 PM, Kai Tietz wrote:
> 2010/9/6 Ozkan Sezer :
>> On Mon, Sep 6, 2010 at 3:11 PM, Kai Tietz wrote:
>>> 2010/9/6 Bidski :
Is there a reason why strnlen has been excluded thusly?
Regards
Bidski
>>>
>>> Hmm, not sure. I think it was due an iss
2010/9/6 Ozkan Sezer :
> On Mon, Sep 6, 2010 at 3:11 PM, Kai Tietz wrote:
>> 2010/9/6 Bidski :
>>> Is there a reason why strnlen has been excluded thusly?
>>>
>>> Regards
>>> Bidski
>>>
>>>
>>
>> Hmm, not sure. I think it was due an issue in building bootstrap, but
>> I can't recall it.
>>
>> Kai
Kai wrote:
>Hmm, not sure. I think it was due an issue in building bootstrap, but
>I can't recall it.
Is there a suggested work-a-round?
Regards
Bidski
--
This SF.net Dev2Dev email is sponsored by:
Show off your paral
On Mon, Sep 6, 2010 at 3:11 PM, Kai Tietz wrote:
> 2010/9/6 Bidski :
>> Is there a reason why strnlen has been excluded thusly?
>>
>> Regards
>> Bidski
>>
>>
>
> Hmm, not sure. I think it was due an issue in building bootstrap, but
> I can't recall it.
>
> Kai
strnlen doesn't exist in msvcrt.dll
2010/9/6 Bidski :
> Is there a reason why strnlen has been excluded thusly?
>
> Regards
> Bidski
>
>
Hmm, not sure. I think it was due an issue in building bootstrap, but
I can't recall it.
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him
Is there a reason why strnlen has been excluded thusly?
Regards
Bidski
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.ne
Hi,
> On 9/6/2010 15:52, Mario Emmenlauer wrote:
>> I'm the original author of the issue [0] that Ismail referenced. During
>> the last months since my report, I've repeatedly re-tried numerous
>> times,
>> but failed to build the canadian cross. Actually, back then mostly the
>> same suggestions
On Mon, Sep 6, 2010 at 7:26 PM, JonY wrote:
> Are you using a multilib setup? There should not be a lib64 directory around
> for non-multilib toolchains.
I have tried different binary downloads. The one from MinGW-w64 Sourceforge
site and the one from http://www.drangon.org/mingw/ both are not
mu
JonY wrote:
>Note the driver used for the compile test. C test passes but not C++. I
>think strnlen is disabled for C++, or maybe somebody forgot to include
>the correct headers.
In C:\MinGW\string.h there is the following
#if 0
size_t __cdecl strnlen(const char *_Str,size_t _MaxCount);
#endi
On 9/6/2010 19:01, Xiaofan Chen wrote:
> Last time we had some discussions in the libusb mailing list about
> using MinGW-w64 to build 64bit libusb-1.0 Windows backend.
>
> http://libusb.6.n5.nabble.com/PATCH-28-37-core-now-references-windows-backend-td8410i80.html#a1046006
>
> One issue we found i
On 9/6/2010 17:36, Bidski wrote:
> OK, I solved that original problem by copying the files from the
> C:\MinGW\x86_64-w64-mingw32 directory to the C:\MinGW directory, but now I
> am getting a problem with strnlen not being declared. The error is once
> again from building wxWidgets-2.9.1, during th
Last time we had some discussions in the libusb mailing list about
using MinGW-w64 to build 64bit libusb-1.0 Windows backend.
http://libusb.6.n5.nabble.com/PATCH-28-37-core-now-references-windows-backend-td8410i80.html#a1046006
One issue we found is that recent version of libtool is needed
to rec
Hi;
On Mon, Sep 6, 2010 at 1:02 PM, Pete Batard wrote:
> For those interested, I recently blogged about how one can get a working
> multilib MinGW-w64 on Linux, which includes how to work around the
> "skipping incompatible" errors [1].
>
> I'm pretty sure there's a much better way than what I d
For those interested, I recently blogged about how one can get a working
multilib MinGW-w64 on Linux, which includes how to work around the
"skipping incompatible" errors [1].
I'm pretty sure there's a much better way than what I did (for one
thing, I didn't use --with-sysroot), and it's likely
OK, I solved that original problem by copying the files from the
C:\MinGW\x86_64-w64-mingw32 directory to the C:\MinGW directory, but now I
am getting a problem with strnlen not being declared. The error is once
again from building wxWidgets-2.9.1, during the make stage this time though.
In fil
Hi;
On Mon, Sep 6, 2010 at 11:47 AM, JonY wrote:
> Did you link lib to lib64? And do you have lib32? Native cross-back works
> fine for me.
>
>
I do link lib64 to lib and I have lib32.
> Are you talking about a triple cross? I tried
> i686-linux->sparc-linux-mingw64 before, it works fine too.
On 9/6/2010 15:52, Mario Emmenlauer wrote:
>
> Hi,
>
> I'm the original author of the issue [0] that Ismail referenced. During
> the last months since my report, I've repeatedly re-tried numerous times,
> but failed to build the canadian cross. Actually, back then mostly the
> same suggestions wher
On Mon, Sep 6, 2010 at 11:45 AM, İsmail Dönmez wrote:
> Hi;
>
> On Mon, Sep 6, 2010 at 11:41 AM, Kai Tietz wrote
>
>> just for getting you right. Does initial cross-compiler fails, or then
>> the build of the canadian cross based on this cross-compiler?
>>
>>
> Initial gcc is fine, it fails in t
Hi;
On Mon, Sep 6, 2010 at 11:41 AM, Kai Tietz wrote
>
> just for getting you right. Does initial cross-compiler fails, or then
> the build of the canadian cross based on this cross-compiler?
>
>
Initial gcc is fine, it fails in the "Finishing GCC [
FNSHGC]" part mentioned in the gcc.
Regards,
i
Hi,
just for getting you right. Does initial cross-compiler fails, or then
the build of the canadian cross based on this cross-compiler?
Regards,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
--
Hi,
I'm the original author of the issue [0] that Ismail referenced. During
the last months since my report, I've repeatedly re-tried numerous times,
but failed to build the canadian cross. Actually, back then mostly the
same suggestions where given, tried, and failed. As you can see from my
post
On Mon, Sep 6, 2010 at 11:20 AM, JonY wrote:
>
> No, not path. By link, I meant using symlinks on Linux and junction points
> in Windows.
>
> The compiler looks in /usr/local/mingw64/mingw instead of
> /usr/local/mingw64/x86_64-w64-mingw32, so you'll need to link them.
>
Sorry I misunderstood but
On 9/6/2010 15:11, İsmail Dönmez wrote:
> Hi;
>
> On Mon, Sep 6, 2010 at 4:03 AM, JonY wrote:
>> On 9/6/2010 05:27, İsmail Dönmez wrote:
>>>
>>> Hi;
>>>
>>> On Mon, Sep 6, 2010 at 12:12 AM, Kai Tietz
>>> wrote:
Well, could you please try '../configure --host=x86_64-w64-mingw32
--e
Hi;
On Mon, Sep 6, 2010 at 4:03 AM, JonY wrote:
> On 9/6/2010 05:27, İsmail Dönmez wrote:
>>
>> Hi;
>>
>> On Mon, Sep 6, 2010 at 12:12 AM, Kai Tietz
>> wrote:
>>>
>>> Well, could you please try '../configure --host=x86_64-w64-mingw32
>>> --enable-lib32 --enable-lib64 --prefix=/usr/local/mingw64
46 matches
Mail list logo
