submitting support for suppressing static and dynamic libs

Tue Sep 27 06:36:44 PDT 2011

Apparently the link expired after a month. He put up a new file at the
same location a while ago, but it may be expired again by now. I'm not
sure why the download has to expire.

- Josh

On 2011-6-1 17:45 , stavanger wrote:
> 
> 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
>>
>>
> 