Re: [Mingw-w64-public] 64-bit dynamic libxml2

[Ozkan Sezer <sezeroz@gm...>]

On Wed, Nov 17, 2010 at 12:32 PM, Sisyphus <sisyphus1@...> wrote:
>
> ----- Original Message ----- From: "Ozkan Sezer" <sezeroz@...>
> To: "Sisyphus" <sisyphus1@...>
> Cc: "mingw64" <mingw-w64-public@...>
> Sent: Wednesday, November 17, 2010 9:00 PM
> Subject: Re: [Mingw-w64-public] 64-bit dynamic libxml2
>
>
>> On Wed, Nov 17, 2010 at 11:31 AM, Sisyphus <sisyphus1@...>
>> wrote:
>>>
>>> Reposting to list - last message blocked.
>>>
>>> ----- Original Message -----
>>> From: "Ozkan Sezer"
>>>
>>>>> These issues should be fixed in libxml2-2.7.8, please try
>>>>> it, instead.
>>>>>
>>>>> --
>>>>> O.S.
>>>>>
>>>>
>>>> Or, if you insist on using 2.7.7, see this bugzilla entry:
>>>> https://bugzilla.gnome.org/show_bug.cgi?id=614087
>>>
>>> Thanks O.S.
>>>
>>> No objection to switching to 2.7.8 - I would have done that anyway had I
>>> been aware of its existence (and I'm not really sure how I missed
>>> noticing
>>> it).
>>>
>>> Anyway, 2.7.8 takes care of the zlib problem but not the -lws2_32 issue
>>> ....
>>> so I'm still only getting a static build which, ironically, fails to
>>> define
>>> all symbols (such as '_imp__xmlFree', for obvious reasons).
>>>
>>> Here's the relevant section of output:
>>>
>>> ##################################
>>> *** Warning: linker path does not have real file for library -lws2_32.
>>> *** I have the capability to make that library automatically link in when
>>> *** you link to this library. But I can only do this if you have a
>>> *** shared version of the library, which you do not appear to have
>>> *** because I did check the linker path looking for a file starting
>>> *** with libws2_32 and none of the candidates passed a file format test
>>> *** using a file magic. Last file checked:
>>> /c/Windows/system32/libws2_32.dll
>>> *** The inter-library dependencies that have been dropped here will be
>>> *** automatically added whenever a program is linked with this library
>>> *** or is declared to -dlopen it.
>>>
>>> *** Since this library must not contain undefined symbols,
>>> *** because either the platform does not support them or
>>> *** it was explicitly requested with -no-undefined,
>>> *** libtool will only create a static version of it.
>>> libtool: link: x86_64-w64-mingw32-ar cru ......
>>> ##################################
>>>
>>> What needs to be done here ?
>>>
>>> Btw, that "Last file checked" (ie /c/Windows/system32/libws2_32.dll)
>>> doesn't even exist.
>>>
>>
>> Well, sorry that I responded without trying to compile myself.
>> This seems like another libtool screwup to me.  Pinging for
>> autotools/libtool gurus out there please?
>>
>
> That failure I reported happens when using the cross-compiler.
> Ozkan, I've  just now finished building 2.7.8 with one of your builds and it
> went fine.
>
> See the attached v.txt for the 'gcc -v' output of both compilers.
>
> Cheers,
> Rob

Well, I did test with a cross-compiler on linux.  I

Re: [Mingw-w64-public] 64-bit dynamic libxml2

[Sisyphus <sisyphus1@op...>]

Reposting to list - last message blocked.

----- Original Message ----- 
From: "Ozkan Sezer"

>> These issues should be fixed in libxml2-2.7.8, please try
>> it, instead.
>>
>> --
>> O.S.
>>
>
> Or, if you insist on using 2.7.7, see this bugzilla entry:
> https://bugzilla.gnome.org/show_bug.cgi?id=614087

Thanks O.S.

No objection to switching to 2.7.8 - I would have done that anyway had I
been aware of its existence (and I'm not really sure how I missed noticing
it).

Anyway, 2.7.8 takes care of the zlib problem but not the -lws2_32 issue ....
so I'm still only getting a static build which, ironically, fails to define
all symbols (such as '_imp__xmlFree', for obvious reasons).

Here's the relevant section of output:

##################################
*** Warning: linker path does not have real file for library -lws2_32.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libws2_32 and none of the candidates passed a file format test
*** using a file magic. Last file checked: /c/Windows/system32/libws2_32.dll
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.
libtool: link: x86_64-w64-mingw32-ar cru ......
##################################

