Distutils: using different linker options for c++ and c code

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Distutils: using different linker options for c++ and c code

cdavid
Hi,

    I cannot seem to make scipy.sparse works on windows with mingw32,
and it seems related to the msvc runtime. I always get segfaults in the
sparsetools module (c++); if I build the module manually to control the
options precisely and remove the -lmsvc71 from the build command, I
cannot reproduce the segfault anymore (but the segfault does not happen
100 % of the time, so it is hard to be sure)

    So is there a way in distutils to make the difference between C++
and C: for extension with C, use the msvc, for extensions in C++, do not
use it ? (The obvious hack consisting in remove msvc alltogether does
not work: it crahses in scipy.io, which is linked to incompatible FILE
structures between mingw and VS, I guess).

    thanks,

    David
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Distutils: using different linker options for c++ and c code

Robert Kern-2
On Thu, Apr 17, 2008 at 6:34 AM, David Cournapeau
<[hidden email]> wrote:

> Hi,
>
>     I cannot seem to make scipy.sparse works on windows with mingw32,
>  and it seems related to the msvc runtime. I always get segfaults in the
>  sparsetools module (c++); if I build the module manually to control the
>  options precisely and remove the -lmsvc71 from the build command, I
>  cannot reproduce the segfault anymore (but the segfault does not happen
>  100 % of the time, so it is hard to be sure)
>
>     So is there a way in distutils to make the difference between C++
>  and C: for extension with C, use the msvc, for extensions in C++, do not
>  use it ? (The obvious hack consisting in remove msvc alltogether does
>  not work: it crahses in scipy.io, which is linked to incompatible FILE
>  structures between mingw and VS, I guess).

Ah, this problem again. The build of mingw that you are using were
written with msvcrt in mind. For the most part they are compatible
with msvcr71, but there are a few places where they reference a table
that is different between the two runtimes, namely iostream in C++ and
ischar() in C. Consequently, there are some extension modules built
with mingw which work with msvcrt because they need iostream, some
with msvcr71 because they need to pass FILE pointers, and probably
some which won't work with either. The core problem won't be fixed
until mingw writes their headers for msvcr71. They may have; it looks
like they just released some new builds this month. It would be worth
checking these out.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
 -- Umberto Eco
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Distutils: using different linker options for c++ and c code

cdavid
Robert Kern wrote:
>
> Ah, this problem again. The build of mingw that you are using were
> written with msvcrt in mind. For the most part they are compatible
> with msvcr71, but there are a few places where they reference a table
> that is different between the two runtimes, namely iostream in C++ and
> ischar() in C.

Do you know by any chance any document/email which talks about that ?
The only things I found were very general (I know file related do not
work, but that's it).

> Consequently, there are some extension modules built
> with mingw which work with msvcrt because they need iostream, some
> with msvcr71 because they need to pass FILE pointers, and probably
> some which won't work with either. The core problem won't be fixed
> until mingw writes their headers for msvcr71. They may have; it looks
> like they just released some new builds this month. It would be worth
> checking these out.
>  

Are you talking about the 3.* or the 4.* releases ?

The new 3.* release seems to only contain a new release note (all the
files except the release note have 20060117-2 in their names).

I also found an unofficial installer for gcc 4.*, which at least claim
to care about python:

http://www.develer.com/oss/GccWinBinaries

The problems with the new official (but beta) 4.* builds is the lack of
fortran support. For some reasons, building gfortran on windows does not
sound really appealing :) Also, I noticed when developing numscons that
numpy (implicetely ?) relied on buggy mingw headers, bugs which were
fixed in 4.* and hence did not work forr numpy (nothing serious, though;
it should be easily fixable in distutils).

Thank you for those information, I will dig a bit deeper. Should we
consider this as a major blocker for numpy as well (since it would not
be possible to build a working scipy with numpy 1.1.0 ?) ?

David

_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Distutils: using different linker options for c++ and c code

Robert Kern-2
On Thu, Apr 17, 2008 at 9:36 PM, David Cournapeau
<[hidden email]> wrote:

