Samba 3.0.22 Porting by Vidya Sagar

26
#ifdef mpeix
ldap_unbind_s(ldap_state->ldap_struct);
#else
ldap_unbind_ext(ldap_state->ldap_struct, NULL, NULL);
#endif
If you encounter unresolved symbols which do not seem to be covered by any of the above mentioned class,
either refer
common runtime problems for other suggestions.
Once all the unresolved routines are resolved rebuild the application as mentioned in step 8 and 9. You now
should have an application that is built, installed on the build machine and ready to test.
3.12 Testing the features to be supported (make test)
In section 3.1 you would have created a list of features your application supports. Unit test all those features and
document the results, especially if you found any limitation during testing. One must also decide if this is an
expected outcome to be documented, or a bug which needs to be fixed before you proceed. Many applications
contain standard tests to be done after successfully building the code on target machine. Identify the tests
applicable to your port and run make test to carry out those tests.
shell/iX> pwd
/SAMBA/SMB3022/src/samba-3.0.22-mpe/source #Just for example
shell/iX> make test #not applicable to Samba
After running those tests analyze the test results against expected outcomes. Standard tests available in Samba
source tree do not apply to MPE/iX Samba as test scripts are written for Unix environments, hence you can skip
running standard test i.e. no need to run make test. For HP Lab engineers a list of standard tests should be
performed for Samba/iX which is available at
http://jazz.external.hp.com/src/samba/samba-3.0.22-test.htm.
3.13 Packaging
Packaging the binaries and essential source for distribution is solely the porter’s responsibility. While creating a
distribution package you must keep in mind that it should not include any extraneous file, any experimental file,
any temporary file etc which increases the deliverable size. Also, it should not miss any binary, library, header file,
manpages. You should also include any script can be useful in running the application. Typically only a diff of
vanilla and mpe source should be distributed, it is not recommended to include the entire source as that can be
available from the application’s official site. The package must have a script to install it on target machine. The
installation script must check and create the proper account structure if absent, sets the proper capability to the
user, fixes the binary and directory permission and finally cleanup, i.e., purge the temporary created files/directory
during installation.
Normally HP distributes ported applications for MPE/iX as patches which can be installed using PATCHIX or
AUTOPAT. Their distribution requires minimally following three files
• Program file P00xxxx which is the package for distribution.
• IHFxxxx file is the installation job file which is streamed by patchix or autopat to install the patch.
• README file REAxxxx contains installation notes.
where xxxx is the last four characters of patchid.
If you are packaging a patch for use with HP installation tools you should ensure that the job IHFxxxx invoke the
installation script.
Appendix A lists the script to package Samba and few important notes on patch creation.
3.14 Documentation notes
Given the limitations of the MPE/iX POSIX implementation it is possible to successfully port a useful percentage
of an application’s feature set. However it is quite normal that features a user may be looking for remains
unsupported or supported with changed behavior. One must document those and advertise them in such a way
that user should not miss them. Please refer
Samba-3.0.22 communicator article [7] on Jazz which lists significant
limitations of Samba-3.0.22 on MPE/iX. There are similar articles on Jazz for other ported products.