What needs to be done here ?

Btw, that "Last file checked" (ie  /c/Windows/system32/libws2_32.dll)
doesn't even exist.

With these 64-bit libraries, should they load the System32 dll's, or should
they load the SysWOW64 dll's ? (Or doesn't it matter ?)

Cheers,
Rob

Re: [Mingw-w64-public] 64-bit dynamic libxml2

[Ozkan Sezer <sezeroz@gm...>]

On Wed, Nov 17, 2010 at 11:31 AM, Sisyphus <sisyphus1@...> wrote:
> Reposting to list - last message blocked.
>
> ----- Original Message -----
> From: "Ozkan Sezer"
>
>>> These issues should be fixed in libxml2-2.7.8, please try
>>> it, instead.
>>>
>>> --
>>> O.S.
>>>
>>
>> Or, if you insist on using 2.7.7, see this bugzilla entry:
>> https://bugzilla.gnome.org/show_bug.cgi?id=614087
>
> Thanks O.S.
>
> No objection to switching to 2.7.8 - I would have done that anyway had I
> been aware of its existence (and I'm not really sure how I missed noticing
> it).
>
> Anyway, 2.7.8 takes care of the zlib problem but not the -lws2_32 issue ....
> so I'm still only getting a static build which, ironically, fails to define
> all symbols (such as '_imp__xmlFree', for obvious reasons).
>
> Here's the relevant section of output:
>
> ##################################
> *** Warning: linker path does not have real file for library -lws2_32.
> *** I have the capability to make that library automatically link in when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have
> *** because I did check the linker path looking for a file starting
> *** with libws2_32 and none of the candidates passed a file format test
> *** using a file magic. Last file checked: /c/Windows/system32/libws2_32.dll
> *** The inter-library dependencies that have been dropped here will be
> *** automatically added whenever a program is linked with this library
> *** or is declared to -dlopen it.
>
> *** Since this library must not contain undefined symbols,
> *** because either the platform does not support them or
> *** it was explicitly requested with -no-undefined,
> *** libtool will only create a static version of it.
> libtool: link: x86_64-w64-mingw32-ar cru ......
> ##################################
>
> What needs to be done here ?
>
> Btw, that "Last file checked" (ie  /c/Windows/system32/libws2_32.dll)
> doesn't even exist.
>

Well, sorry that I responded without trying to compile myself.
This seems like another libtool screwup to me.  Pinging for
autotools/libtool gurus out there please?


> With these 64-bit libraries, should they load the System32 dll's, or should
> they load the SysWOW64 dll's ? (Or doesn't it matter ?)
>
> Cheers,
> Rob

--
O.S.

Re: [Mingw-w64-public] 64-bit dynamic libxml2

[Sisyphus <sisyphus1@op...>]

----- Original Message ----- 
From: "Ozkan Sezer" <sezeroz@...>
To: "Sisyphus" <sisyphus1@...>
Cc: "mingw64" <mingw-w64-public@...>
Sent: Wednesday, November 17, 2010 9:00 PM
Subject: Re: [Mingw-w64-public] 64-bit dynamic libxml2


> On Wed, Nov 17, 2010 at 11:31 AM, Sisyphus <sisyphus1@...> 
> wrote:
>> Reposting to list - last message blocked.
>>
>> ----- Original Message -----
>> From: "Ozkan Sezer"
>>
>>>> These issues should be fixed in libxml2-2.7.8, please try
>>>> it, instead.
>>>>
>>>> --
>>>> O.S.
>>>>
>>>
>>> Or, if you insist on using 2.7.7, see this bugzilla entry:
>>> https://bugzilla.gnome.org/show_bug.cgi?id=614087
>>
>> Thanks O.S.
>>
>> No objection to switching to 2.7.8 - I would have done that anyway had I
>> been aware of its existence (and I'm not really sure how I missed 
>> noticing
>> it).
>>
>> Anyway, 2.7.8 takes care of the zlib problem but not the -lws2_32 issue 
>> ....
>> so I'm still only getting a static build which, ironically, fails to 
>> define
>> all symbols (such as '_imp__xmlFree', for obvious reasons).
>>
>> Here's the relevant section of output:
>>
>> ##################################
>> *** Warning: linker path does not have real file for library -lws2_32.
>> *** I have the capability to make that library automatically link in when
>> *** you link to this library. But I can only do this if you have a
>> *** shared version of the library, which you do not appear to have
>> *** because I did check the linker path looking for a file starting
>> *** with libws2_32 and none of the candidates passed a file format test
>> *** using a file magic. Last file checked: 
>> /c/Windows/system32/libws2_32.dll
>> *** The inter-library dependencies that have been dropped here will be
>> *** automatically added whenever a program is linked with this library
>> *** or is declared to -dlopen it.
>>
>> *** Since this library must not contain undefined symbols,
>> *** because either the platform does not support them or
>> *** it was explicitly requested with -no-undefined,
>> *** libtool will only create a static version of it.
>> libtool: link: x86_64-w64-mingw32-ar cru ......
>> ##################################
>>
>> What needs to be done here ?
>>
>> Btw, that "Last file checked" (ie /c/Windows/system32/libws2_32.dll)
>> doesn't even exist.
>>
>
> Well, sorry that I responded without trying to compile myself.
> This seems like another libtool screwup to me.  Pinging for
> autotools/libtool gurus out there please?
>

