2011-03-28 09:27:05     comments on recently modified samba makefile...

Document created by Aaronwu Employee on Aug 26, 2013
Version 1Show Document
  • View in full screen mode

2011-03-28 09:27:05     comments on recently modified samba makefile...

Robert Cochran (UNITED STATES)

Message: 99361   

 

The makefile in samba/samba-3.0.25a/source rev 10127 seems to create an unwanted situation where make will fail:

 

Using make menuconfig, select smbmount under network applications->samba.

 

With a newer kernel, smb.h won't be found and configure/make will continue without smbmount regardless of what was set in the make menu.

 

When it comes time to install the smbmount related binaries into romfs, it will fail since they don't exist.

 

Perhaps Kconfig should be modified to get rid of smbmount/unmount and/or modify the makefile to wrap conditional logic around the romfs-inst.sh lines related to smbmount (don't try to copy them if they were left out in configure)?

 

Another comment is that the makefile keys off of the presence of smb.h under the kernel directory.  However, when the code is built, the headers are pulled in from the toolchain.  For me, I had copied over the headers into the trunk toochain from 2010R1, so I ran into the aforementioned situation where make failed even though I had the headers available and smbmount selected in the make menu.

 

Lastly, let me know if these types of comments would have been better suited in a reply email to Mike's original uclinux-dist-commits email for the new makefile.

 

Thanks,

 

Bob

QuoteReplyEditDelete

 

 

2011-03-28 12:35:55     Re: comments on recently modified samba makefile...

Mike Frysinger (UNITED STATES)

Message: 99369   

 

the reason the logic is written this way is that the uclinux-dist guys tend to run configure once, and then let people change kconfig options without needing a reconfigure/rebuild.

 

so ive tweaked the code to disable the config options when the kernel lacks support.

 

as for the kernel vs toolchain checking, that is a fair point, but for a few things:

- we dont really support mixing versions of toolchain/kernel, so none of the releases will have an issue

- checking the toolchain, while possible, is a bit more tricky and i'd have to grub up some code to do so

Attachments

    Outcomes