root@batfs5998:/clusters/samba# uname -a SunOS batfs5998 5.11 11.2 i86pc i386 i86pc root@batfs5998:/clusters/samba# gmake WAF_MAKE=1 python ./buildtools/bin/waf build Waf: Entering directory `/clusters/samba/bin' Selected embedded Heimdal build [1723/3879] Compiling source3/lib/msghdr.c ../source3/lib/msghdr.c: In function âmsghdr_prep_fdsâ: ../source3/lib/msghdr.c:35:7: error: âstruct msghdrâ has no member named âmsg_controlâ msg->msg_control = NULL; ^ ../source3/lib/msghdr.c:36:7: error: âstruct msghdrâ has no member named âmsg_controllenâ msg->msg_controllen = 0; ^ ../source3/lib/msghdr.c:47:5: error: âstruct msghdrâ has no member named âmsg_controlâ msg->msg_control = buf; ^ ../source3/lib/msghdr.c:48:5: error: âstruct msghdrâ has no member named âmsg_controllenâ msg->msg_controllen = cmsg_space; ^ ../source3/lib/msghdr.c:50:7: warning: assignment makes pointer from integer without a cast [enabled by default] cmsg = CMSG_FIRSTHDR(msg); ^ ../source3/lib/msghdr.c:54:8: warning: assignment makes pointer from integer without a cast [enabled by default] fdptr = CMSG_DATA(cmsg); ^ ../source3/lib/msghdr.c:56:5: error: âstruct msghdrâ has no member named âmsg_controllenâ msg->msg_controllen = cmsg->cmsg_len; ^ ../source3/lib/msghdr.c: In function âmsghdr_prep_recv_fdsâ: ../source3/lib/msghdr.c:139:7: error: âstruct msghdrâ has no member named âmsg_controlâ msg->msg_control = buf; ^ ../source3/lib/msghdr.c:140:7: error: âstruct msghdrâ has no member named âmsg_controllenâ msg->msg_controllen = ret; ^ ../source3/lib/msghdr.c:142:7: error: âstruct msghdrâ has no member named âmsg_controlâ msg->msg_control = NULL; ^ ../source3/lib/msghdr.c:143:7: error: âstruct msghdrâ has no member named âmsg_controllenâ msg->msg_controllen = 0; ^ ../source3/lib/msghdr.c: In function âmsghdr_extract_fdsâ: ../source3/lib/msghdr.c:154:11: warning: assignment makes pointer from integer without a cast [enabled by default] for(cmsg = CMSG_FIRSTHDR(msg); ^ ../source3/lib/msghdr.c:156:11: warning: assignment makes pointer from integer without a cast [enabled by default] cmsg = CMSG_NXTHDR(msg, cmsg)) ^ ../source3/lib/msghdr.c:171:3: warning: passing argument 2 of âmemcpyâ makes pointer from integer without a cast [enabled by default] memcpy(fds, CMSG_DATA(cmsg), num_fds * sizeof(int)); ^ In file included from /usr/include/string.h:11:0, from ../lib/replace/replace.h:163, from ../source3/lib/msghdr.c:19: /usr/include/iso/string_iso.h:54:14: note: expected âconst void *â but argument is of type âintâ extern void *memcpy(void *_RESTRICT_KYWD, const void *_RESTRICT_KYWD, size_t); ^ Waf: Leaving directory `/clusters/samba/bin' Build failed: -> task failed (err #1): {task: cc msghdr.c -> msghdr_98.o} gmake: *** [all] Error 1
Created attachment 10623 [details] lib/msghdr: add defines for Solaris This should fix the issue. It paves over the problem by adding the defines to the source file instead of fixing the waf build, but it seems we can't add the necessary defines for a proper Solaris build from waf as it breaks too much else.
Arggg. But it is unbelievably *ugly* :-). What are the details of what breaks if we fix it in waf ?
*** Bug 11318 has been marked as a duplicate of this bug. ***
I ran into this while trying to build 4.3.0rc4 on a Solaris 10 i386 machine. A relevant part of the output of configure is: Checking if we can use msg_control for passing file descriptors : not found Checking if we can use msg_accrights for passing file descriptors : ok I tried defining _XPG4_2 globally with CFLAGS="-D_XPG4_2" on the configure command line, but then there was a huge number of things that configure could no longer find. So your finding that you can not add the proper defines in waf is probably correct. I hope that you can include some fix for this in the final release of 4.3.0.
Michael, is https://git.samba.org/?p=obnox/samba/samba-obnox.git;a=commitdiff;h=4af0ddc1f1650c the fix for this bug?
I just tried the patch from comment 5 on a Solaris 10 i386 machine and got the following different error output. [1570/3885] Compiling source3/lib/msghdr.c ../source3/lib/msghdr.c: In function 'msghdr_prep_fds': ../source3/lib/msghdr.c:80:5: error: 'struct msghdr' has no member named 'accrights' ../source3/lib/msghdr.c:81:5: error: 'struct msghdr' has no member named 'accrights_len' ../source3/lib/msghdr.c: In function 'msghdr_prep_recv_fds': ../source3/lib/msghdr.c:170:7: error: 'struct msghdr' has no member named 'msg_control' ../source3/lib/msghdr.c:171:7: error: 'struct msghdr' has no member named 'msg_controllen' ../source3/lib/msghdr.c:173:7: error: 'struct msghdr' has no member named 'msg_control' ../source3/lib/msghdr.c:174:7: error: 'struct msghdr' has no member named 'msg_controllen' ../source3/lib/msghdr.c: In function 'msghdr_extract_fds': ../source3/lib/msghdr.c:185:11: warning: assignment makes pointer from integer without a cast [enabled by default] ../source3/lib/msghdr.c:187:11: warning: assignment makes pointer from integer without a cast [enabled by default] ../source3/lib/msghdr.c:202:3: warning: passing argument 2 of 'memcpy' makes pointer from integer without a cast [enabled by default] In file included from /usr/include/string.h:18:0, from ../lib/replace/replace.h:163, from ../source3/lib/msghdr.c:19: /usr/include/iso/string_iso.h:60:14: note: expected 'const void *' but argument is of type 'int' Waf: Leaving directory `/home/projects/tools/samba/samba-4.3.0rc4.i386/bin'
The patch from Comment 1 allows msghdr.c to compile without any complaint. But the build now dies elsewhere, so I can not test the result right now.
I have now managed to build 4.3.0 and a very quick test indicates that it works on Solaris 10 i386. Two questions. Is there any possibility that the structure msghdr could be passed to a function outside of msghdr.c, where it would be defined without all of the members used in msghdr.c? Is there any particular function of Samba that I should exercise to verify that the functions in msghdr.c are working correctly. Hopefully this bug can be fixed in time for 4.3.1.
(In reply to Tom Schulz from comment #8) > Is there any possibility that the structure msghdr could be passed to a > function outside of msghdr.c, where it would be defined without all of the > members used in msghdr.c? Hmm. What do you mean by this? For example in unix_msg.c we use it, using .msg_iov and .msg_iovlen. > Is there any particular function of Samba that I should exercise to verify > that the functions in msghdr.c are working correctly. The smbtorture3 LOCAL-MESSAGING-FDPASS family of tests is designed for this.
(In reply to Volker Lendecke from comment #9) >> Is there any possibility that the structure msghdr could be passed to a >> function outside of msghdr.c, where it would be defined without all of the >> members used in msghdr.c? > > Hmm. What do you mean by this? For example in unix_msg.c we use it, using > .msg_iov and .msg_iovlen. The msghdr structure on Solaris is defined as: /* * Message header for recvmsg and sendmsg calls. */ struct msghdr { void *msg_name; /* optional address */ socklen_t msg_namelen; /* size of address */ struct iovec *msg_iov; /* scatter/gather array */ int msg_iovlen; /* # elements in msg_iov */ #if defined(_XPG4_2) || defined(_KERNEL) void *msg_control; /* ancillary data */ socklen_t msg_controllen; /* ancillary data buffer len */ int msg_flags; /* flags on received message */ #else caddr_t msg_accrights; /* access rights sent/received */ int msg_accrightslen; #endif /* defined(_XPG4_2) || defined(_KERNEL) */ }; And, with the patch, msghdr.c will have both _XPG4_2 and _KERNEL defined but unix_msg.c will not. If the same instance of that structure is passed between routines in msghdr.c and routines in unix_msg.c, the different definitions could cause trouble. But I see that .msg_iov and .msg_iovlen are above that conditional, so both definitions would have them in the same position.
We need the same in socket_wrapper ...
(In reply to Stefan Metzmacher from comment #5) > Michael, is > https://git.samba.org/?p=obnox/samba/samba-obnox.git;a=commitdiff;h=4af0ddc1f1650c > the fix for this bug? Yes, this the _beginning_ of the intended fix - not finished yet.
Created attachment 11457 [details] Patch for referance only This is somewhat of a mess. I have been fiddling around with this so I will report what I have found. The patch from comment 5 and 12 has two typos and misses the use of msg_control and msg_controllen in routine msghdr_prep_recv_fds. The attached patch is a crude attempt to fix that. msghdr.c now compiles but the build fails with the following link error: [3346/3885] Linking default/source3/lib/unix_msg/unix_msg_test Undefined first referenced symbol in file CMSG_LEN default/source3/libmsghdr-samba4.so CMSG_NXTHDR default/source3/libmsghdr-samba4.so CMSG_FIRSTHDR default/source3/libmsghdr-samba4.so CMSG_DATA default/source3/libmsghdr-samba4.so CMSG_SPACE default/source3/libmsghdr-samba4.so The only way to define those macros is to have _XPG4_2 defined when including socket.h. Also there is code that is conditional on having HAVE_STRUCT_MSGHDR_MSG_CONTROL in other source files. In particular, source3/lib/unix_msg/unix_msg.c contains the following: #ifndef HAVE_STRUCT_MSGHDR_MSG_CONTROL if (num_fds > 0) { return ENOSYS; } #endif /* ! HAVE_STRUCT_MSGHDR_MSG_CONTROL */ in two places. And lib/socket_wrapper/socket_wrapper.c has a lot of code conditional on HAVE_STRUCT_MSGHDR_MSG_CONTROL. I have to retract part of what I said on comment 4. I must have mis-typed my additions to CFLAGS. Trying again with '-D_XPG4_2 -D__EXTENSIONS__' does not cause configure to be unable to find a huge number of things. It does cause HAVE_STRUCT_MSGHDR_MSG_CONTROL to be defined and HAVE_STRUCT_MSGHDR_MSG_ACCRIGHTS to be undefined. But the build now fails with: [ 998/3885] Compiling source4/heimdal/lib/hcrypto/libtommath/bn_mp_karatsuba_mul.c ../source4/heimdal/lib/hcrypto/libtommath/bn_mp_karatsuba_mul.c: In function 'mp_karatsuba_mul': ../source4/heimdal/lib/hcrypto/libtommath/bn_mp_karatsuba_mul.c:63:10: error: expected identifier or '*' before numeric constant ../source4/heimdal/lib/hcrypto/libtommath/bn_mp_karatsuba_mul.c:160:4: error: expected ';' before ':' token But if I do not define those when running configure but instead hand edit bin/default/include/config.h after configure has been run to define _XPG4_2, __EXTENSIONS__ and HAVE_STRUCT_MSGHDR_MSG_CONTROL and to undefine HAVE_STRUCT_MSGHDR_MSG_ACCRIGHTS, then Samba builds with no errors. So perhaps a change to the tests in configure to define _XPG4_2 and __EXTENSIONS__ for Solaris as pert of the check for HAVE_STRUCT_MSGHDR_MSG_CONTROL would work.
(In reply to Tom Schulz from comment #13) Yeah, the patch is not finished. It does not compile and it does not work. If I did not make that clear - my apologies! I'd like to finish that soon(ish), so please keep nagging. A working patch is of course also highly welcome. ;-)
(In reply to Michael Adam from comment #14) My comments in comment 13 were not in response to today's comments. I intended to make them a few days ago but work got in the way. For reference, here are the corrected typos. - msg->accrights = buf; - msg->accrights_len = num_fds; + msg->msg_accrights = buf; + msg->msg_accrightslen = num_fds; Some more information on my playing around with defining _XPG4_2 and __EXTENSIONS__. As mentioned above, defining them with CFLAGS on the configure command line does not work but defining them by editing bin/default/include/config.h after running configure does work. Now if I both define them with configure and by editing config.h, I get exactly the same error as with just defining them with configure. If I define them in both places, I have to then edit bin/c4che/default.cache.py and remove them from the saved gcc command line before make will succeed. I really wonder what is going on there, but I suppose that I do not have the ambition to find out. For Michael Adam: nag nag nag nag nag nag nag nag nag nag nag nag nag nag nag nag nag nag nag! :-)
https://lists.samba.org/archive/samba-technical/2015-September/109699.html
Created attachment 11476 [details] Patch for 4.3
Comment on attachment 11476 [details] Patch for 4.3 Verified. Thanks for the backport! We do need the build fixes (including a few more) to build 4.3 on solaris. I'll look for an existing bug and create a new one if I don't find one...
Karo, please pick for 4.3.NEXT. Thanks!
(In reply to Michael Adam from comment #19) Pushed to autobuild-v4-3-test.
(In reply to Karolin Seeger from comment #20) Pushed(In reply to Karolin Seeger from comment #20) Pushed to v4-3-test. Closing out bug report. Thanks!