[opencode]

I'm working on updating the samba version in tools/depends/target/samba-gplv3/Makefile (per this samba 4 thread), but I haven't done this before. I can't figure out how to get this directory to compile. I did a make from git root before changing the version, and when I try make again, it doesn't detect any changes.

Does default make even build the samba library from source? I'm guessing not and that I'd need to use something like tools/buildsteps/linux64 instead, but I can't figure out the right command to run. Any pointers on what I should be doing to compile and test this change?

Thanks,

David

[Montellese]

You need to go into tools/depends and execute bootstrap and then configure (look at the README for additional information) and then you can execute make.

[opencode]

Thanks. I gave that a shot, but I must be missing something. I couldn't find bootstrap or configure scripts in tools/buildsteps. If I try running the xbmc root scripts while in that directory, that doesn't seem to do the trick either. Any thoughts on what I might be missing here?

Thanks,

David

[Montellese]

What version of Kodi are you trying to compile? See https://github.com/xbmc/xbmc/tree/master/tools/depends and more specifically https://github.com/xbmc/xbmc/blob/master.../bootstrap so there certainly is a bootstrap script which in turn will generate the configure script.

EDIT: My bad. It's tools/depends and not tools/buildsteps.

[Memphiz]

once you have built depends a rebuilt of one library can be triggered via

Code:

make -C tools/depends/target/samba-gplv3 distclean
make -C tools/depends/target/samba-gplv3

[opencode]

Ah, thanks that was it.

Once I have /tools/depends compiling with samba 4, is there anything else I should check before submitting a PR? I figured I'd try using samba v4 functionality in Kodi on my Ubuntu box, but I'm not sure if there's anything else that should be verified for other distributions esp. darwin or Android. (I don't have devices for either of those environments personally.)

David

[Memphiz]

once you have a working solution you are fine with you can do a pull request and we can build it for all platforms on jenkins. But its not only having samba4 compiled - you need to alter the core samba support in xbmc/filesystems/SmbFile.cpp/.h and SmbDirectory.cpp/.h to support samba4 aswell i guess.

[wsnipex]

once you have a working solution you are fine with you can do a pull request and we can build it for all platforms on jenkins. But its not only having samba4 compiled - you need to alter the core samba support in xbmc/filesystems/SmbFile.cpp/.h and SmbDirectory.cpp/.h to support samba4 aswell i guess.

linux already uses samba4 for a while now, so it should just work. But we could use SMB2/3 now, which might need core changes(didn't check)

[Memphiz]

Ahh ok - i forgot about that - i am sure you already stated this at some point . So yeah - get it to compile and do a PR and then we check the other platforms via jenkins...

Also as you are working on ubuntu it would be great if you could handle the android path aswell before submitting the PR. Its very likely that you need heavy patching for android. I doubt that our single one android dev has enough time to figure those out. (you can compile kodi for android by following the docs/README.android file).

[opencode]

I'm making progress but currently stumped getting past the configure step for verifying Python development headers/libraries (samba 4 uses WAF, which is python-based, for its build system). It looks like it's able to find the definitions in the header files OK, but stuck in the linker step.

Below, source is equivalent to /xbmc with Kodi's configured depends PREFIX equivalent to /xbmc-depends. (Paths shortened for readability.)

Code:

/xbmc-depends/x86_64-linux-gnu-native/lib/libpython2.6.a(complexobject.o): In function `_Py_c_abs':
/xbmc/tools/depends/native/python26-native/x86_64-linux-native/Objects/complexobject.c:214: undefined reference to `hypot'
collect2: error: ld returned 1 exit status
['/usr/bin/gcc', 'default/test_1.o', '-o', '/xbmc/tools/depends/target/samba-gplv3/x86_64-linux-gnu/bin/.conf_check_0/testbuild/default/testprog', '-L/xbmc-depends/x86_64-linux-gnu-native/lib', '-Wl,-Bdynamic', '-lm', '-lpthread', '-ldl', '-lutil', '-lpython2.6']
command returned 'Build failed:  -> task failed (err #1): \n\t{task: cc_link test_1.o -> testprog}'Could not find the python development headers

Searching around on this problem, the general advice is to install a package like python2.7-dev. I think something's going wrong with either getting the necessary python dev library into the right place in xbmc-depends, or somehow the right location isn't getting passed through to samba's configure script. I checked /xbmc-depends/x86_64-linux-gnu-native/lib/python2.6, and it looks in general like the right things are there, but I'm not positive.

Any thoughts on what the equivalent of something like "apt-get install python2.7-dev" would be for setting up the xbmc-depends/PREFIX location appropriately?

Thanks,

David

[Memphiz]

could you somehow adapt the linker line so that -lm is after -lpython26 ?

[opencode]

I tried moving -lm after -lpython26 but that didn't help.

However, after playing around with it for a while, I think I figured out the problem - it's using the statically linked version of the python library instead of the dynamically linked one. If I try the same command and specify, instead of -lpython26, the full path to the static python2.6.a file (/xbmc-depends/...-native.../python2.6.a), I get the same error. I also have python 2.7 and its dev package installed on my machine. A similar error happens if I specify the full path to the static python2.7.a file on my system, but it works if I specify the full path to my python2.7.so file.

So I suspect if I had a dynamically linked version of python 2.6 compiled in the xbmc-depends/PREFIX location, it would all work fine. I'll poke around some more next time, but if anyone knows how to do that, please let me know.

EDIT: Changing the native python Makefile to use --enable-shared instead of --disable-shared seems to do the trick (plus LDFLAGS rpath to keep the python executable runnable given the custom prefix). Let me know if this sounds like the right approach.

Thanks,

David

[Memphiz]

mhhh i bet there was a reason why we statically link it in the first place. Though the whole python mess was way before i entered the project. I am not the right person to comment the shared approach here. The question is - why doesn't the static link and then -lm work (that missing symbol obviously comes from libm).