> Robert Kern wrote:
>  >
>  > Ah, this problem again. The build of mingw that you are using were
>  > written with msvcrt in mind. For the most part they are compatible
>  > with msvcr71, but there are a few places where they reference a table
>  > that is different between the two runtimes, namely iostream in C++ and
>  > ischar() in C.
>
>  Do you know by any chance any document/email which talks about that ?
>  The only things I found were very general (I know file related do not
>  work, but that's it).

Only my own emails. I found this out by largely experimentation and
reading the header files.

>  > Consequently, there are some extension modules built
>  > with mingw which work with msvcrt because they need iostream, some
>  > with msvcr71 because they need to pass FILE pointers, and probably
>  > some which won't work with either. The core problem won't be fixed
>  > until mingw writes their headers for msvcr71. They may have; it looks
>  > like they just released some new builds this month. It would be worth
>  > checking these out.
>
>  Are you talking about the 3.* or the 4.* releases ?
>  The new 3.* release seems to only contain a new release note (all the
>  files except the release note have 20060117-2 in their names).

Ah, I missed that. It looks like it's just a re-release of the 2006
build with a bugfix for Vista.

>  I also found an unofficial installer for gcc 4.*, which at least claim
>  to care about python:
>
>  http://www.develer.com/oss/GccWinBinaries
>
>  The problems with the new official (but beta) 4.* builds is the lack of
>  fortran support. For some reasons, building gfortran on windows does not
>  sound really appealing :) Also, I noticed when developing numscons that
>  numpy (implicetely ?) relied on buggy mingw headers, bugs which were
>  fixed in 4.* and hence did not work forr numpy (nothing serious, though;
>  it should be easily fixable in distutils).

What were these problems?

>  Thank you for those information, I will dig a bit deeper. Should we
>  consider this as a major blocker for numpy as well (since it would not
>  be possible to build a working scipy with numpy 1.1.0 ?) ?

It depends entirely on what the ultimate solution is. I don't think
that numpy can be "fixed" in order to solve this problem.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
 -- Umberto Eco
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Distutils: using different linker options for c++ and c code

cdavid
Robert Kern wrote:

> On Thu, Apr 17, 2008 at 9:36 PM, David Cournapeau
> <[hidden email]> wrote:
>  
>> Robert Kern wrote:
>>  >
>>  > Ah, this problem again. The build of mingw that you are using were
>>  > written with msvcrt in mind. For the most part they are compatible
>>  > with msvcr71, but there are a few places where they reference a table
>>  > that is different between the two runtimes, namely iostream in C++ and
>>  > ischar() in C.
>>
>>  Do you know by any chance any document/email which talks about that ?
>>  The only things I found were very general (I know file related do not
>>  work, but that's it).
>>    
>
> Only my own emails. I found this out by largely experimentation and
> reading the header files.
>
>  
>>  > Consequently, there are some extension modules built
>>  > with mingw which work with msvcrt because they need iostream, some
>>  > with msvcr71 because they need to pass FILE pointers, and probably
>>  > some which won't work with either. The core problem won't be fixed
>>  > until mingw writes their headers for msvcr71. They may have; it looks
>>  > like they just released some new builds this month. It would be worth
>>  > checking these out.
>>
>>  Are you talking about the 3.* or the 4.* releases ?
>>  The new 3.* release seems to only contain a new release note (all the
>>  files except the release note have 20060117-2 in their names).
>>    
>
> Ah, I missed that. It looks like it's just a re-release of the 2006
> build with a bugfix for Vista.
>
>  
>>  I also found an unofficial installer for gcc 4.*, which at least claim
>>  to care about python:
>>
>>  http://www.develer.com/oss/GccWinBinaries
>>
>>  The problems with the new official (but beta) 4.* builds is the lack of
>>  fortran support. For some reasons, building gfortran on windows does not
>>  sound really appealing :) Also, I noticed when developing numscons that
>>  numpy (implicetely ?) relied on buggy mingw headers, bugs which were
>>  fixed in 4.* and hence did not work forr numpy (nothing serious, though;
>>  it should be easily fixable in distutils).
>>    
>
> What were these problems?
>  

Distutils uses some tests function to see wether a particular set of
float functions is available (FUNCTIONS_TO_CHECK dict in
numpy/core/setup.py), detects a particular set is not available on mingw
(say 'HAVE_INVERSE_HYPERBOLIC'), and define all of them. The problem is
that they are available in the library, just not declared (I remember
because at first, when I built the core with numscons, I only detected
functions by linking to them, and I had discrepancies between numscons
config.h and distutils config.h: that's why I now use both declaration
and presence detection in the m library).

Concretely, some redefinition from static to non static; but that's just
a configuration problem I think.

