Re: [macports-ports] branch master updated: snowleopardfixes: new port to deal with missing functions in Snow Leopard

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [macports-ports] branch master updated: snowleopardfixes: new port to deal with missing functions in Snow Leopard

Ryan Schmidt-24

On Jul 3, 2017, at 14:46, Marius Schamschula <[hidden email]> wrote:

Marius Schamschula (Schamschula) pushed a commit to branch master
in repository macports-ports.

https://github.com/macports/macports-ports/commit/3efea307091e06b1176c8e9c1f771dd1efdea179

The following commit(s) were added to refs/heads/master by this push:
     new 3efea30  snowleopardfixes: new port to deal with missing functions in Snow Leopard
3efea30 is described below

commit 3efea307091e06b1176c8e9c1f771dd1efdea179
Author: Marius Schamschula <[hidden email]>
AuthorDate: Mon Jul 3 14:46:31 2017 -0500

    snowleopardfixes: new port to deal with missing functions in Snow Leopard
---
 devel/snowleopardfixes/Portfile | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/devel/snowleopardfixes/Portfile b/devel/snowleopardfixes/Portfile
new file mode 100644
index 0000000..d628fc9
--- /dev/null
+++ b/devel/snowleopardfixes/Portfile
@@ -0,0 +1,31 @@
+# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
+
+PortSystem          1.0
+PortGroup           github 1.0
+PortGroup           muniversal 1.0

Why muniversal?

+#PortGroup          cmake 1.0
+
+github.setup        kencu snowleopardfixes 72c90d36d20023eab306b1f9be077c5e11c3fc58
+version             20170702
+categories          sysutils
+platforms           darwin
+maintainers         gmail.com:ken.cunningham.webuse
+license             GPL-2
+
+description         A library to replace common functions missing from SnowLeopard
+long_description    ${description}
+
+checksums           rmd160  43303d2c290455488a806b05fe22647b8b070e63 \
+                    sha256  b73fdaed13fb50a437cd5cbe530096f9afb921820ce1dcd292bc367470888b46
+
+use_configure       no
+
+
+build.env           CXX="${configure.cxx}" \
+                    CXXFLAGS="${configure.cxxflags} [get_canonical_archflags cxx]" \
+                    CC="${configure.cc}" \
+                    CFLAGS="${configure.cflags}" \
+                    LDFLAGS="${configure.ldflags}  [get_canonical_archflags ld]" \
+                    PREFIX=${prefix}
get_canonical_archflags won't do the right thing with muniversal. Look in the log and note how the "x86_64" build and the "i386" build both build for both x86_64 and i386.

The fact that the universal build succeeds and actually produces universal binaries suggests the muniversal portgroup isn't needed. All you need is "variant universal {}" after "use_configure no".

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [macports-ports] branch master updated: snowleopardfixes: new port to deal with missing functions in Snow Leopard

Ken Cunningham
Thanks --  these kinds of nuances are tricky.

Will alter that and update.

Ken



On 2017-07-04, at 1:29 AM, Ryan Schmidt wrote:


On Jul 3, 2017, at 14:46, Marius Schamschula <[hidden email]> wrote:

Marius Schamschula (Schamschula) pushed a commit to branch master
in repository macports-ports.

https://github.com/macports/macports-ports/commit/3efea307091e06b1176c8e9c1f771dd1efdea179

The following commit(s) were added to refs/heads/master by this push:
     new 3efea30  snowleopardfixes: new port to deal with missing functions in Snow Leopard
3efea30 is described below

commit 3efea307091e06b1176c8e9c1f771dd1efdea179
Author: Marius Schamschula <[hidden email]>
AuthorDate: Mon Jul 3 14:46:31 2017 -0500

    snowleopardfixes: new port to deal with missing functions in Snow Leopard
---
 devel/snowleopardfixes/Portfile | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/devel/snowleopardfixes/Portfile b/devel/snowleopardfixes/Portfile
new file mode 100644
index 0000000..d628fc9
--- /dev/null
+++ b/devel/snowleopardfixes/Portfile
@@ -0,0 +1,31 @@
+# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
+
+PortSystem          1.0
+PortGroup           github 1.0
+PortGroup           muniversal 1.0