That failure I reported happens when using the cross-compiler.
Ozkan, I've  just now finished building 2.7.8 with one of your builds and it 
went fine.

See the attached v.txt for the 'gcc -v' output of both compilers.

Cheers,
Rob 

Re: [Mingw-w64-public] 64-bit dynamic libxml2

[Ozkan Sezer <sezeroz@gm...>]

On Wed, Nov 17, 2010 at 12:32 PM, Sisyphus <sisyphus1@...> wrote:
>
> ----- Original Message ----- From: "Ozkan Sezer" <sezeroz@...>
> To: "Sisyphus" <sisyphus1@...>
> Cc: "mingw64" <mingw-w64-public@...>
> Sent: Wednesday, November 17, 2010 9:00 PM
> Subject: Re: [Mingw-w64-public] 64-bit dynamic libxml2
>
>
>> On Wed, Nov 17, 2010 at 11:31 AM, Sisyphus <sisyphus1@...>
>> wrote:
>>>
>>> Reposting to list - last message blocked.
>>>
>>> ----- Original Message -----
>>> From: "Ozkan Sezer"
>>>
>>>>> These issues should be fixed in libxml2-2.7.8, please try
>>>>> it, instead.
>>>>>
>>>>> --
>>>>> O.S.
>>>>>
>>>>
>>>> Or, if you insist on using 2.7.7, see this bugzilla entry:
>>>> https://bugzilla.gnome.org/show_bug.cgi?id=614087
>>>
>>> Thanks O.S.
>>>
>>> No objection to switching to 2.7.8 - I would have done that anyway had I
>>> been aware of its existence (and I'm not really sure how I missed
>>> noticing
>>> it).
>>>
>>> Anyway, 2.7.8 takes care of the zlib problem but not the -lws2_32 issue
>>> ....
>>> so I'm still only getting a static build which, ironically, fails to
>>> define
>>> all symbols (such as '_imp__xmlFree', for obvious reasons).
>>>
>>> Here's the relevant section of output:
>>>
>>> ##################################
>>> *** Warning: linker path does not have real file for library -lws2_32.
>>> *** I have the capability to make that library automatically link in when
>>> *** you link to this library. But I can only do this if you have a
>>> *** shared version of the library, which you do not appear to have
>>> *** because I did check the linker path looking for a file starting
>>> *** with libws2_32 and none of the candidates passed a file format test
>>> *** using a file magic. Last file checked:
>>> /c/Windows/system32/libws2_32.dll
>>> *** The inter-library dependencies that have been dropped here will be
>>> *** automatically added whenever a program is linked with this library
>>> *** or is declared to -dlopen it.
>>>
>>> *** Since this library must not contain undefined symbols,
>>> *** because either the platform does not support them or
>>> *** it was explicitly requested with -no-undefined,
>>> *** libtool will only create a static version of it.
>>> libtool: link: x86_64-w64-mingw32-ar cru ......
>>> ##################################
>>>
>>> What needs to be done here ?
>>>
>>> Btw, that "Last file checked" (ie /c/Windows/system32/libws2_32.dll)
>>> doesn't even exist.
>>>
>>
>> Well, sorry that I responded without trying to compile myself.
>> This seems like another libtool screwup to me.  Pinging for
>> autotools/libtool gurus out there please?
>>
>
> That failure I reported happens when using the cross-compiler.
> Ozkan, I've  just now finished building 2.7.8 with one of your builds and it
> went fine.
>
> See the attached v.txt for the 'gcc -v' output of both compilers.
>
> Cheers,
> Rob

