OpenIPMI 2.0.30 no longer builds with MSYS/MinGW
Brought to you by:
cminyard
Menu
▾
▴
#92 OpenIPMI 2.0.30 no longer builds with MSYS/MinGW
Newly released version 2.0.30 no longer builds under MSYS/MinGW, see the output below.
It looks like there are dllexport/dllimport issues.
This stuff is defined in include/OpenIPMI/dllvisibility.h, but this file, and the symbol IPMI_DLL_PUBLIC which it defines, is shared between 2 different DLLs - libOpenIPMIutils and libOpenIPMI - of which the latter depends on the former.
I believe the solution would be to split IPMI_DLL_PUBLIC into 2 different defines (one for libOpenIPMIutils and one for libOpenIPMI ), which are only set to __attribute__ ((dllexport)) when the relevant shared library is being built.
libtool: link: x86_64-w64-mingw32-gcc -shared .libs/md5.o .libs/md2.o .libs/ipmi_auth.o .libs/ipmi_malloc.o .libs/ilist.o .libs/locks.o .libs/hash.o .libs/locked_list.o .libs/os_handler.o .libs/string.o -lws2_32 -liphlpapi -lgdi32 -g -O2 -o .libs/libOpenIPMIutils-0.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libOpenIPMIutils.dll.a
d:/prog/winlibs64-9.2.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: .libs/ilist.o: in function `add_after':
R:\winlibs64-9.2.0\OpenIPMI-2.0.30\utils/ilist.c:129: undefined reference to `__imp_ilist_mem_alloc'
d:/prog/winlibs64-9.2.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: .libs/ilist.o: in function `add_before':
R:\winlibs64-9.2.0\OpenIPMI-2.0.30\utils/ilist.c:152: undefined reference to `__imp_ilist_mem_alloc'
d:/prog/winlibs64-9.2.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: .libs/ilist.o: in function `alloc_ilist':
R:\winlibs64-9.2.0\OpenIPMI-2.0.30\utils/ilist.c:66: undefined reference to `__imp_ilist_mem_alloc'
d:/prog/winlibs64-9.2.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: R:\winlibs64-9.2.0\OpenIPMI-2.0.30\utils/ilist.c:72: undefined reference to `__imp_ilist_mem_free'
d:/prog/winlibs64-9.2.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: .libs/ilist.o: in function `alloc_ilist_iter':
R:\winlibs64-9.2.0\OpenIPMI-2.0.30\utils/ilist.c:89: undefined reference to `__imp_ilist_mem_alloc'
d:/prog/winlibs64-9.2.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: .libs/ilist.o: in function `free_ilist':
R:\winlibs64-9.2.0\OpenIPMI-2.0.30\utils/ilist.c:103: undefined reference to `__imp_ilist_mem_free'
d:/prog/winlibs64-9.2.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: .libs/ilist.o: in function `free_ilist_iter':
R:\winlibs64-9.2.0\OpenIPMI-2.0.30\utils/ilist.c:117: undefined reference to `__imp_ilist_mem_free'
d:/prog/winlibs64-9.2.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: .libs/ilist.o: in function `ilist_delete':
R:\winlibs64-9.2.0\OpenIPMI-2.0.30\utils/ilist.c:252: undefined reference to `__imp_ilist_mem_free'
d:/prog/winlibs64-9.2.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: .libs/ilist.o: in function `ilist_remove_first':
R:\winlibs64-9.2.0\OpenIPMI-2.0.30\utils/ilist.c:377: undefined reference to `__imp_ilist_mem_free'
d:/prog/winlibs64-9.2.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: .libs/ilist.o: in function `ilist_remove_last':
R:\winlibs64-9.2.0\OpenIPMI-2.0.30\utils/ilist.c:395: undefined reference to `__imp_ilist_mem_free'
d:/prog/winlibs64-9.2.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: .libs/ilist.o:R:\winlibs64-9.2.0\OpenIPMI-2.0.30\utils/ilist.c:416: more undefined references to `__imp_ilist_mem_free' follow
d:/prog/winlibs64-9.2.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: .libs/ilist.o: in function `ilist_add_twoitem':
R:\winlibs64-9.2.0\OpenIPMI-2.0.30\utils/ilist.c:451: undefined reference to `__imp_ilist_mem_alloc'
d:/prog/winlibs64-9.2.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: .libs/ilist.o: in function `ilist_remove_twoitem':
R:\winlibs64-9.2.0\OpenIPMI-2.0.30\utils/ilist.c:472: undefined reference to `__imp_ilist_mem_free'
d:/prog/winlibs64-9.2.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: .libs/ilist.o: in function `ilist_first':
R:\winlibs64-9.2.0\OpenIPMI-2.0.30\utils/ilist.c:200: undefined reference to `__imp_ilist_mem_free'
Related
On Wed, Dec 09, 2020 at 08:17:47AM -0000, Brecht Sanders wrote:
That was quick :-). Thanks for the report.
I don't understand how that would fix it. It's failing when linking the
libOpenIPMIutils shared library, which is before it tries to build
libOpenIPMI, so I don't see how splitting them could be relevant.
But I will admit I don't understand how this works on the Windows side,
I just followed instructions.
Really, ilist_mem_alloc() and ilist_mem_free() should not have public
visibility. Can you verify if removing IPMI_DLL_PUBLIC from those
definitions in include/OpenIPMI/internal/ilist.h solves the problem?
I'm guessing that other problems will show up.
But this is really strange, because I've verified that
OpenIPMI/internal/ilist.h is included in all places that define
and use these functions. My understanding is that should be all that is
required.
Thanks,
-corey
This doesn't fix it:
Note that
make -Cutilsworks fine. The errors start when runningmake -Cliband there's a lot of them (see attachment).When a project generates multiple DLLs you should separate defines per library for the
dllexport/dllimportstuff, as it is possible some functions are exported in one library while other functions are imported from another - as I believe this is the case here.The result is header files will tell functions to be exported from the second library, while in fact they should be imported from the first library, which the second library links with.
Also I noticed
#ifdef BUILDING_DLLininclude/OpenIPMI/dllvisibility.hbut I don't seeBUILDING_DLLactually being defined (e.g. byconfigure).A more appropiate way to do this would be to define either
BUILDING_IPMI_DLLorBUILDING_IPMIUTILS_DLLdepending on which shared library is being built and then defineIPMI_DLL_PUBLICandIPMIUTILS_DLL_PUBLICbased on that (and changeIPMI_DLL_PUBLICtoIPMIUTILS_DLL_PUBLICin theutilssources).On Wed, Dec 09, 2020 at 08:01:11PM -0000, Brecht Sanders wrote:
Yeah, I had kind of figured this out, too. I'll see what I can do.
-corey
Related
Bugs:
#92On Wed, Dec 09, 2020 at 08:01:11PM -0000, Brecht Sanders wrote:
Ok, can you try the attached patch. I think I got everything.
-corey
Not quite there yet...
Now you gave cases where either
IPMI_UTILS_DLL_PUBLICorIPMI_UTILS_DLL_PUBLICare not defined, leading to compilation errors.Also, you seem to make a distinction based on
__GNUC__which I don't think is needed as both MinGW-GCC and MSVC understand__declspec(dllexport)/__declspec(dllimport).See here for a clean example on how I usually do this: https://github.com/brechtsanders/ci-test/blob/master/include/mylibrary.h
On Thu, Dec 10, 2020 at 07:57:40AM -0000, Brecht Sanders wrote:
Doh, that was a dumb mistake.
I am worried about support for older compilers in cygwin, so I'd like to
leave that in.
I have downloaded mingw and set things up. I'm having trouble
compiling, though, I get:
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -Wall -Wsign-compare -I../include -DIPMI_CHECK_LOCKS -DBUILDING_IPMI_UTILS_DLL -g -O2 -MT hash.lo -MD -MP -MF .deps/hash.Tpo -c -o hash.lo hash.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wall -Wsign-compare -I../include -DIPMI_CHECK_LOCKS -DBUILDING_IPMI_UTILS_DLL -g -O2 -MT hash.lo -MD -MP -MF .deps/hash.Tpo -c hash.c -DDLL_EXPORT -DPIC -o .libs/hash.o
In file included from ../include/OpenIPMI/ipmi_types.h:60,
from ../include/OpenIPMI/internal/ipmi_utils.h:27,
from hash.c:51:
../include/OpenIPMI/ipmi_addr.h:60:10: fatal error: netinet/in.h: No such file or directory
60 | #include <netinet in.h="">
| ^~~~~~~~~~~~~~</netinet>
I can't find netinet or socket.h or in.h anywhere in the install. I
can't find a package that would seem to supply those.
Anyway, I have included my hopefully working patch.
-corey
Related
Bugs:
#92It did require some tweaking from my part to get it to build on native Windows with MinGW-w64.
Here are some of those tricks I used:
If the code was on GitHub I could do a pull request of some of the code changes that are needed. I'm not sure how to do that on SourceForge though.
On Thu, Dec 10, 2020 at 05:30:57PM -0000, Brecht Sanders wrote:
I've fixed all those so hacks are no longer necessary, for the most
part. Though I'm not sure where the alloca.h thing is, openipmi doesn't
use that. I've also fixed some more DLL issues that I found.
These are all pushed up to github (I keep a mirror there at
cminyard/openipmi) and I'd be delighted to get pull requests :).
The changes are not pushed to sourceforge yet, because it's giving me
issues with non-fast-forward pushes. I may have to nuke the repository
and start over, or just use the github one.
It's still not compiling for me, though, it can't find inet_ntop,
inet_pton, fcntl, O_NONBLOCK, F_SETFL, or anything about signals.
There are warnings about %lld conversions being invalid in printf,
which is strange.
I'm wondering if I have the right version of MinGW.
-corey
Related
Bugs:
#92Just created pull request https://github.com/cminyard/openipmi/pull/3 with what I believe needs to be fixed.
Well almost.
Still 3 undefined references: ipmi_malloc_shutdown/ipmi_malloc_init/ipmi_malloc_log
On Sat, Dec 12, 2020 at 08:59:19AM -0000, Brecht Sanders wrote:
I'm attaching a diff that maybe fixes the ipmi_malloc_log() thing? If
not, I'll do a 2.1 release and get rid of the reverse reference.
-corey
Related
Bugs:
#92That fix didn't do the trick.
I still get:
Also I still see
#define O_NONBLOCK 1inlib/ipmi_lan.candlib/oem_atca_conn.c. That's not the right way to fix setting sockets to non-blocking on Windows. See my pull request on how to fix that.On Sat, Dec 12, 2020 at 05:23:55PM -0000, Brecht Sanders wrote:
Dant, I didn't push to github. I just did that. I can mess with it
this weekend.
Oops, that got left in from some hacking I was doing. I've pulled it
out.
-corey
Related
Bugs:
#92I see a lot of the stuff from my pull request is still missing when I
make a new fork of the github repository.
Is it possible not everything got merged?
On 12/12/2020 21:28, Corey Minyard wrote:
Related
Bugs:
#92On Sun, Dec 13, 2020 at 02:21:23PM -0000, Brecht Sanders wrote:
I just looked, and it doesn't appear so. I diffed the end if your pull
request with where I pulled in your changes, and the only differences
were some trailing spaces I removed.
I just tried building on MinGW, and it still says inet_ntop isn't
defined, but the code you added to fix it is there. I can't find a
definition of inet_ntop in anywhere in MinGW.
If fails compiling unix/selector.c with a bunch of error.
-corey
Related
Bugs:
#92I looked and for example lib/domain.c didn't have my changes. Maybe I
was looking in the wrong place?
Should I fork it again to be sure?
I'm using the latest MinGW-w64.
If you're using the old MinGW it's possible that inet_ntop/inet_pton is
not there.
Brecht Sanders
Edustria | MailTester.com | WinLibs.com
E-mail: brecht@sanders.org brecht@sanders.org
On 13/12/2020 17:12, Corey Minyard wrote:
Related
Bugs:
#92On Sun, Dec 13, 2020 at 04:50:30PM -0000, Brecht Sanders wrote:
I'm nost sure what is going on. Looking at
https://github.com/cminyard/openipmi/blob/master/lib/domain.c, I see:
include <stdlib.h></stdlib.h>
include <stdint.h></stdint.h>
ifdef MINGW32
undef __USE_MINGW_ANSI_STDIO //fix wrong definition of PRId64 on MinGW
endif
include <inttypes.h></inttypes.h>
and lots of intptr_t.
Where is the newest one? I used mingw-get-setup.exe on
https://osdn.net/projects/mingw/releases/
-corey
Related
Bugs:
#92I use the latest build from http://winlibs.com/ http://winlibs.com/
There is also a MinGW-w64 that you can install via the package manager
of MSYS2 from https://sourceforge.net/projects/msys2/files/Base/
https://sourceforge.net/projects/msys2/files/Base/
I will try to fork again to see if it's okay then.
On 13/12/2020 21:09, Corey Minyard wrote:
Related
Bugs:
#92On Sun, Dec 13, 2020 at 08:25:30PM -0000, Brecht Sanders wrote:
I have this all installed and working. I've updated OpenIPMI so it
compiles properly. It was quite a job, but it's done.
Except that it doesn't work. It's getting a bogus return code from
getaddrinfo() in lib/ipmi_lan.c. The data going in looks correct.
-corey
Related
Bugs:
#92Great work.
Just a tip but
getaddrinfosometimes requires this to work properly:Were there any build warnings?
On Fri, Dec 18, 2020 at 07:59:09PM -0000, Brecht Sanders wrote:
Actually, it appears to be a bug in the MinGW I am using. It doesn't
call the winsock startup function. I add that call and it gets past
that, but then I found that the version I am using is not defining
_WIN32, it's working more like cygwin. And it appears to be buggy in a
few places besides not calling the winsock startup function.
Anyway, all the nasty work of rearranging everything to make it compile
is done.
Yes,
WSAStartup()must be called manually at the beginning of each program when using winsock in MinGW.Looking forward to your next release :-)
Also, to build
make -Cglibsome missing exports need to be fixed:Forgot to mention:
declspec(dllexport)anddeclspec(dllimport)work fine on Cygwin too.I believe this is fixed now with version 2.0.31. If not, please re-open.