Bug 3607 - linking with libmsrpc.so fails because it references a static fn from libsmbclient
linking with libmsrpc.so fails because it references a static fn from libsmbc...
Status: RESOLVED LATER
Product: Samba 3.0
Classification: Unclassified
Component: libsmbclient
3.0.21c
All Linux
: P3 normal
: none
Assigned To: Jim McDonough
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-14 20:36 UTC by Jim McDonough
Modified: 2006-04-05 21:35 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jim McDonough 2006-03-14 20:36:41 UTC
If you try to link a program (in this case, the cacusermgr or test suite from 'examples/libmsrpc') with libmsrpc, it will fail with an unknown reference to smbc_attr_server.  that function is static in libsmb/libsmbclient.c.  Derrell, I was hoping you could take a look and verify that it's ok to just remove that "static" from smbc_attr_server().
Comment 1 Derrell Lipman 2006-03-14 20:57:34 UTC
Hmmm...  smbc_attr_server() assumes that libsmbclient is initialized, including having a valid set of callback functions provided by the user, and it's really quite specific to libsmbclient.  In fact, the return value from smbc_attr_server() is a type which is opaque except inside of libsmbclient.  What is libmsrpc.so doing with this function?  Whatever it is, I don't believe it should be doing it.

If you feel that you really want libmsrpc to be making use of this internal function, let me know and I'll see what needs to be done to provide a safe external entry point for it.  I'd like to find out how it's being used first, though.
Comment 2 Jim McDonough 2006-03-15 07:10:14 UTC
I don't actually care...but libmsrpc should link, that's what I'm trying to accomplish here.  Jerry, this is only used for cac_GetServer, which is only called from cac_connect().  seems like this might be doable without it...who wrote this code?

I'll take this one on my list for now.  THanks, Derrell.
Comment 3 Jim McDonough 2006-04-05 21:35:49 UTC
Since nobody seems to be complaining, I'm just going to close this for now.