>  
>>  Thank you for those information, I will dig a bit deeper. Should we
>>  consider this as a major blocker for numpy as well (since it would not
>>  be possible to build a working scipy with numpy 1.1.0 ?) ?
>>    
>
> It depends entirely on what the ultimate solution is.

Yes. I still hope this can be solved using a different build chain than
the 3.4.5 mingw. If not, there is nothing we can do about it. But then,
should we build official binaries with MS compilers ?

cheers,

David
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Distutils: using different linker options for c++ and c code

cdavid
David Cournapeau wrote:

>
> Distutils uses some tests function to see wether a particular set of
> float functions is available (FUNCTIONS_TO_CHECK dict in
> numpy/core/setup.py), detects a particular set is not available on mingw
> (say 'HAVE_INVERSE_HYPERBOLIC'), and define all of them. The problem is
> that they are available in the library, just not declared (I remember
> because at first, when I built the core with numscons, I only detected
> functions by linking to them, and I had discrepancies between numscons
> config.h and distutils config.h: that's why I now use both declaration
> and presence detection in the m library).
>
> Concretely, some redefinition from static to non static; but that's just
> a configuration problem I think.
To be more precise, here is what I get with gcc 4.1.2 on windows (sorry
for the buggy copy-and-paste, but I am surprised I can copy from windows
in linux at all):

gcc -mno-cygwin -O2 -Wall -Wstrict-prototypes
-Ibuild\src.win32-2.5\numpy\core\src -Inumpy\core\include
-Ibuild\src.win32-2.5\numpy\core -Inumpy\core\src -Inumpy\cor
e\include -IC:\Python25\include -IC:\Python25\PC -IC:\Python25\include
-IC:\Python25\PC -c build\src.win32-2.5\numpy\core\src\umathmodule.c -o
build\temp.win32-2.5\R
elease\build\src.win32-2.5\numpy\core\src\umathmodule.o
numpy\core\src\umathmodule.c.src:128: error: static declaration of
'acoshf' follows non-static declaration
numpy\core\src\umathmodule.c.src:136: error: static declaration of
'asinhf' follows non-static declaration
error: Command "gcc -mno-cygwin -O2 -Wall -Wstrict-prototypes
-Ibuild\src.win32-2.5\numpy\core\src -Inumpy\core\include
-Ibuild\src.win32-2.5\numpy\core -Inumpy\core
\src -Inumpy\core\include -IC:\Python25\include -IC:\Python25\PC
-IC:\Python25\include -IC:\Python25\PC -c
build\src.win32-2.5\numpy\core\src\umathmodule.c -o build\
temp.win32-2.5\Release\build\src.win32-2.5\numpy\core\src\umathmodule.o"
failed with exit status 1

cheers,

David
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Distutils: using different linker options for c++ and c code

Robert Kern-2
In reply to this post by cdavid
On Thu, Apr 17, 2008 at 9:36 PM, David Cournapeau
<[hidden email]> wrote:
>  I also found an unofficial installer for gcc 4.*, which at least claim
>  to care about python:
>
>  http://www.develer.com/oss/GccWinBinaries
>
>  The problems with the new official (but beta) 4.* builds is the lack of
>  fortran support. For some reasons, building gfortran on windows does not
>  sound really appealing :)

It seems that Giovanni is getting his gcc from here:

  http://www.tdragon.net/recentgcc/

which also appears to have gfortran binaries, too.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
 -- Umberto Eco
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Distutils: using different linker options for c++ and c code

cdavid
Robert Kern wrote:
>
> It seems that Giovanni is getting his gcc from here:
>
>   http://www.tdragon.net/recentgcc/
>
> which also appears to have gfortran binaries, too.
>
>  

Would that be acceptable to use for numpy/scipy ? I mean, is it enough
if we say to people: you need to install mingw from there instead of the
official ones if you want to build both numpy and scipy ?

cheers,

David
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Distutils: using different linker options for c++ and c code

Robert Kern-2
On Thu, Apr 17, 2008 at 10:56 PM, David Cournapeau
<[hidden email]> wrote:

> Robert Kern wrote:
>  >
>  > It seems that Giovanni is getting his gcc from here:
>  >
>  >   http://www.tdragon.net/recentgcc/
>  >
>  > which also appears to have gfortran binaries, too.
>
>  Would that be acceptable to use for numpy/scipy ? I mean, is it enough
>  if we say to people: you need to install mingw from there instead of the
>  official ones if you want to build both numpy and scipy ?