Why muniversal?

+#PortGroup          cmake 1.0
+
+github.setup        kencu snowleopardfixes 72c90d36d20023eab306b1f9be077c5e11c3fc58
+version             20170702
+categories          sysutils
+platforms           darwin
+maintainers         gmail.com:ken.cunningham.webuse
+license             GPL-2
+
+description         A library to replace common functions missing from SnowLeopard
+long_description    ${description}
+
+checksums           rmd160  43303d2c290455488a806b05fe22647b8b070e63 \
+                    sha256  b73fdaed13fb50a437cd5cbe530096f9afb921820ce1dcd292bc367470888b46
+
+use_configure       no
+
+
+build.env           CXX="${configure.cxx}" \
+                    CXXFLAGS="${configure.cxxflags} [get_canonical_archflags cxx]" \
+                    CC="${configure.cc}" \
+                    CFLAGS="${configure.cflags}" \
+                    LDFLAGS="${configure.ldflags}  [get_canonical_archflags ld]" \
+                    PREFIX=${prefix}
get_canonical_archflags won't do the right thing with muniversal. Look in the log and note how the "x86_64" build and the "i386" build both build for both x86_64 and i386.

The fact that the universal build succeeds and actually produces universal binaries suggests the muniversal portgroup isn't needed. All you need is "variant universal {}" after "use_configure no".


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [macports-ports] branch master updated: snowleopardfixes: new port to deal with missing functions in Snow Leopard

Ken Cunningham
In reply to this post by Ryan Schmidt-24
>
> Why muniversal?

> The fact that the universal build succeeds and actually produces universal binaries suggests the muniversal portgroup isn't needed. All you need is "variant universal {}" after "use_configure no".
>

thanks for fixing that. I just used muniversal because I saw the portgroup there, and adding it worked.

TBH, I never would have guessed that adding this bit to the portfile

variant universal {}

would enable macports to build it universal, but I'm certainly glad you knew. At first glance, I would have thought it would disable a universal build, like that construct seems to do for destroot, etc. ..

BR,

Ken


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [macports-ports] branch master updated: snowleopardfixes: new port to deal with missing functions in Snow Leopard

Ryan Schmidt-24

On Jul 10, 2017, at 09:44, Ken Cunningham wrote:

>> Why muniversal?
>
>> The fact that the universal build succeeds and actually produces universal binaries suggests the muniversal portgroup isn't needed. All you need is "variant universal {}" after "use_configure no".
>
> thanks for fixing that. I just used muniversal because I saw the portgroup there, and adding it worked.
>
> TBH, I never would have guessed that adding this bit to the portfile
>
> variant universal {}
>
> would enable macports to build it universal, but I'm certainly glad you knew. At first glance, I would have thought it would disable a universal build, like that construct seems to do for destroot, etc. ..

MacPorts defines a default universal variant that works with autotools configure scripts and some hand-made configure scripts.

"use_configure no" declares that this port does not use any configure script, therefore MacPorts disables its default universal variant and it's up to you to provide one.

"variant universal {}" declares that a universal variant should be offered to the user, and that it requires no additional code as compared to the regular build.

"get_canonical_archflags" returns the canonical archflags, informed by the user's processor (or build_arch setting in macports.conf) and whether or not the user has selected the universal variant (and, if so, the universal_archs setting in macports.conf).

"PortGroup muniversal 1.0" defines a universal variant that builds multiple times, once for each arch, then uses lipo(1) to glue them together. This is needed for build systems that incorrectly assume results obtained during the configure phase (such as endianness or bitness tests) are valid during the build phase but snowleopardfixes doesn't make those assumptions.

~

MacPorts declares a default build phase that runs "make" and a default destroot phase that runs "make install".

"destroot {}" declares that this default destroot phase is to be overridden with nothing, which would result in a port that can't be installed, so that wouldn't be done. It wouldn't be unusual however for the destroot phase to be overridden with a non-empty block that installs files.

"build {}" is sometimes used to declare an empty build phase, for unusual build systems that combine building with either configuring or installing. More likely you would see a port overriding the build phase with a non-empty block that does the build.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [macports-ports] branch master updated: snowleopardfixes: new port to deal with missing functions in Snow Leopard