Well, I did test with a cross-compiler on linux.  I

Re: [Mingw-w64-public] 64-bit dynamic libxml2

[Ozkan Sezer <sezeroz@gm...>]

On Wed, Nov 17, 2010 at 12:32 PM, Sisyphus <sisyphus1@...> wrote:
>
> ----- Original Message ----- From: "Ozkan Sezer" <sezeroz@...>
> To: "Sisyphus" <sisyphus1@...>
> Cc: "mingw64" <mingw-w64-public@...>
> Sent: Wednesday, November 17, 2010 9:00 PM
> Subject: Re: [Mingw-w64-public] 64-bit dynamic libxml2
>
>
>> On Wed, Nov 17, 2010 at 11:31 AM, Sisyphus <sisyphus1@...>
>> wrote:
>>>
>>> Reposting to list - last message blocked.
>>>
>>> ----- Original Message -----
>>> From: "Ozkan Sezer"
>>>
>>>>> These issues should be fixed in libxml2-2.7.8, please try
>>>>> it, instead.
>>>>>
>>>>> --
>>>>> O.S.
>>>>>
>>>>
>>>> Or, if you insist on using 2.7.7, see this bugzilla entry:
>>>> https://bugzilla.gnome.org/show_bug.cgi?id=614087
>>>
>>> Thanks O.S.
>>>
>>> No objection to switching to 2.7.8 - I would have done that anyway had I
>>> been aware of its existence (and I'm not really sure how I missed
>>> noticing
>>> it).
>>>
>>> Anyway, 2.7.8 takes care of the zlib problem but not the -lws2_32 issue
>>> ....
>>> so I'm still only getting a static build which, ironically, fails to
>>> define
>>> all symbols (such as '_imp__xmlFree', for obvious reasons).
>>>
>>> Here's the relevant section of output:
>>>
>>> ##################################
>>> *** Warning: linker path does not have real file for library -lws2_32.
>>> *** I have the capability to make that library automatically link in when
>>> *** you link to this library. But I can only do this if you have a
>>> *** shared version of the library, which you do not appear to have
>>> *** because I did check the linker path looking for a file starting
>>> *** with libws2_32 and none of the candidates passed a file format test
>>> *** using a file magic. Last file checked:
>>> /c/Windows/system32/libws2_32.dll
>>> *** The inter-library dependencies that have been dropped here will be
>>> *** automatically added whenever a program is linked with this library
>>> *** or is declared to -dlopen it.
>>>
>>> *** Since this library must not contain undefined symbols,
>>> *** because either the platform does not support them or
>>> *** it was explicitly requested with -no-undefined,
>>> *** libtool will only create a static version of it.
>>> libtool: link: x86_64-w64-mingw32-ar cru ......
>>> ##################################
>>>
>>> What needs to be done here ?
>>>
>>> Btw, that "Last file checked" (ie /c/Windows/system32/libws2_32.dll)
>>> doesn't even exist.
>>>
>>
>> Well, sorry that I responded without trying to compile myself.
>> This seems like another libtool screwup to me.  Pinging for
>> autotools/libtool gurus out there please?
>>
>
> That failure I reported happens when using the cross-compiler.
> Ozkan, I've  just now finished building 2.7.8 with one of your builds and it
> went fine.
>
> See the attached v.txt for the 'gcc -v' output of both compilers.
>
> Cheers,
> Rob

Well, I did test with a cross-compiler on linux.  If it is fine with a
native compiler, then it still is a bug.  Can you please report that
to their bugzilla?

--
O.S.

Re: [Mingw-w64-public] 64-bit dynamic libxml2

[Sisyphus <sisyphus1@op...>]

----- Original Message ----- 
From: "Ozkan Sezer"
To: "Sisyphus"

>> That failure I reported happens when using the cross-compiler.
>> Ozkan, I've just now finished building 2.7.8 with one of your builds and 
>> it
>> went fine.

> Well, I did test with a cross-compiler on linux.  If it is fine with a
> native compiler, then it still is a bug.  Can you please report that
> to their bugzilla?

Done:
https://bugzilla.gnome.org/show_bug.cgi?id=635123

Thanks again for the help.

Cheers,
Rob