Well, if the official mingw team is committed to not supporting the
features that we need, then yes, absolutely. This appears to be the
case.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
 -- Umberto Eco
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Distutils: using different linker options for c++ and c code

Charles R Harris
Question. How does numpy link against the python library when there is only a static version present? I compiled/installed python2.6.2a and the only library it generated was /usr/local/lib/python2.6/config/libpython2.6.a. Furthermore, I didn't see the python library specifically linked by any of the numpy code. Compare with the python2.5 build:

$[charris@f8 numpy]$ grep /numpy/fft/fftpack.o log2.6
gcc -pthread -shared -Wall -march=nocona -mtune=generic -O2 -pipe -fomit-frame-pointer -fno-strict-aliasing -finline-functions build/temp.linux-i686-2.6/numpy/fft/fftpack_litemodule.o build/temp.linux-i686-2.6/numpy/fft/fftpack.o -o build/lib.linux-i686-2.6/numpy/fft/fftpack_lite.so

$[charris@f8 numpy]$ grep /numpy/fft/fftpack.o log2.5
gcc -pthread -shared -Wall -march=nocona -mtune=generic -O2 -pipe -fomit-frame-pointer -fno-strict-aliasing -finline-functions build/temp.linux-i686-2.5/numpy/fft/fftpack_litemodule.o build/temp.linux-i686-2.5/numpy/fft/fftpack.o -L/usr/lib -lpython2.5 -o build/lib.linux-i686-2.5/numpy/fft/fftpack_lite.so


I'm trying to track down the failed check_object_casting failure and I am finding some very strange things.

Chuck

_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Distutils: using different linker options for c++ and c code

Robert Kern-2
On Thu, Apr 17, 2008 at 11:33 PM, Charles R Harris
<[hidden email]> wrote:
> Question. How does numpy link against the python library when there is only
> a static version present?

However distutils tells it to. The information is contained in
/usr/local/lib/python2.6/config/Makefile, mostly in the LDFLAGS and
LDSHARED variables.

> I compiled/installed python2.6.2a and the only
> library it generated was /usr/local/lib/python2.6/config/libpython2.6.a.
> Furthermore, I didn't see the python library specifically linked by any of
> the numpy code.

This looks like a problem with your installation of Python.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
 -- Umberto Eco
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Distutils: using different linker options for c++ and c code

cdavid
In reply to this post by Robert Kern-2
Robert Kern wrote:
>
> Well, if the official mingw team is committed to not supporting the
> features that we need, then yes, absolutely. This appears to be the
> case.
>  

Well, this does not seem to work either with gcc 4.3* releases. I got
segfaults too. So should we use VS built instead for numpy and scipy in
the future ?

cheers,

David

_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Distutils: using different linker options for c++ and c code

Robert Kern-2
On Thu, Apr 17, 2008 at 11:49 PM, David Cournapeau
<[hidden email]> wrote:
> Robert Kern wrote:
>  >
>  > Well, if the official mingw team is committed to not supporting the
>  > features that we need, then yes, absolutely. This appears to be the
>  > case.
>
>  Well, this does not seem to work either with gcc 4.3* releases. I got
>  segfaults too. So should we use VS built instead for numpy and scipy in
>  the future ?

Quite possibly. Can you run the segfaulting code in a debugger so we
can try to isolate the actual cause? It is possible that we can patch
it up to work with msvcr71.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
 -- Umberto Eco
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Distutils: using different linker options for c++ and c code

cdavid
Robert Kern wrote:

> On Thu, Apr 17, 2008 at 11:49 PM, David Cournapeau
> <[hidden email]> wrote:
>  
>> Robert Kern wrote:
>>  >
>>  > Well, if the official mingw team is committed to not supporting the
>>  > features that we need, then yes, absolutely. This appears to be the
>>  > case.
>>
>>  Well, this does not seem to work either with gcc 4.3* releases. I got
>>  segfaults too. So should we use VS built instead for numpy and scipy in
>>  the future ?
>>    
>
> Quite possibly. Can you run the segfaulting code in a debugger so we
> can try to isolate the actual cause? It is possible that we can patch
> it up to work with msvcr71.
>  

Ok, I will have to take a look at how to do that, then, I don't really
have experience with debugger, much less on windows. Will get back one I
understand how this works.

David
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Distutils: using different linker options for c++ and c code