Jeremy Lavergne-2
Has this list been added to the Guide?


> MacPorts defines a default universal variant that works with autotools configure scripts and some hand-made configure scripts.
>
> "use_configure no" declares that this port does not use any configure script, therefore MacPorts disables its default universal variant and it's up to you to provide one.
>
> "variant universal {}" declares that a universal variant should be offered to the user, and that it requires no additional code as compared to the regular build.
>
> "get_canonical_archflags" returns the canonical archflags, informed by the user's processor (or build_arch setting in macports.conf) and whether or not the user has selected the universal variant (and, if so, the universal_archs setting in macports.conf).
>
> "PortGroup muniversal 1.0" defines a universal variant that builds multiple times, once for each arch, then uses lipo(1) to glue them together. This is needed for build systems that incorrectly assume results obtained during the configure phase (such as endianness or bitness tests) are valid during the build phase but snowleopardfixes doesn't make those assumptions.
>
> ~
>
> MacPorts declares a default build phase that runs "make" and a default destroot phase that runs "make install".
>
> "destroot {}" declares that this default destroot phase is to be overridden with nothing, which would result in a port that can't be installed, so that wouldn't be done. It wouldn't be unusual however for the destroot phase to be overridden with a non-empty block that installs files.
>
> "build {}" is sometimes used to declare an empty build phase, for unusual build systems that combine building with either configuring or installing. More likely you would see a port overriding the build phase with a non-empty block that does the build.
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [macports-ports] branch master updated: snowleopardfixes: new port to deal with missing functions in Snow Leopard

Ken Cunningham
In reply to this post by Ryan Schmidt-24

On 2017-07-21, at 4:21 AM, Ryan Schmidt wrote:


> "variant universal {}" declares that a universal variant should be offered to the user, and that it requires no additional code as compared to the regular build.
>

> "PortGroup muniversal 1.0" defines a universal variant that builds multiple times, once for each arch, then uses lipo(1) to glue them together.


Thanks for the detailed response, Ryan. I believe get how this works now.

If it works like I think it does, PortGroup muniversal does manually what Apple's driverdriver.c does behind the scenes for apple gcc compilers (gcc4.2, etc) and is built in to clang … so PortGroup muniversal should not be needed for anything that is being handled by an Apple compiler that can understand what to do with multiple -arch flags.

<https://opensource.apple.com/source/gcc_42/gcc_42-5577/driverdriver.c>

If that is all true, it makes me wonder what if anything actually does need PortGroup universal  to build correctly any more.

Ken
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [macports-ports] branch master updated: snowleopardfixes: new port to deal with missing functions in Snow Leopard

Ryan Schmidt-24

On Jul 21, 2017, at 12:56, Kenneth F. Cunningham wrote:

> If it works like I think it does, PortGroup muniversal does manually what Apple's driverdriver.c does behind the scenes for apple gcc compilers (gcc4.2, etc) and is built in to clang … so PortGroup muniversal should not be needed for anything that is being handled by an Apple compiler that can understand what to do with multiple -arch flags.
>
> <https://opensource.apple.com/source/gcc_42/gcc_42-5577/driverdriver.c>
>
> If that is all true, it makes me wonder what if anything actually does need PortGroup universal to build correctly any more.

The problem is with configure scripts that make assumptions that don't hold when building for multiple architectures.

For example, consider a configure script that checks whether we are building for 32 or 64 bit. It does so by compiling and running a small C program and running it and checking what happens. It sets a define based on the result, and that define is used in ifdefs in the code during compilation.

If the configure script check is compiled with -arch i386 -arch x86_64 and the resulting program is then run, it will only run as one arch -- x86_64 on 64-bit systems, and i386 on 32-bit systems. So the result of running this program will only give the correct answer on one arch, not both. So on 64-bit systems it will build everything -- both the x86_64 and i386 parts -- as if they were both 64-bit, and on 32-bit systems it will build both parts as if they were 32-bit.

The muniversal portgroup fixes this by extracting the source to two different directories, one for each arch, running configure, build and destroot separately in each of those two directories, and then using lipo(1) to combine all the binaries in the two destroots in a single merged destroot, which is what's then installed.

Loading...