I don't have a Windows box in front of me, indeed haven't seriously touched Windows in quite a while, but this is typically the result of either mismatched types (e.g. you've got a header file or typedef claiming a function's type is something that it really isn't) or incompatible calling conventions between caller and callee. In either case you end up with a number of bytes pushed on the stack at call time, with commensurate adjustment of the stack pointer, and the SP isn't being restored properly afterward.
For historical reasons dating back to the earliest 16-bit versions, Windows is blessed with a number of strange calling conventions that differ in such things as what order the arguments get pushed on the stack and who's responsible for cleaning up and resetting the stack pointer when a function finishes.
Over the years you'd see function prototypes annotated with things like STDCALL, CALLBACK, CDECL, PASCAL, WINAPI, etc. MSDN should document these in detail, and beware there are many synonyms. In the cave times this allowed Windows apps to be slightly smaller by reducing the amount of code that had to be generated at Windows API call sites by entire bytes.
First I'd take a peek into the source for the C client library, and any include files you're pulling in to make use of it and make sure you know what the calling conventions are. If you're defining callbacks in your code that will be invoked by stuff in the library, make sure those functions really have the signatures the caller wants. Also, if you or any code between you and the library have typedef'ed any function pointers for convenience, make sure those types really and truly match those of the functions the DLL is exporting.
Jerry
On Nov 9, 2010, at 8:33 AM, Vincent Cheong wrote:
I have downloaded the rabbit mq c client from http://hg.rabbitmq.com/rabbitmq-c/summary and compiled the the library using mingw successfully.
However when I compile against the library (librabbitmq.dll.a) and run my application, I get a run-time check failure of the value of esp being not properly saved. Any help would be deeply appreciated.
<ATT00001..txt>
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq...@lists.rabbitmq.com
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Are you trying to call the mingw-compiled library from code developed in
Visual Studio? That doesn't work, as explained in the README.windows
file.
But we have addressed this issue in the bug23423 branch. If you switch
to that branch, README.windows contains instructions on how to build the
library with Microsoft's compiler, so that it is callable from code
developed in VS.
That branch still has to go through code review here, but it should work
fine. Let me know if you have any problems with it.
David
--
David Wragg
Staff Engineer, RabbitMQ
SpringSource, a division of VMware
Using Visual Studio install at /C/Program Files/Microsoft Visual Studio 8
Using Windows SDK install at /C/Program Files/Microsoft SDKs/Windows/v6.0A
+ autoreconf -i
C:\MinGW\bin\libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
C:\MinGW\bin\libtoolize: rerunning C:\MinGW\bin\libtoolize, to keep the correct libtool macros in-tree.
C:\MinGW\bin\libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
+ ./configure CC=cl.exe LD=link.exe CFLAGS=-nologo
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for gcc... cl.exe
checking whether the C compiler works... yes
checking for C compiler default output file name... conftest.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... obj
checking whether we are using the GNU C compiler... no
checking whether cl.exe accepts -g... yes
checking for cl.exe option to accept ISO C89... none needed
checking dependency style of cl.exe... none
checking how to run the C preprocessor... cl.exe -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... no
checking for inttypes.h... no
checking for stdint.h... no
checking for unistd.h... no
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for gcc... (cached) cl.exe
checking whether we are using the GNU C compiler... (cached) no
checking whether cl.exe accepts -g... (cached) yes
checking for cl.exe option to accept ISO C89... (cached) none needed
checking dependency style of cl.exe... (cached) none
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking for as... as
checking for dlltool... dlltool
checking for objdump... objdump
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for fgrep... /bin/grep -F
checking for non-GNU ld... link.exe
checking if the linker (link.exe) is GNU ld... no
checking for BSD- or MS-compatible name lister (nm)... /bin/nm -B
checking the name lister (/bin/nm -B) interface... BSD nm
checking whether ln -s works... no, using cp -p
checking the maximum length of command line arguments... 8192
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert i686-pc-mingw32 file names to i686-pc-mingw32 format... func_convert_file_msys_to_w32
checking for link.exe option to reload object files... -r
checking for objdump... (cached) objdump
checking how to recognize dependent libraries... file_magic ^x86 archive import|^x86 DLL
checking for dlltool... (cached) dlltool
checking how to associate runtime and link libraries... func_cygming_dll_for_implib
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /bin/nm -B output from cl.exe object... ok
checking for sysroot... no
checking for mt... mt
checking if mt is a manifest tool... yes
checking for dlfcn.h... no
checking for objdir... .libs
checking for cl.exe option to produce PIC... -DDLL_EXPORT -DPIC
checking if cl.exe PIC flag -DDLL_EXPORT -DPIC works... yes
checking if cl.exe static flag works... yes
checking if cl.exe supports -c -o file.obj... no
checking if cl.exe supports -c -o file.obj... (cached) no
checking if we can lock with hard links... yes
checking whether the cl.exe linker (link.exe) supports shared libraries... yes
checking dynamic linker characteristics... Win32 link.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for ANSI C header files... (cached) yes
checking for inline... __inline
checking location of AMQP codegen directory... /home/vincentcheong/rabbit/windows_rabbitmq-c/../rabbitmq-codegen
checking finding a python with simplejson installed... python
checking for poptGetContext in -lpopt... no
checking for xmlto... no
configure: creating ./config.status
config.status: creating Makefile
config.status: creating librabbitmq/Makefile
config.status: creating tests/Makefile
config.status: creating examples/Makefile
config.status: creating tools/Makefile
config.status: creating tools/doc/Makefile
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
config.status: executing libtool commands
+ sed -i -e 's/^fix_srcfile_path=.*$/fix_srcfile_path=""/;s/^deplibs_check_method=.*$/deplibs_check_method=pass_all/;/^archive_cmds=/s/-link -dll/& -implib:\\$libname.\\$libext/' libtool
+ make
make all-recursive
make[1]: Entering directory `/home/vincentcheong/rabbit/windows_rabbitmq-c'
Making all in librabbitmq
make[2]: Entering directory `/home/vincentcheong/rabbit/windows_rabbitmq-c/librabbitmq'
make all-am
make[3]: Entering directory `/home/vincentcheong/rabbit/windows_rabbitmq-c/librabbitmq'
/bin/sh ../libtool --tag=CC --mode=link cl.exe -I./windows -DBUILDING_LIBRABBITMQ -I../msinttypes -nologo -no-undefined -o librabbitmq.la -rpath /usr/local/lib amqp_mem.lo amqp_table.lo amqp_connection.lo amqp_socket.lo amqp_api.lo socket.lo amqp_framing.lo ws2_32.lib
*** Warning: Linking the shared library librabbitmq.la against the
*** static library ws2_32.lib is not portable!
libtool: link: rm -fr .libs/rabbitmq.exp
libtool: link: /bin/nm -B .libs/amqp_mem.obj .libs/amqp_table.obj .libs/amqp_connection.obj .libs/amqp_socket.obj .libs/amqp_api.obj .libs/socket.obj .libs/amqp_framing.obj | sed -n -e 's/^.*[ ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][ ]*_\([_A-Za-z][_A-Za-z0-9]*\)\{0,1\}$/\1 _\2 \2/p' | /bin/sed -e '/^[BCDGRS][ ]/s/.*[ ]\([^ ]*\)/\1,DATA/' | /bin/sed -e '/^[AITW][ ]/s/.*[ ]//' | sort | uniq > .libs/rabbitmq.exp
libtool: link: if test "x`/bin/sed 1q .libs/rabbitmq.exp`" = xEXPORTS; then sed -n -e s/\\\(.*\\\)/-link\ -EXPORT:\\\1/ -e 1\!p < .libs/rabbitmq.exp > .libs/rabbitmq-0.dll.exp; else sed -e s/\\\(.*\\\)/-link\ -EXPORT:\\\1/ < .libs/rabbitmq.exp > .libs/rabbitmq-0.dll.exp; fi
libtool: link: cl.exe -o .libs/rabbitmq-0.dll .libs/amqp_mem.obj .libs/amqp_table.obj .libs/amqp_connection.obj .libs/amqp_socket.obj .libs/amqp_api.obj .libs/socket.obj .libs/amqp_framing.obj ws2_32.lib @.libs/rabbitmq-0.dll.exp -Wl,-DLL
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
cl : Command line warning D9035 : option 'o' has been deprecated and will be removed in a future release
cl -link -EXPORT:amqp_abort
-link -EXPORT:amqp_basic_ack
-link -EXPORT:amqp_basic_consume
-link -EXPORT:amqp_basic_get
-link -EXPORT:amqp_basic_publish
-link -EXPORT:amqp_bytes_free
-link -EXPORT:amqp_bytes_malloc
-link -EXPORT:amqp_bytes_malloc_dup
-link -EXPORT:amqp_channel_close
-link -EXPORT:amqp_channel_open
-link -EXPORT:amqp_connection_close
-link -EXPORT:amqp_constant_is_hard_error
-link -EXPORT:amqp_constant_name
-link -EXPORT:amqp_cstring_bytes
-link -EXPORT:amqp_data_in_buffer
-link -EXPORT:amqp_decode_method
-link -EXPORT:amqp_decode_properties
-link -EXPORT:amqp_decode_table
-link -EXPORT:amqp_destroy_connection
-link -EXPORT:amqp_empty_array,DATA
-link -EXPORT:amqp_empty_bytes,DATA
-link -EXPORT:amqp_empty_table,DATA
-link -EXPORT:amqp_encode_method
-link -EXPORT:amqp_encode_properties
-link -EXPORT:amqp_encode_table
-link -EXPORT:amqp_error_string
-link -EXPORT:amqp_exchange_declare
-link -EXPORT:amqp_frames_enqueued
-link -EXPORT:amqp_get_channel_max
-link -EXPORT:amqp_get_rpc_reply
-link -EXPORT:amqp_get_sockfd
-link -EXPORT:amqp_handle_input
-link -EXPORT:amqp_login
-link -EXPORT:amqp_maybe_release_buffers
-link -EXPORT:amqp_method_has_content
-link -EXPORT:amqp_method_name
-link -EXPORT:amqp_new_connection
-link -EXPORT:amqp_open_socket
-link -EXPORT:amqp_os_error_string
-link -EXPORT:amqp_pool_alloc
-link -EXPORT:amqp_pool_alloc_bytes
-link -EXPORT:amqp_queue_bind
-link -EXPORT:amqp_queue_declare
-link -EXPORT:amqp_queue_delete
-link -EXPORT:amqp_queue_purge
-link -EXPORT:amqp_queue_unbind
-link -EXPORT:amqp_release_buffers
-link -EXPORT:amqp_release_buffers_ok
-link -EXPORT:amqp_send_frame
-link -EXPORT:amqp_send_header
-link -EXPORT:amqp_send_method
-link -EXPORT:amqp_set_sockfd
-link -EXPORT:amqp_simple_rpc
-link -EXPORT:amqp_simple_wait_frame
-link -EXPORT:amqp_simple_wait_method
-link -EXPORT:amqp_socket_init
-link -EXPORT:amqp_table_entry_cmp
-link -EXPORT:amqp_tune_connection
-link -EXPORT:amqp_tx_commit
-link -EXPORT:amqp_tx_rollback
-link -EXPORT:amqp_tx_select
-link -EXPORT:amqp_version
-link -EXPORT:empty_amqp_pool
-link -EXPORT:init_amqp_pool
-link -EXPORT:recycle_amqp_pool
cl : Command line error D8021 : invalid numeric argument '/Wl,-DLL'
make[3]: *** [librabbitmq.la] Error 2
make[3]: Leaving directory `/home/vincentcheong/rabbit/windows_rabbitmq-c/librabbitmq'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/vincentcheong/rabbit/windows_rabbitmq-c/librabbitmq'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/vincentcheong/rabbit/windows_rabbitmq-c'
make: *** [all] Error 2
> [...]
From the output, I see that nothing is actually getting compiled, but
only linked. I'm not sure that this is related to the error, but it
makes me think that you have some files present from an earlier build,
and that might be affecting things. Could you try deleting (or moving)
your rabbitmq-c directory, and starting from a fresh 'hg clone' of the
rabbitmq-c repository, and let me know what happens?
Thanks,
David
--
David Wragg
Staff Engineer, RabbitMQ
SpringSource, a division of VMware
Vincent Cheong <vincent...@gmail.com> writes:
> I believe the individual .c files were compiled. The respective obj file
> were found in librabbitmq/.libs.
Yes, but the compiler commands that produced those obj files were not
present in the build output you sent. I'd like to see the output you
get when building from an absolutely clean state, to help me understand
the cause of the error.
> However, I did not get the source files via
> a 'hg clone' but downloaded them from
> http://hg.rabbitmq.com/rabbitmq-c/file/f09918f7aa73.
Downloading that revision via one of the archive links (such as the
'zip' link) is fine too. But make sure you delete your existing
rabbitmq-c directory first - don't just unpack over it - so that you
build from a clean state.
> I have multiple
> versions of visual studio installed on my machine but i'm forcing it to use
> my visual studio 2005 compiler. I did so by removing the 10.0 and 9.0 for
> the vsvers and v7.0A and v6.0A from the build-ms.sh file. Is this the
> correct way to it or have I introduced an error by doing so?
This should be fine. I expect that if you do not make this change, and
so build with the compiler from VS 10.0, you will get the same error.
David
--
David Wragg
Staff Engineer, RabbitMQ
SpringSource, a division of VMware
config.status: executing depfiles commands
config.status: executing libtool commands
+ sed -i -e 's/^fix_srcfile_path=.*$/fix_srcfile_path=""/;s/^deplibs_check_metho
d=.*$/deplibs_check_method=pass_all/;/^archive_cmds=/s/-link -dll/& -implib:\\$l
ibname.\\$libext/' libtool
+ make
make all-recursive
make[1]: Entering directory `/home/vincentcheong/rabbit/windows_rabbitmq-c'
Making all in librabbitmq
make[2]: Entering directory `/home/vincentcheong/rabbit/windows_rabbitmq-c/libra
bbitmq'
PYTHONPATH=/home/vincentcheong/rabbit/windows_rabbitmq-c/../rabbitmq-codegen pyt
hon ./codegen.py header /home/vincentcheong/rabbit/windows_rabbitmq-c/../rabbitm
q-codegen/amqp-rabbitmq-0.9.1.json amqp_framing.h
PYTHONPATH=/home/vincentcheong/rabbit/windows_rabbitmq-c/../rabbitmq-codegen pyt
hon ./codegen.py body /home/vincentcheong/rabbit/windows_rabbitmq-c/../rabbitmq-
codegen/amqp-rabbitmq-0.9.1.json amqp_framing.c
make all-am
make[3]: Entering directory `/home/vincentcheong/rabbit/windows_rabbitmq-c/libra
bbitmq'
source='amqp_mem.c' object='amqp_mem.lo' libtool=yes \
DEPDIR=.deps depmode=none /bin/sh ../depcomp \
/bin/sh ../libtool --tag=CC --mode=compile cl.exe -DHAVE_CONFIG_H -I.
-I.. -I./windows -DBUILDING_LIBRABBITMQ -I../msinttypes -nologo -c -o amqp_m
em.lo amqp_mem.c
libtool: compile: cl.exe -DHAVE_CONFIG_H -I. -I.. -I./windows -DBUILDING_LIBRAB
BITMQ -I../msinttypes -nologo -c amqp_mem.c -DDLL_EXPORT -DPIC
amqp_mem.c
libtool: compile: mv -f "amqp_mem.obj" ".libs/amqp_mem.obj"
libtool: compile: cl.exe -DHAVE_CONFIG_H -I. -I.. -I./windows -DBUILDING_LIBRAB
BITMQ -I../msinttypes -nologo -c amqp_mem.c >/dev/null 2>&1
source='amqp_table.c' object='amqp_table.lo' libtool=yes \
DEPDIR=.deps depmode=none /bin/sh ../depcomp \
/bin/sh ../libtool --tag=CC --mode=compile cl.exe -DHAVE_CONFIG_H -I.
-I.. -I./windows -DBUILDING_LIBRABBITMQ -I../msinttypes -nologo -c -o amqp_t
able.lo amqp_table.c
libtool: compile: cl.exe -DHAVE_CONFIG_H -I. -I.. -I./windows -DBUILDING_LIBRAB
BITMQ -I../msinttypes -nologo -c amqp_table.c -DDLL_EXPORT -DPIC
amqp_table.c
libtool: compile: mv -f "amqp_table.obj" ".libs/amqp_table.obj"
libtool: compile: cl.exe -DHAVE_CONFIG_H -I. -I.. -I./windows -DBUILDING_LIBRAB
BITMQ -I../msinttypes -nologo -c amqp_table.c >/dev/null 2>&1
source='amqp_connection.c' object='amqp_connection.lo' libtool=yes \
DEPDIR=.deps depmode=none /bin/sh ../depcomp \
/bin/sh ../libtool --tag=CC --mode=compile cl.exe -DHAVE_CONFIG_H -I.
-I.. -I./windows -DBUILDING_LIBRABBITMQ -I../msinttypes -nologo -c -o amqp_c
onnection.lo amqp_connection.c
libtool: compile: cl.exe -DHAVE_CONFIG_H -I. -I.. -I./windows -DBUILDING_LIBRAB
BITMQ -I../msinttypes -nologo -c amqp_connection.c -DDLL_EXPORT -DPIC
amqp_connection.c
libtool: compile: mv -f "amqp_connection.obj" ".libs/amqp_connection.obj"
libtool: compile: cl.exe -DHAVE_CONFIG_H -I. -I.. -I./windows -DBUILDING_LIBRAB
BITMQ -I../msinttypes -nologo -c amqp_connection.c >/dev/null 2>&1
source='amqp_socket.c' object='amqp_socket.lo' libtool=yes \
DEPDIR=.deps depmode=none /bin/sh ../depcomp \
/bin/sh ../libtool --tag=CC --mode=compile cl.exe -DHAVE_CONFIG_H -I.
-I.. -I./windows -DBUILDING_LIBRABBITMQ -I../msinttypes -nologo -c -o amqp_s
ocket.lo amqp_socket.c
libtool: compile: cl.exe -DHAVE_CONFIG_H -I. -I.. -I./windows -DBUILDING_LIBRAB
BITMQ -I../msinttypes -nologo -c amqp_socket.c -DDLL_EXPORT -DPIC
amqp_socket.c
libtool: compile: mv -f "amqp_socket.obj" ".libs/amqp_socket.obj"
libtool: compile: cl.exe -DHAVE_CONFIG_H -I. -I.. -I./windows -DBUILDING_LIBRAB
BITMQ -I../msinttypes -nologo -c amqp_socket.c >/dev/null 2>&1
source='amqp_api.c' object='amqp_api.lo' libtool=yes \
DEPDIR=.deps depmode=none /bin/sh ../depcomp \
/bin/sh ../libtool --tag=CC --mode=compile cl.exe -DHAVE_CONFIG_H -I.
-I.. -I./windows -DBUILDING_LIBRABBITMQ -I../msinttypes -nologo -c -o amqp_a
pi.lo amqp_api.c
libtool: compile: cl.exe -DHAVE_CONFIG_H -I. -I.. -I./windows -DBUILDING_LIBRAB
BITMQ -I../msinttypes -nologo -c amqp_api.c -DDLL_EXPORT -DPIC
amqp_api.c
libtool: compile: mv -f "amqp_api.obj" ".libs/amqp_api.obj"
libtool: compile: cl.exe -DHAVE_CONFIG_H -I. -I.. -I./windows -DBUILDING_LIBRAB
BITMQ -I../msinttypes -nologo -c amqp_api.c >/dev/null 2>&1
source='windows/socket.c' object='socket.lo' libtool=yes \
DEPDIR=.deps depmode=none /bin/sh ../depcomp \
/bin/sh ../libtool --tag=CC --mode=compile cl.exe -DHAVE_CONFIG_H -I.
-I.. -I./windows -DBUILDING_LIBRABBITMQ -I../msinttypes -nologo -c -o socke
t.lo `test -f 'windows/socket.c' || echo './'`windows/socket.c
libtool: compile: cl.exe -DHAVE_CONFIG_H -I. -I.. -I./windows -DBUILDING_LIBRAB
BITMQ -I../msinttypes -nologo -c windows/socket.c -DDLL_EXPORT -DPIC
socket.c
libtool: compile: mv -f "socket.obj" ".libs/socket.obj"
libtool: compile: cl.exe -DHAVE_CONFIG_H -I. -I.. -I./windows -DBUILDING_LIBRAB
BITMQ -I../msinttypes -nologo -c windows/socket.c >/dev/null 2>&1
source='amqp_framing.c' object='amqp_framing.lo' libtool=yes \
DEPDIR=.deps depmode=none /bin/sh ../depcomp \
/bin/sh ../libtool --tag=CC --mode=compile cl.exe -DHAVE_CONFIG_H -I.
-I.. -I./windows -DBUILDING_LIBRABBITMQ -I../msinttypes -nologo -c -o amqp_f
raming.lo amqp_framing.c
libtool: compile: cl.exe -DHAVE_CONFIG_H -I. -I.. -I./windows -DBUILDING_LIBRAB
BITMQ -I../msinttypes -nologo -c amqp_framing.c -DDLL_EXPORT -DPIC
amqp_framing.c
libtool: compile: mv -f "amqp_framing.obj" ".libs/amqp_framing.obj"
libtool: compile: cl.exe -DHAVE_CONFIG_H -I. -I.. -I./windows -DBUILDING_LIBRAB
BITMQ -I../msinttypes -nologo -c amqp_framing.c >/dev/null 2>&1
/bin/sh ../libtool --tag=CC --mode=link cl.exe -I./windows -DBUILDING_LIBRABBI
TMQ -I../msinttypes -nologo -no-undefined -o librabbitmq.la -rpath /usr/local/
lib amqp_mem.lo amqp_table.lo amqp_connection.lo amqp_socket.lo amqp_api.lo sock
et.lo amqp_framing.lo ws2_32.lib
*** Warning: Linking the shared library librabbitmq.la against the
*** static library ws2_32.lib is not portable!
libtool: link: /bin/nm -B .libs/amqp_mem.obj .libs/amqp_table.obj .libs/amqp_co
nnection.obj .libs/amqp_socket.obj .libs/amqp_api.obj .libs/socket.obj .libs/amq
cl : Command line error D8021 : invalid numeric argument '/Wl,-DLL'
make[3]: *** [librabbitmq.la] Error 2
make[3]: Leaving directory `/home/vincentcheong/rabbit/windows_rabbitmq-c/librab
bitmq'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/vincentcheong/rabbit/windows_rabbitmq-c/librab
bitmq'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/vincentcheong/rabbit/windows_rabbitmq-c'
make: *** [all] Error 2
Thanks.
The output suggest that you have a different version of libtool from the
one installed by the rabbitmq-c/etc/install-mingw.sh script. Did you
use that script to install mingw, or did you do it some other way? It's
quite possible that the Windows build depends upon the specific versions
of packages installed by that script - I haven't tested it with anything
else.
If you did use that script, is it possible that you have another version
of mingw or cygwin installed, and present in your PATH? If so, please
set PATH before you start bash, so that only the version of mingw
installed by the script is mentioned.
Finally, if none of the above seems to apply, please do the following
two commands at the bash prompt, and send the output:
which libtool
libtool --version
David
--
David Wragg
Staff Engineer, RabbitMQ
SpringSource, a division of VMware
Ah, I see. I'm afraid that the easiest way forward for you will be to
do a second temporary install of mingw using the script - you can delete
it as soon as the build has worked :-)
> [...]
>
> I've been looking at error statement again.
> cl : Command line error D8021 : invalid numeric argument '/Wl,-DLL'
> the cl command seems to be expecting a numeral after /W. Could the cl option
> be /W1 or /WL instead or /Wl?
-Wl,-DLL is a gcc option, and cl.exe generally has a completely
different option syntax. Why libtool is passing that option to cl.exe,
I don't know. libtool's support for the MS toolchain seems to be quite
weak, and I was only able to get 2.2.7a to work by patching its output.
I wouldn't be surprised if later versions break that support completely.
So at the moment, you really need 2.2.7a.
I don't know if there will be such strict dependencies on the other
required mingw/msys packages. You might be able to make it work just by
changing your version of libtool, but I'm not sure.
Thanks for bringing this to my attention, I will clarify the build
instructions.
David
--
David Wragg
Staff Engineer, RabbitMQ
SpringSource, a division of VMware
Thanks Vincent - I have corrected this in the branch.
--
David Wragg
Staff Engineer, RabbitMQ
SpringSource, a division of VMware