cdavid
David Cournapeau wrote:
>
>
> Ok, I will have to take a look at how to do that, then, I don't really
> have experience with debugger, much less on windows. Will get back one I
> understand how this works.
>  

Ok, this is great: when run in gdb, no crash. But when run in cmd.exe,
it always crash. Is there anything else I can do to get the crash under
a debugger ?

David
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Distutils: using different linker options for c++ and c code

Matthieu Brucher-2
In reply to this post by cdavid


2008/4/18, David Cournapeau <[hidden email]>:
Robert Kern wrote:
>
> Well, if the official mingw team is committed to not supporting the
> features that we need, then yes, absolutely. This appears to be the
> case.
>


Well, this does not seem to work either with gcc 4.3* releases. I got
segfaults too. So should we use VS built instead for numpy and scipy in
the future ?

I can help with packaging at least numpy with Visual Studio 2003 (well, I have to check the EULA if I'm allowed to do that !). For scipy, it is a matter of Fortran compiler :|

Matthieu
--
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Distutils: using different linker options for c++ and c code

Robert Kern-2
On Fri, Apr 18, 2008 at 12:57 AM, Matthieu Brucher
<[hidden email]> wrote:
> I can help with packaging at least numpy with Visual Studio 2003 (well, I
> have to check the EULA if I'm allowed to do that !). For scipy, it is a
> matter of Fortran compiler :|

That probably won't work. I believe that the debugging symbol formats
are different between mingw and MSVC.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
 -- Umberto Eco
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Distutils: using different linker options for c++ and c code

Matthieu Brucher-2


2008/4/18, Robert Kern <[hidden email]>:
On Fri, Apr 18, 2008 at 12:57 AM, Matthieu Brucher
<[hidden email]> wrote:
> I can help with packaging at least numpy with Visual Studio 2003 (well, I
> have to check the EULA if I'm allowed to do that !). For scipy, it is a
> matter of Fortran compiler :|


That probably won't work. I believe that the debugging symbol formats
are different between mingw and MSVC.

That was in case we publish binaries made with Visual Studio, as David asked about this matter. The debugging symbols are indeed different, but if it is possible to use Visual Studio, why shouldn't we ? Visual Studio debugger is far better than gdb when debugging optimized code (IMHO).

Matthieu
--
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Distutils: using different linker options for c++ and c code

cdavid
Matthieu Brucher wrote:

>
>
> 2008/4/18, Robert Kern <[hidden email]
> <mailto:[hidden email]>>:
>
>     On Fri, Apr 18, 2008 at 12:57 AM, Matthieu Brucher
>     <[hidden email] <mailto:[hidden email]>>
>     wrote:
>     > I can help with packaging at least numpy with Visual Studio 2003
>     (well, I
>     > have to check the EULA if I'm allowed to do that !). For scipy,
>     it is a
>     > matter of Fortran compiler :|
>
>
>     That probably won't work. I believe that the debugging symbol formats
>     are different between mingw and MSVC.
>
>
> That was in case we publish binaries made with Visual Studio, as David
> asked about this matter. The debugging symbols are indeed different,
> but if it is possible to use Visual Studio, why shouldn't we ?

Well, because it is not available freely and is not open source. I am
really reluctant to do this, personally, but if we don't have a
choice... It will mean that someone will have to do all the work for
windows, though. I personally won't waste any time using visual studio.

cheers,

David
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Distutils: using different linker options for c++ and c code

Robert Kern-2
In reply to this post by Matthieu Brucher-2
On Fri, Apr 18, 2008 at 1:15 AM, Matthieu Brucher
<[hidden email]> wrote:

>
>
> 2008/4/18, Robert Kern <[hidden email]>:
> > On Fri, Apr 18, 2008 at 12:57 AM, Matthieu Brucher
> > <[hidden email]> wrote:
> > > I can help with packaging at least numpy with Visual Studio 2003 (well,
> I
> > > have to check the EULA if I'm allowed to do that !). For scipy, it is a
> > > matter of Fortran compiler :|
> >
> > That probably won't work. I believe that the debugging symbol formats
> > are different between mingw and MSVC.
>
> That was in case we publish binaries made with Visual Studio, as David asked
> about this matter. The debugging symbols are indeed different, but if it is
> possible to use Visual Studio, why shouldn't we ? Visual Studio debugger is
> far better than gdb when debugging optimized code (IMHO).

Sorry, I completely misread what you wrote.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
 -- Umberto Eco
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
12