Re: [Inkscape-devel] Win32 build trouble
--- spike@...749... wrote:
Wow, it disappeared. I'm on vacation now so I don't have the access necessary to send you any large ZIPs. I think I would try MinGW-4.1.0.exe and mingw32-make-3.80.0-3.exe.
http://prdownloads.sourceforge.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sourceforge.net/mingw/MinGW-4.1.0.exe?download
See if that works.
It compiles! I had some trouble with unknown symbols, so I added a few hacks to placate the linker.
In desktop-affine.cpp: #include <assert.h>
In dir-util.cpp: int errno;
In unclump.o: unsigned long infinity_hack = 0x7F800000; //32-bit IEEE infinity float _imp____infinity = *reinterpret_cast<float*>(&infinity_hack);
The first is arguably a legitimate fix, but the other two horrible hacks for problems I do not fully understand.
I will probably start work on the dialog box issues this afternoon. In particular, the biggest problem is bug [1318726], which I just submitted. (http://sourceforge.net/tracker/index.php?func=detail&aid=1318726&gro...) For some reason, the "Save As" dialog box is an insane size, making it completely unusable. The non-native dialogs are a nusiance in the first place; it would be much better to replace them with the standard dialogs in comctl32.dll anyhow, as per bug [1118565]. (http://sourceforge.net/tracker/?group_id=93438&atid=604306&func=deta...)
Does anyhone object to making the switch?
-s_tec
__________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
On 10/8/05, William Swanson <swansontec@...36...> wrote:
I will probably start work on the dialog box issues this afternoon. In particular, the biggest problem is bug [1318726], which I just submitted. (http://sourceforge.net/tracker/index.php?func=detail&aid=1318726&gro...) For some reason, the "Save As" dialog box is an insane size, making it completely unusable. The non-native dialogs are a nusiance in the first place; it would be much better to replace them with the standard dialogs in comctl32.dll anyhow, as per bug [1118565]. (http://sourceforge.net/tracker/?group_id=93438&atid=604306&func=deta...)
Does anyhone object to making the switch?
Actually we did use Windows file dialogs before, but then switched to the standard cross-platform ones. The main problems with Windows dialogs are:
- We don't have a person who would be dedicated to maintaining that part of the code, fixing bugs etc. Most of us use Linux, and those who use Windows (such as Richard Hughes) are usually busy with other parts of the code.
- Our own dialog has a nice preview pane, which uses the same SVG renderer as Inkscape itself. Windows dialogs do not.
- Our own dialog has a nice bookmarking ability. Windows dialogs do not.
I'm sure there are other issues as well but this is what I can see from my viewpoint.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Oct 8, 2005, at 12:59 PM, William Swanson wrote:
In dir-util.cpp: int errno;
Eeeeeeeeeek!!!
That's quite a scary one to be missing. errno.h usually holds it.
You *really* want the real one, since that holds the error result from system calls.
For Win32 development, you can search MSDN for 'errno'
Did you have to fix it to compile, or to link?
[SNIP]
The first is arguably a legitimate fix, but the other two horrible hacks for problems I do not fully understand.
Hopefully this helps a bit on that second one. I don't really have a good idea on the last one.
--- "Jon A. Cruz" <jon@...18...> wrote:
Did you have to fix it to compile, or to link?
This is to placate the linker. Actually, I am familiar with what errono is and what it does. The thing I baffles me is why the linker can't find it in the standard library to begin with. The fix is really just a band-aid so I can do development; I wouldn't think of sharing these builds with anyone.
-s_tec
__________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/
On Oct 11, 2005, at 12:06 AM, William Swanson wrote:
--- "Jon A. Cruz" <jon@...18...> wrote:
Did you have to fix it to compile, or to link?
This is to placate the linker. Actually, I am familiar with what errono is and what it does. The thing I baffles me is why the linker can't find it in the standard library to begin with. The fix is really just a band-aid so I can do development; I wouldn't think of sharing these builds with anyone.
Off hand, I've seen that sort of thing when there is some c++ mangling or namespacing involved, but it doesn't quite look like it's this case.
It's probably a meaningful red-flag that it's not being found. Running all object files and libs through nm piped through grep might be one thing to do. Looking at the line passed into the linker might be good also.
Le decadi 20 vendémiaire, an CCXIV, William Swanson a écrit :
This is to placate the linker. Actually, I am familiar with what errono is and what it does. The thing I baffles me is why the linker can't find it in the standard library to begin with.
In threaded programs, errno can not be just be a static global variable, since its value must be local to each thread. The standard solution is for errno to be a macro for '*(pointer_to_this_thread_s_errno())'.
I do not know what it is on windows, but on GNU, there has been for some time a hack to ensure that on single-threaded programs, pointer_to_this_thread_s_errno was indeed the address of a global integer symbol. This hack has been dropped some time ago.
On Oct 11, 2005, at 3:36 AM, Nicolas George wrote:
In threaded programs, errno can not be just be a static global variable, since its value must be local to each thread. The standard solution is for errno to be a macro for '*(pointer_to_this_thread_s_errno())'.
Actually, it *can* be.
Note the difference from "should be"
Remember, that on MS Windows, the recommended thing is to use the win32 API and WSAGetLastError.
I do not know what it is on windows, but on GNU, there has been for some time a hack to ensure that on single-threaded programs, pointer_to_this_thread_s_errno was indeed the address of a global integer symbol. This hack has been dropped some time ago.
Good to look into
And remember that the intent is that Inkscape be a single-threaded program.
Jon A. Cruz wrote:
On Oct 11, 2005, at 3:36 AM, Nicolas George wrote:
In threaded programs, errno can not be just be a static global variable, since its value must be local to each thread. The standard solution is for errno to be a macro for '*(pointer_to_this_thread_s_errno())'.
Actually, it *can* be.
Note the difference from "should be"
Remember, that on MS Windows, the recommended thing is to use the win32 API and WSAGetLastError.
I do not know what it is on windows, but on GNU, there has been for some time a hack to ensure that on single-threaded programs, pointer_to_this_thread_s_errno was indeed the address of a global integer symbol. This hack has been dropped some time ago.
Good to look into
And remember that the intent is that Inkscape be a single-threaded program.
This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I have had problems with portability of errno, so I usually avoid it. However, I think what you need for the compile is instead of: int errno; use extern int errno;
Bob
Le decadi 20 vendémiaire, an CCXIV, rjamison a écrit :
I have had problems with portability of errno, so I usually avoid it. However, I think what you need for the compile is instead of: int errno; use extern int errno;
The only correct way to use errno is:
#include <errno.h>
That is so at least since ANSI C.
Declaring errno by hand like you suggest will give programs that do not link against recent glibc, for example.
Quoting William Swanson <swansontec@...36...>:
--- "Jon A. Cruz" <jon@...18...> wrote:
Did you have to fix it to compile, or to link?
This is to placate the linker. Actually, I am familiar with what errono is and what it does. The thing I baffles me is why the
linker
can't find it in the standard library to begin with. The fix is really just a band-aid so I can do development; I wouldn't think of sharing these builds with anyone.
IIRC, I think typically on Windows errno is a macro wrapping a function call.
-mental
participants (6)
-
unknown＠example.com -
bulia byak -
Jon A. Cruz -
Nicolas George -
rjamison -
William Swanson