Bug 10315 - Solaris 10 build issues with 4.1.3
Summary: Solaris 10 build issues with 4.1.3
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Build (show other bugs)
Version: 4.1.3
Hardware: x64 Solaris
: P5 normal (vote)
Target Milestone: ---
Assignee: Björn Jacke
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on: 11073
Blocks:
  Show dependency treegraph
 
Reported: 2013-12-10 18:43 UTC by Marty Lee
Modified: 2015-03-13 08:32 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marty Lee 2013-12-10 18:43:58 UTC
H/W: Intel x86 (64bot)
O/S: Solaris 10, 08/11
Compiler: Sun Studio 12 update 3

When trying to build, I'm getting a linking error:

[3444/3816] Linking default/source4/librpc/libdcerpc-samr.so
cc: standard input (-) valid only for preprocessor

This was seen in bug #9334, but seemed to be marked as 'workedforme' without resolution or root cause.

The issue seems to be in wafsamba/samba_optimisation.py ; where the code

    def run(self):
        if self.env.CC_NAME == "sun" and not self.inputs:
            self.env = self.env.copy()
            self.env.append_value('LINKFLAGS', '-')

appends a '-' to the linker command line, which generates the error. Further up in the file is a comment:

'''work around a problem with cc on solaris not handling module aliases
    which have empty libs'''

The full link command is 

[3430/3816] Linking default/source4/librpc/libdcerpc-atsvc.so
17:05:16 runner /opt/SUNWspro/bin/cc -o /share/sources/solaris/Packages/Samba4/src/samba-4.1.3/bin/default/source4/librpc/libdcerpc-atsvc.so -R/opt/samba4/lib:/opt/samba4/lib/private -lpthread -G -Wl,-h,libdcerpc-atsvc.so.0 -L/usr/lib -R/usr/lib -L/opt/berkeleydb/lib -R/opt/berkeleydb/lib -Ldefault/lib/ccan -Ldefault/lib/ntdb -Ldefault/auth -Ldefault/libcli/ldap -Ldefault/libds/common -Ldefault/lib/tdb -Ldefault/lib/socket -Ldefault/source4/libcli/ldap -Ldefault/lib/krb5_wrap -Ldefault/source4/auth/kerberos -Ldefault/lib/ldb-samba -Ldefault/lib/dbwrap -Ldefault/lib/tdb_wrap -Ldefault/source4/dsdb -Ldefault/lib/ldb -Ldefault/lib/replace -Ldefault/lib -Ldefault/libcli/smb -Ldefault/source4/lib/socket -Ldefault/libcli/cldap -Ldefault/auth/gensec -Ldefault/source4/lib/events -Ldefault/libcli/util -Ldefault/libcli/auth -Ldefault/lib/param -Ldefault/auth/credentials -Ldefault/lib/util -Ldefault/source4/libcli -Ldefault/source4/heimdal_build -Ldefault/libcli/nbt -Ldefault/lib/addns -Ldefault/libcli/security -Ldefault/lib/tevent -Ldefault/lib/talloc -Ldefault/source4/librpc -Ldefault/librpc -L/usr/local/lib -L/opt/python/lib -Bdynamic -ldcerpc-samba -lndr-standard -ldcerpc -ldcerpc-binding -ltalloc -lndr-samba -ltevent -lndr -lsamba-security -lndr-nbt -laddns -lcli-nbt -lroken-samba4 -lsmbclient-raw -ltevent-util -lsamba-credentials -lsamba-hostconfig -lcliauth -lerrors -levents -lgensec -lsamba-util -lcli_cldap -lnetif -lcli_smb_common -lsamba-sockets -lreplace -lndr-krb5pac -lasn1util -lgssapi-samba4 -lldb -lsamdb-common -lcom_err-samba4 -ltdb-wrap -ldbwrap -lutil_tdb -lldbsamba -lauthkrb5 -lkrb5samba -lserver-role -lsamba-modules -lsamdb -lutil_setid -lcli-ldap -linterfaces -lsmb_transport -lkrb5-samba4 -lasn1-samba4 -lhcrypto-samba4 -lwind-samba4 -ltdb -lflag_mapping -lcli-ldap-common -lutil_ntdb -lpyldb-util -lauth_sam_reply -lheimbase-samba4 -lhx509-samba4 -lntdb -lccan -lm -lsocket -lnsl -lrt -ldl -lpython2.7 -lresolv -lmd5 -lz -

which seems to be linking a whole bunch of dynamic libraries, but as the comment suggests, no objects.

If you comment out the self.env.append_value('LINKFLAGS', '-') line, then the
trailing '-' is omitted, and then the linker fails as there are no objects to link!

Looks like this work around doesn't work any more.

If someone can explain what the premise is behind linking lots of dynamic libraries without objects, I can see if I can get it to work. I just don't understand what the build system is trying to achieve here..

marty
Comment 1 Tom Schulz 2014-02-04 20:58:43 UTC
Interesting that gcc is happy to link with no object module specified and sun c is not. I worked around this problem by creating a file named null.c in bin with the contents:

int includethistomakelinkwork()
{
}

I then compiled that with 'cc -c null.c'
I then modified buildtools/wafsamba/samba_optimisation.py and changed

  self.env.append_value('LINKFLAGS', '-')
to
  self.env.append_value('LINKFLAGS', 'null.o')

After rerunning configure, I was able to build Samba 4.1.4.  I have not yet checked to see if the resulting programs work .I also built 4.1.4 with gcc after creating the workaround shown in Bug 10261.  I have not tested that one either. That is for tomorrow.
Comment 2 Tom Schulz 2014-02-07 02:51:04 UTC
The procedure in my previous comment works, but is somewhat of a pain. The configure and build system likes to clean out bin fairly often. Also there is a null.c elsewhere in the source (although there was no conflict). So a slightly different work around for anyone wanting Samba on Solaris before a release is available with a fix  (hopefully sometime soon).

Create a file named nullnull.c in the base directory
with the contents:

int includethistomakelinkwork()
{
}

Then compile that with 'cc -c nullnull.c'
Then modify buildtools/wafsamba/samba_optimisation.py by changing

  self.env.append_value('LINKFLAGS', '-')
to
  self.env.append_value('LINKFLAGS', '../nullnull.o')

After that run 'configure configure' and then make (or 'configure build').
Comment 3 Marty Lee 2014-02-07 15:19:09 UTC
Tom,

I concur with your findings - the nullnull.c file and edit to the buildtools/wafsamba/samba_optimisation.py script do allow 4.1.4 to build under Solaris 10.

I've still got some linking issues to sort out, however these are probably of my own making!

Fingers crossed I can get Samba4 up and running this weekend - or at least, find out where it breaks next.

Thanks for posting the 'patch'; I was off on a tangent trying to fix this another way, with very little success...

Cheers

marty
Comment 4 Stefan Metzmacher 2015-03-13 08:32:19 UTC
Fixed in bug #11073.