Unable to build Samba 2.2.8 libsmbclient on HP-UX 11.00
Hello, I am having problems building Samba 2.2.8 on HP-UX 11.00. I am using the ANSI C compiler, /opt/ansic/bin/cc: LINT A.11.01.25171.GP CXREF A.11.01.25171.GP HP92453-01 A.11.01.25171.GP HP C Compiler $ Sep 8 2000 23:13:51 $ My configure line is CC=cc CFLAGS='+DA2.0W' ./configure --with-automount --with-libsmbclient --with-winbind I get the following errors Linking libsmbclient non-shared library bin/libsmbclient.a Linking libsmbclient shared library bin/libsmbclient.sl ld: (Warning) Cannot make undefined symbol "ISSECURE" symbolic. Symbol was refer enced from file /usr/lib/pa20_64/libsec.sl ld: Unsatisfied protected symbol "ISSECURE" in file "libsmb/libsmbclient.po" ld: Unsatisfied protected symbol "ISSECURE" in file "lib/charcnv.po" [deleted lines] ld: Unsatisfied protected symbol "ISSECURE" in file "ubiqx/ubi_sLinkList.po" ld: Unsatisfied protected symbol "ISSECURE" in file "ubiqx/debugparse.po" 1 warnings. 83 errors. make: *** [bin/libsmbclient.sl] Error 1 Any ideas? -- Eric M. Boehm /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML or RTF in mail X No proprietary word-processing Respect Open Standards / \ files in mail
How do I enable groupname map functionality?
I can see code in Samba 2.2.7a in source/smbd/groupname.c to do "groupname map" functionality. I see #ifdef USING_GROUPNAME_MAP but I don't see any option to configure to enable this. Is this feature available or is it still under development. -- Eric M. Boehm /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML or RTF in mail X No proprietary word-processing Respect Open Standards / \ files in mail
Re: PR #s 25271, 25273, 25445 security=domain does not work onSolaris
On Mon, Sep 09, 2002 at 11:36:51AM -0400, David Collier-Brown wrote: > "David" == David Collier-Brown <[EMAIL PROTECTED]> writes: > "Tim" == Tim Allen <[EMAIL PROTECTED]> writes: Tim> I have posted to this group in the past and been told that Tim> the behavior I'm seeing is not correct. My main file server Tim> (Samba/Linux) does not behave this way (similar smb.conf). Tim> And the symptom was: I have posted to the user groups and Tim> think I have found a bug. Our RHL6.2 box running samba 2.0.6 Tim> is a member of our NT domain. An NT user (say jbloggs) cannot Tim> browse the unix/samba box unless there is a corresponding Tim> unix user (jbloggs) on the unix box; this is the expected Tim> (and correct??!) behavior. We have added samba 2.2.2 to one Tim> of our Sun boxes (Solaris 8) and now we appear to have to add Tim> users to the "smbusers" file in addition to (or instead of) Tim> just having a corresponding unix user. I will supply further Tim> information (smb.conf, log files, whatever) as requested. David> You normally need a Unix user, but if you wish to use David> the NT form of encrypted passwords, you also have to have David> an entry for the user in the smbpasswd file. As David> security=domain requires encrypted passwords, I'm afraid David> you're stuck with it! Are you sure about this? I've been running 2.0.7 for a couple of years with security = domain and I don't need to create an smbusers file. The only time I run into problems is if the Windows user does not have a UNIX account. As long as the userid exists in the Windows domain and NIS domain, it works fine (with encrypted passwords). I am also running 2.2.5 with the same configuration. It might be worthwhile to see Tim's smb.conf or a level 3 or level 5 log of a failed access. Here's the relevant portion of mine workgroup = AMERICASE security = domain password server= ZRTPD01T ZRTPD0P0 NRTPDE11 # wins server= 47.156.160.179 encrypt passwords = yes -- Eric M. Boehm /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML or RTF in mail X No proprietary word-processing Respect Open Standards / \ files in mail
Re: How do I compile 64 bit Samba on Solaris 8?
On Tue, Jul 30, 2002 at 03:38:59PM -0700, Dennis, David M. wrote:
> "Dave" == Dennis, David M <[EMAIL PROTECTED]> writes:
Dave> Regarding compiling on solaris: 1) make sure the environment
Dave> variable CC is set to the proper compiler. If gcc then $CC
Dave> needs 'gcc' and if Forte on Sun then $CC=cc .
Dave> 2) ensure the proper paths, the Sun Companion CD puts gcc in
Dave> /opt/sfw/bin/gcc .
Dave> 3) LD_LIBRARY_PATH must include non-standard Solaris libs,
Dave> /usr/local/lib is NOT standard on Solaris.
Might be best to unset LD_LIBRARY_PATH
Dave> 4) If you have Forte your PATH should be something like
Dave> /opt/SUNWspro/bin ahead of everything, and /opt/sfw/bin or
Dave> /usr/local/bin last . LD_LIBRARY_PATH should likewise have
Dave> /opt/SUNWspro/lib ahead of everything else.
Dave> There was also just recently a patch posted for smbwrapper
Dave> for samba, if your compile is failing with that email me and
Dave> I'll send it along.
Dave> Hope that helps, anyone feel free to add corrections to the
Dave> above, I am still learning these myself!
John> I haven't found any docs on how to do this. Can someone
John> point me in the right direction? I've got Forte compiler 6.2
John> and the sun linker and assembler in my path, but not gcc. Is
John> it an option I give to configure? Do I have to use gcc?
I believe I've posted instructions on this several times in the past.
Assuming that you have cc in your PATH and the CC=cc
A. For Bourne/Korn Shells
1. For Sun's Forte compiler
CC=cc CPPFLAGS='-D__EXTENSIONS__' CFLAGS='-xarch=v9a' \
./configure
2. For gcc 3.x or better
CC=gcc CPPFLAGS='-D__EXTENSIONS__' CFLAGS='-m64' \
./configure
B. For Csh and derivatives
1. For Sun's Forte compiler
setenv CC cc \
setenv CPPFLAGS '-D__EXTENSIONS__' \
setenv CFLAGS '-xarch=v9a' \
./configure
2. For gcc 3.x or better
setenv CC gcc\
setenv CPPFLAGS '-D__EXTENSIONS__' \
setenv CFLAGS '-m64' \
./configure
The CPPFLAGS='-D__EXTENSIONS__' is necessary because configure doesn't
(yet) include and crypt gets the wrong prototype in a 64-bit
application, leading to a SIGSEGV in swat
If you experience difficulties linking some shared objects, it's
because the definition of SHLD doesn't include CFLAGS. The workaround
is
make SHLD='${CC} ${CFLAGS}'
when building Samba
You could also use '-xarch=v9' or 'xarch=v9b' for UltraSparc III or
'-xarch=native64' instead of '-xarch=v9a'
--
Eric M. Boehm /"\ ASCII Ribbon Campaign
[EMAIL PROTECTED] \ / No HTML or RTF in mail
X No proprietary word-processing
Respect Open Standards / \ files in mail
Re: compile samba-2.2.4 on Solaris 7
On Mon, Jun 03, 2002 at 03:31:10PM -0500, Gerald Carter wrote: >>>>> "Jerry" == Gerald Carter <[EMAIL PROTECTED]> writes: Eric> On Thu, 30 May 2002, Eric Boehm wrote: I've seen the Eric> following behavior on Solaris 8. Eric> 1. compiling 32-bit with Sun Workshop, configure checks for Eric> and finds readdir64... yes dirent64... yes Eric> 2. compiling 32-bit with Sun Workshop, configure checks for Eric> and finds readdir64... no dirent64... yes Jerry> Do you mean 64-bit here for #2? Yes, I mean 64-bit. cut-and-paste too quickly, sorry. -- Eric M. Boehm /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML or RTF in mail X No proprietary word-processing Respect Open Standards / \ files in mail
Re: compile samba-2.2.4 on Solaris 7
On Thu, May 30, 2002 at 10:55:45PM +1000, Andrew Bartlett wrote:
> "Tian" == Tian-xiong Lu <[EMAIL PROTECTED]> writes:
> "Jerry" == Gerald Carter <[EMAIL PROTECTED]> writes:
> "Andrew" == Andrew Bartlett <[EMAIL PROTECTED]> writes:
Tian> Just tried compling samba-2.2.4 on a Solaris 7 box with two
Tian> configure options: --with-libsmbclient --with-acl-support
Tian> When compiling I got a warning message like this: In
Tian> function "sys_readdir" lib/system.c 331 Warning: return from
Tian> incompatible pointer type.
Jerry> Am looking into it.
Andrew> BTW, this is one of the things currently blocking us from
Andrew> building on the Cray. (Now that just means that we will
Andrew> find the next one, but anyway...)
I've seen the following behavior on Solaris 8.
1. compiling 32-bit with Sun Workshop, configure checks for and finds
readdir64... yes
dirent64... yes
2. compiling 32-bit with Sun Workshop, configure checks for and finds
readdir64... no
dirent64... yes
I believe that this is because the test program for readdir64 is
incorrect.
The normal test program is
#line 5614 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char readdir64(); below. */
#include
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char readdir64();
int main() {
/* The GNU C library defines this for functions which it implements
to always fail with ENOSYS. Some functions are actually named
something starting with __ and the normal name is an alias. */
#if defined (__stub_readdir64) || defined (__stub___readdir64)
choke me
#else
readdir64( );
#endif
; return 0; }
This compiles okay as 32bit because it links with /usr/lib/libc.so.1,
which contains readdir64.
A 64-bit compile links with /usr/lib/sparcv9/libc.so.1 which doesn't
contain readdir64 (since it isn't necessary).
If we change the test program to:
#line 5614 "configure"
#include "confdefs.h"
#include
#include
#include
/*char readdir64();*/
int main() {
#if defined (__stub_readdir64) || defined (__stub___readdir64)
choke me
#else
DIR *dirp;
readdir64( dirp );
#endif
; return 0; }
Then it builds and links okay. If you look at the pre-processed
output, you can see why
A 32-bit build generates
#pragma redefine_extnamereaddir readdir64
extern DIR *opendir(const char *);
extern struct dirent*readdir(DIR *);
extern long telldir(DIR *);
extern void seekdir(DIR *, long);
extern void rewinddir(DIR *);
extern int closedir(DIR *);
extern struct dirent64 *readdir64(DIR *);
int main() {
DIR *dirp;
readdir64( dirp );
; return 0; }
Note the "#pragma redefine_extnamereaddir readdir64"
A 64-bit build generates
#pragma redefine_extnamereaddir64 readdir
extern DIR *opendir(const char *);
extern struct dirent*readdir(DIR *);
extern long telldir(DIR *);
extern void seekdir(DIR *, long);
extern void rewinddir(DIR *);
extern int closedir(DIR *);
extern struct dirent64 *readdir64(DIR *);
int main() {
DIR *dirp;
readdir64( dirp );
; return 0; }
Note that "#pragma redefine_extnamereaddir64 readdir" is
the reverse of the 32-bit build
You would need to change configure.in but configure.in uses
AC_CHECK_FUNC to generate the test program for readdir64. The
generated program doesn't include the right include files or the right
arguments.
The check for dirent64 has a specific program rather than one
generated by AC_CHECK_FUNC.
--
Eric M. Boehm /"\ ASCII Ribbon Campaign
[EMAIL PROTECTED] \ / No HTML or RTF in mail
X No proprietary word-processing
Respect Open Standards / \ files in mail
