submitting support for suppressing static and dynamic libs

stavanger szijpeter at gmail.com
Wed Jun 1 00:45:52 PDT 2011 

Hi James,

I've been trying to cross compile the boost library for iOS for a while, but
no success (I am fairly new I think to anything that is needed here). I was
very much pleased when I read your letter but unfortunately your link is
seems to be dead now. Could you please provide me another one? Also, could
you give me some instructions how to use it (maybe scripts that you were
using).

Thanks,
   Peter



James Gregurich wrote:
> 
> 
> In this latest round of work, I've added support for suppressing static
> and dynamic libs. This feature is useful because when passing -l flags to
> the linker, dynamic libs take precedence over static libs. If one wants to
> use static libs, then he has to explicitly reference the lib by path using
> the -L option. The problem is avoided by not having dynamic libs if you
> don't need them. Also, Apple disallows use of dylibs for iOS anyway.  I've
> added two more variables to the .conf file: 
> 
> $suppress_static_libs
> $suppress_shared_libs
> 
> 
> If the first is on, dylib generation is forced and static lib generation
> is suppressed.
> If the second is on, static generation is forced and dylib generation is
> suppressed.
> If neither flag is set, the system defaults to the usual behavior.
> If both flags are set, the system aborts with an error indicating the
> state is invalid.
> 
> The changes for this feature are in portconfigure.tcl and macports.tcl. 
> 
> 
> For autoconf ports, no changes should be necessary to the portfile to
> support these features. The normal configure flags are used to enable and
> disable the building of the libs.  For custom build systems, the port
> files will have to be modified to check the variables. However, if the
> flags are not used in the .conf file, then all existing portfiles will
> work normally. 
> 
> Portmain.tcl has a minor bugfix.
> 
> 
> These changes have been tested with the 5 test ports that have been used
> and  against MacOSX, iOS 4.2 and the iOS simulator for 4.2. Everything
> works as expected as best I can tell. I'm not planning any more changes
> until I hear back from the macports developers as to whether this work is
> desired. I have what I need to proceed on my iOS projects for now with
> this latest round of changes. I think I've demoed that macports can be
> cleanly modified to fully support building libs for iOS. So, my job is
> done and I'm returning to my normal duties.
> 
> There does need to be further thought put into the design of the system.
> In some of the ports, I had to use conditional code to determine whether a
> build is using muniversal or not. This code is necessary because variables
> like worksrcpath are not adjusted for muniversal. So, if it is a universal
> build, I have to use one variable and it if isnt, I have to use another.
> Some thought needs to be put into a new variable arrangment so that for
> muniversal builds, a port can refer to either worksrcpath or the
> muniversal equivalent of worksrcpath for the current architecture with a
> single variable. Other variables that need to be considered in the same
> way:  destroot, configure.cc_archflags and its cousins.
> 
> isysroot needs to be worked into the design a little more thoroughly so
> that portfiles don't have to hard-code isysroot. Perhaps it can be tacked
> on to archflags when necessary.
> 
> 
> muniversal needs to be extended so that each architecture gets its own set
> of pre/post phases. The variables need to be set up so that a single set
> of variables can serve both the universal and non-universal cases....as
> discussed earlier. Perhaps the answer is to create a new portgroup or new
> version of muniversal that changes this behavior to preserve compatibility
> with existing portfiles. portfiles that get upgraded to work with iOS can
> be changed to use the new version of muniversal. I wasn't sure how to set
> up the pre/post phases, so I just set up simple call-back functions as
> earlier documented. 
> 
> 
> my latest changes can be downloaded at the following link. The download is
> 200MB because I didn't bother going to the extra trouble to strip out the
> binaries. I was in a hurry, and didn't want to take the time. The download
> only takes 5 or 10 minutes on a decent connection. This should be good
> enough.
> 
> https://files.me.com/bayoubengal/9i3y2z
> 
> 
> 
> 
> -James
> 
> On Feb 16, 2011, at 7:33 PM, James Gregurich wrote:
> 
>> 
>> I have added additional functionality to macports. The following ports
>> now build:  icu, zlib, bzip2, expat and boost. These ports build
>> universal and non-universal for MacOSX (ppc, ppc64, i386, x86_64) and
>> iPhoneOS (armv6, armv7) as well as non-universal for the iPhoneSimulator
>> (only i386 exists on this one). They build with the default compilers for
>> each platform as well as clang 2.8 for MacOSX.
>> 
>> 
>> I think this experiment is successful. I've made only minor adjustments
>> to the design on macports. Most of the work is simply logically existing
>> the design that is already present to handle additional functionality
>> needed for complicated projects (such as boost). The changes to ports
>> files are reasonable. Boost required significant alteration due to the
>> nature of the boost build system and the desire to use "combined"
>> architecture when possible to speed up builds. Ports for MacOSX should
>> keep building without modification. Ports can be updated to handle iOS on
>> an as-needed basis. The change can be as simple as adding the muniversal
>> PortGroup if autoconf is used as the build system for the projects as
>> configure scripts break on multiple architecture flags on the
>> preprocessor check. 
>> 
>> I have tested the changes against clang and while using the 10.5 sdk. The
>> 5 ports I've handled are certainly diverse. I can't imagine any project
>> having more complicated needs than boost. 
>> 
>> There is certainly a need in the mac developer community to provide for
>> iOS development, and I have proven that macports can be cleanly extended
>> to handle the job.  Given my results, I am requesting macports accept the
>> work. I'm sure additional changes will be required to make the work
>> complete, and I'm certainly willing to cooperate on providing the
>> developer resources to get the work done. 
>> 
>> 
>> 
>> link to zip file of /iopt:   
>> 
>> 
>> 
>> The following files have been changed:
>> 
>> macports.conf
>> portmain.tcl
>> portconfigure.tcl
>> portutil.tcl
>> muniversal.tcl
>> xcodeversion.tcl
>> 
>> portfiles for the projects listed above.
>> 
>> 
>> The following functionality has been implemented:
>> 
>> 1) I have extended the muniversal portgroup to add pre- and post-
>> callbacks on configure, destroot and build such that a portfile can be
>> called for configuring, building and destrooting each architecture being
>> built. These callbacks are simple flat functions. There is probably a way
>> more consistent with the overall design to handle these callbacks, but no
>> one answered my request for guidance on the point, so I just set it up
>> the best way I could figure out on my own. Certainly, the design is good
>> enough to prove the concept works.
>> 
>> 
>> 2) corrected flaw in the setting of the configure CPPFLAGS such that the
>> preprocessor gets the correct sdk and arch flags.
>> 
>> 3) hard-coded support for clang 2.x. see 'macports-clang-2.0' in the
>> code. added entries for apple's clang with cxx and cpp. 
>> 
>> 4) added parallel build functionality back to boost portfile
>> 
>> 5) added the following variables:
>> 
>> 	muniversal-destroot
>>    configure.cxx_archflags
>>    configure.target_uses_host_option  (overrides adding --host to
>> configure.cmd invocation)
>> 
>> 
>> 6) added the following callbacks:
>> 
>> 
>>    pre-muniversal-configure  
>>    post-muniversal-configure
>>    post-muniversal-destroot
>>    pre-muniversal-build
>>    post-muniversal-build
>> 
>> 
>> 7) I broke the assumption that xcode must in $developer_dir since it
>> isn't there in the case of an iOS cross-compile.
>> 
>> 
>> 
>> 
>> changes to boost portfile:
>> 
>> 1) the boost build system offers a "combined" architecture setting for
>> building universal binaries on MacOSX. If the desired configuration can
>> be handled by the combined architecture mechanism, then use it. If it
>> can't, then fall back to using muniversal portgroup to build universal
>> binaries. 
>> 
>> 2) program_options does not build on iOS due to sdk header differences.
>> There is a patch coming in a future version of boost. program_options is
>> disabled.
>> 
>> 3) only static libs are generated for iOS.
>> 
>> NOTE: I have not tested the variants.
>> 
>> 
>> changes to icu portfile:
>> 
>> 1) minor modifications and cleanup.
>> 
>> 
>> changes to zlib portfile:
>> 
>> 1) added muniversal portgroup.
>> 
>> 
>> changes to bzip2 portfile:
>> 
>> 1) added sdk flags to build args.
>> 2) patch makefile in post-destroot to disable tests for a cross-compile. 
>> 
>> 
>> changes to expat portfile:
>> 
>> 1) added muniversal portgroup.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> macports-dev mailing list
>> macports-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
> 
> 
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
> 
> 

-- 
View this message in context: http://old.nabble.com/submitting-additional-work-on-iOS-cross-compiling-support-tp30946578p31715339.html
Sent from the MacPorts - Developer mailing list archive at Nabble.com.

More information about the macports-dev mailing list