MinGW - Minimalist GNU for Windows

Hi all,

Am Freitag, den 26.08.2011, 13:42 +0200 schrieb Fabian Greffrath:
> But I got an idea: What if the "critical" parts of msys-1.0.dll, i.e. 
> the ones that prevent static linking, get replaced by some stubs (like 
> the ones from libgw32c or downhill) depending on whether a dynamic or 
> static library is build.

alright, I admit that the idea to replace fork() with a stub is a stupid
one. But if fork() is really the only implemented function (family) that
prevents static linking, wouldn't it be possible to create a static
library and a set of headers that simply do not provide these functions
anymore? Upstream configure scripts would need to detect this situation
and fall back to calling system() in appropriate situations instead.

 - Fabian

xunxun wrote:
> 于 2011/10/21 2:35, Martin Whitaker 写道:
>> Hi xunxun,
>>
>> I've just upgraded to binutils 2.21.53.20110804 which still has the 
>> same problem. Is there a more recent snapshot than this?
>>
>> Thanks, 
> I don't know whether there is the prebuilt package, but about source 
> code, you can get from ftp://sourceware.org/pub/binutils/snapshots/
> 
> You can build it yourself.
> 
> 

Using --enable-extra-pe-debug ld switch I found the symbol defined as
.weak._myfunc. so I then added --defsym _myfunc=.weak._myfunc. and the
binary was built and executes.  So why the extra "." symbol on the end?
 Whose at fault GCC for the extra "." or binutils for ignoring it?

-- 
Earnie
-- http://www.for-my-kids.com

Hi,

I try to compile pgRouting for PostgreSQL 9.1 on WIndows using MinGW.
PostgreSQL and all pgRouting dependencies (GAUL and CGAL) compiled
successfully.
When I try to build pgRouting itself with CGAL and GAUL support I get next
error

Scanning dependencies of target routing_tsp

[  8%] Building C object extra/tsp/src/CMakeFiles/routing_tsp.dir/tsp.obj

[ 16%] Building CXX object
extra/tsp/src/CMakeFiles/routing_tsp.dir/tsp_solver.obj

In file included from d:/MinGW/msys/1.0/local/include/gaul.h:52:0,

                 from
g:/src/pgRouting-pgrouting-a0c6c18/extra/tsp/src/tsp_solver.cpp:24:

d:/MinGW/msys/1.0/local/include/gaul/log_util.h:75:46: warning:
'dllimport' attribute ignored

In file included from
d:/MinGW/msys/1.0/local/pgsql/include/server/pg_config_os.h:37:0,

                 from d:/MinGW/msys/1.0/local/pgsql/include/server/c.h:90,

                 from
d:/MinGW/msys/1.0/local/pgsql/include/server/postgres.h:47,

                 from
g:/src/pgRouting-pgrouting-a0c6c18/extra/tsp/src/tsp_solver.cpp:25:

d:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/winsock2.h:635:33:
error: declaration of C function 'int gethostname(char*, int)'
conflicts with

d:/MinGW/msys/1.0/local/include/gaul/compatibility.h:189:14: error:
previous declaration 'int gethostname(char*, size_t)' here

make[2]: *** [extra/tsp/src/CMakeFiles/routing_tsp.dir/tsp_solver.obj] Error 1

make[1]: *** [extra/tsp/src/CMakeFiles/routing_tsp.dir/all] Error 2

make: *** [all] Error 2

When I gisable GAUL and leave only CGAL and run clean build another
error appears

Scanning dependencies of target routing_dd

[ 10%] Building C object
extra/driving_distance/src/CMakeFiles/routing_dd.dir/alpha.obj

[ 20%] Building CXX object
extra/driving_distance/src/CMakeFiles/routing_dd.dir/alpha_drivedist.obj

In file included from
d:/MinGW/msys/1.0/local/include/boost/thread/detail/thread_heap_alloc.hpp:15:0,

                 from d:/MinGW/msys/1.0/local/include/boost/thread/tss.hpp:10,

                 from
d:/MinGW/msys/1.0/local/include/CGAL/Modular_arithmetic/Residue_type.h:30,

                 from d:/MinGW/msys/1.0/local/include/CGAL/Residue.h:31,

                 from d:/MinGW/msys/1.0/local/include/CGAL/Modular_traits.h:24,

                 from d:/MinGW/msys/1.0/local/include/CGAL/int.h:29,

                 from
d:/MinGW/msys/1.0/local/include/CGAL/number_type_basic.h:81,

                 from d:/MinGW/msys/1.0/local/include/CGAL/basic.h:35,

                 from
d:/MinGW/msys/1.0/local/include/CGAL/Cartesian/Cartesian_base.h:27,

                 from
d:/MinGW/msys/1.0/local/include/CGAL/Simple_cartesian.h:27,

                 from
g:/src/pgRouting-pgrouting-a0c6c18/extra/driving_distance/src/alpha_drivedist.cpp:34:

d:/MinGW/msys/1.0/local/include/boost/thread/win32/thread_heap_alloc.hpp:59:40:

warning: inline function 'void*
boost::detail::allocate_raw_heap_memory(unsigned int)' declared as
dllimport: attribute ignored

d:/MinGW/msys/1.0/local/include/boost/thread/win32/thread_heap_alloc.hpp:69:39:warning:
inline function 'void boost::detail::free_raw_heap_memory(void*)'
declared as  dllimport: attribute ignored

[ 30%] Building CXX object
extra/driving_distance/src/CMakeFiles/routing_dd.dir/boost_drivedist.obj

In file included from
d:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/windows.h:50:0,

                 from
d:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/winsock2.h:22,

                 from
d:/MinGW/msys/1.0/local/pgsql/include/server/pg_config_os.h:37,

                 from d:/MinGW/msys/1.0/local/pgsql/include/server/c.h:90,

                 from
d:/MinGW/msys/1.0/local/pgsql/include/server/postgres.h:47,

                 from
g:/src/pgRouting-pgrouting-a0c6c18/extra/driving_distance/src/drivedist.h:25,

                 from
g:/src/pgRouting-pgrouting-a0c6c18/extra/driving_distance/src/boost_drivedist.cpp:28:

d:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/winbase.h:1285:59:
error: 'PVECTORED_EXCEPTION_HANDLER' has not been declared

d:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/winbase.h:1815:52:
error: 'HEAP_INFORMATION_CLASS' has not been declared

d:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/winbase.h:1819:50:
error: 'HEAP_INFORMATION_CLASS' has not been declared

make[2]: *** [extra/driving_distance/src/CMakeFiles/routing_dd.dir/boost_drivedist.obj]
Error 1

make[1]: *** [extra/driving_distance/src/CMakeFiles/routing_dd.dir/all] Error 2

make: *** [all] Error 2

Not sure is those errors are MinGW errors or PostgreSQL or another programs.
Can anyone give me any directions?

Thanks
-- 
Alexander Bruy

Alexander Bruy wrote:
> 2011/10/20 Earnie <earnie@...>:
>> You might get by with CPPFLAGS='-Dint64=__int64' or add a ``typedef
>> __int64 int64;'' to one of the config headers.
> 
> Tried with exporting environment variable and with passing as cmake
> command without any success. Here is code snippet from header file
> which reports non working 64-bit integers
> 

Ok, so your configure script didn't detect HAVE_LONG_LONG_INT_64.  So
set CPPFLAGS=-DHAVE_LONG_LONG_INT_64 and you should be good or if you
have config.h then maybe modify it.

-- 
Earnie
-- http://www.for-my-kids.com

[Sent twice, sorry. First mail went to <vim_dev@...>.
  Which is the right address for the vim-dev list, actually?]

Hi all,

Am 02.06.2011 17:07, schrieb Bram Moolenaar:
> Where does Vim crash when homedir is NULL?  That should be fixed.

I have investigated this crash a bit further and tailored it down to a 
completely unrelated issue. It is just that vim takes a different code 
path depending on whether a HOME variable is set and whether it 
succeeds to call a shell (i.e. sh is found in PATH) or not. This led 
me to believe that the missing HOME variable is the culprit, but it isn't.

Remember, my problem was that vim.exe when compiled in an MSYS 
environment crashes when started from a cmd.exe shell when both (a) 
HOME is not set (which is quite common in a cmd.exe shell) and (b) 
sh.exe is found in PATH (it works with zsh-nt, though, but not with 
MSYS's bash).

I can perfectly start vim under the aforementioned conditions if I 
comment out the line calling "fclose(stderr);" in src/os_unix.c around 
line 3994, that's function mch_call_shell() with ((!pipe_error) && 
(pid == 0)). The code block which contains the malicious line is 
introduced with the following paragraph:

>  * Don't want to show any message from the shell.  Can't just
>  * close stdout and stderr though, because some systems will
>  * break if you try to write to them after that, so we must
>  * use dup() to replace them with something else -- webb

And this is exactly what happens, both stdout and stderr are closed 
and the system breaks afterwards. The following calls to dup() aren't 
even reached. How can I circumvent this breakage? It seems that 
cmd.exe needs to have at least one file decriptor open?

  - Fabian

Hi, all. Just for a record.

This reason that gdb crash on WinXP build from gcc 4.6.x can be found here:

http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg02462.html

When building gdb with "-omit-frame-pointer" disabled, gdb works well.

Also, Kai Tietz supplies a patch to solve this problem. (I'm not sure
how the patch works, does it just disable the -omit-frame-pointer on
I386 for mingw?)


asmwarrior
ollydbg from codeblocks' forum