Re: [146550] trunk/dports/devel/libgit2/Portfile

[David Evans]

On 3/11/16 2:55 PM, s...@macports.org wrote:
> Revision
> 146550 
> Author
> s...@macports.org
> Date
> 2016-03-11 14:55:34 -0800 (Fri, 11 Mar 2016)
> 
> 
>   Log Message
> 
> libgit2: update to 0.24.0
> 
> 
>   Modified Paths
> 
>   * trunk/dports/devel/libgit2/Portfile <#trunkdportsdevellibgit2Portfile>
> 
> 
>   Diff
> 
> 
> Modified: trunk/dports/devel/libgit2/Portfile (146549 => 146550)
> 
> --- trunk/dports/devel/libgit2/Portfile 2016-03-11 22:55:33 UTC (rev 146549) 
> +++ trunk/dports/devel/libgit2/Portfile
> 2016-03-11 22:55:34 UTC (rev 146550) @@ -8,8 +8,7 @@ cmake.out_of_source yes 
> # don't forget to update libgit2-glib as
> well -github.setup libgit2 libgit2 0.23.4 v -revision 4 +github.setup libgit2 
> libgit2 0.24.0 v categories devel
> platforms darwin maintainers juanrgar devans openmaintainer
> 
> 
> 
>

I've been holding off on updating this port to version 0.24.0 due to the fact 
that the current version of libgit2-glib
will only build with the previous version.

Would appreciate it if you would revert this update until a compatible version 
is available upstream.

As it is, this update doesn't build due to checksum issues.

Thanks,  Dave

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Why is one compiler on 10.6 able to generate PPC binaries and not the other?

[Jeremy Huddleston Sequoia]

> On Mar 11, 2016, at 02:14, Mojca Miklavec  wrote:
> 
> Hi,
> 
> A few more questions:
> 
> (1) If I want to target 10.5 from 10.6 I probably need libmacho and
> libunwind as well? What about these lines from libcxxabi? Are they
> most likely needed or not?
> 
>pre-build {
>system "nm -g ${prefix}/lib/libmacho.a 2> /dev/null | grep
> ' \[DST\] ' | awk '{print \$3}' >
> ${worksrcpath}/unexported_symbols_macho"
>system "nm -g ${prefix}/lib/libunwind.a 2> /dev/null |
> grep ' \[DST\] ' | awk '{print \$3}' | grep -v '^__Unwind' >
> ${worksrcpath}/unexported_symbols_unwind"
>system "cat ${worksrcpath}/unexported_symbols_macho
> ${worksrcpath}/unexported_symbols_unwind >
> ${worksrcpath}/unexported_symbols"
>}

That just ensures that the build libc++abi.dylib doesn't re-export libunwind 
and libmacho.  Yes, you want to include those lines.

> 
>build.env-append \
>EXTRA_LDFLAGS="${prefix}/lib/libmacho.a
> ${prefix}/lib/libunwind.a -unexported_symbols_list
> ${worksrcpath}/unexported_symbols"
> 
> 
> (2) Installing libunwind +universal (with clang 3.4) fails with
> "clang: error: unknown argument: '-fno-integrated-as'". If I remove
> that flag from the Portfile it fails with
> 
> ld: absolute addressing (perhaps -mdynamic-no-pic) used in
> _unwind_phase2 from ./UnwindLevel1.o not allowed in slidable image.
> Use '-read_only_relocs suppress' to enable text relocs
> 
> and if I try to compile it with clang 3.7 it start installing gdbm
> (most likely it tries to build clang 3.7 + universal) and fails.
> 
> If I don't need libunwind on 10.6 (for 10.5), then I'll skip it. If I
> do, I need to find a workaround.
> 
> Thank you,
>Mojca



smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Why is one compiler on 10.6 able to generate PPC binaries and not the other?

[Jeremy Huddleston Sequoia]

> On Mar 11, 2016, at 01:50, Mojca Miklavec  wrote:
> 
> On 11 March 2016 at 09:35, Jeremy Huddleston Sequoia wrote:
>>> On Mar 10, 2016, at 17:20, Mojca Miklavec wrote:
>>> On 10 March 2016 at 21:26, Ryan Schmidt wrote:
> On Mar 10, 2016, at 1:00 PM, Mojca Miklavec wrote:
> 
> Hi,
> 
> While following
> https://trac.macports.org/wiki/LibcxxOnOlderSystems#Leopardppc
> on 10.6/x86_64 I tried to install clang 3.7 (thinking that version 3.7
> might have an even better support for PPC than 3.6).
> 
> The problem is that clang-mp-3.7 doesn't want to produce ppc binaries,
> so I wasn't able to install libcxx. I get:
> 
>> clang++-mp-3.7 a.cc -arch ppc
> ld: unknown/unsupported architecture name for: -arch ppc
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
>> 
>> The linker you have installed doesn't support ppc.  You need to install ld64 
>> with the +ld64_127 variant to get the last version of the linker that 
>> supported ppc.
> 
> Oh, thank you. That explains a lot.
> 
> I now did
>   sudo port -v -s install ld64 +ld64_127 +universal
> and clang 3.7 indeed no longer complains about unsupported architecture.
> 
> It is still complaining about:
> 
> ld: warning: ignoring file
> /opt/local/libexec/llvm-3.7/bin/../lib/clang/3.7.1/lib/darwin/libclang_rt.osx.a,
> missing required architecture ppc in file

I suspect that is because you had the wrong linker active when you built 
clang-3.7.  The architectures in that library are determined at build time 
based on the capabilities of the linker.  Sorry, but it looks like you may need 
to force rebuild clang-3.7.

> but it generates the binary as expected.
> 
> Now I'm stuck at
> 
> ld: symbol dyld_stub_binder not found (normally in libSystem.dylib).
> Needed to perform lazy binding to function _abort for architecture ppc
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)

dyld_stub_binder only exists for i386 and x86_64 on OSX.  It was added to 
libSystem in SnowLeopard.

Try forcing a 10.5 deployment target by adding -mmacosx-version-min=10.5 to 
work around that, and file a bug report about this at http://www.llvm.org/bugs 
(and let me know the number).


> from compiling libcxxabi:
> 
> /opt/local/bin/clang-mp-3.7 -I/opt/mp/10.5/include abort_message.o
> cxa_aux_runtime.o cxa_default_handlers.o cxa_demangle.o
> cxa_exception.o cxa_exception_storage.o cxa_guard.o cxa_handlers.o
> cxa_new_delete.o cxa_personality.o cxa_thread_atexit.o
> cxa_unexpected.o cxa_vector.o cxa_virtual.o exception.o
> private_typeinfo.o stdexcept.o typeinfo.o -arch ppc -arch i386 -arch
> x86_64 -o libc++abi.dylib -dynamiclib -nodefaultlibs -current_version
> 3.7.0 -compatibility_version 1 -install_name /usr/lib/libc++abi.dylib
> -lSystem -std=c++11 -stdlib=libc++ -fstrict-aliasing
> -Wstrict-aliasing=2 -Wsign-conversion -Wshadow -Wconversion
> -Wunused-variable -Wmissing-field-initializers -Wchar-subscripts
> -Wmismatched-tags -Wmissing-braces -Wshorten-64-to-32 -Wsign-compare
> -Wstrict-aliasing=2 -Wstrict-overflow=4 -Wunused-parameter
> -Wnewline-eof
> ld: symbol dyld_stub_binder not found (normally in libSystem.dylib).
> Needed to perform lazy binding to function _abort for architecture ppc
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> 
> It must have something to do with the fact that I use
>   export MACOSX_DEPLOYMENT_TARGET="10.5"
> but I didn't yet try to figure out how to modify Portfiles to actually
> link against 10.5 SDK.

Odd.  I'd expect MACOSX_DEPLOYMENT_TARGET="10.5" to not use dyld_stub_binder at 
all.

> 
> Before I spend half a day debugging: what's the easiest way to add
>   -isysroot /Developer/SDKs/MacOSX10.5.sdk
> to the relevant ports and which ports are most likely relevant for
> this error? Just libcxxabi?
> 
> I will also try to change "if {${os.major} < 10} { ... }" in libcxxabi
> to "< 11" just in case.
> 
> At the same time clang++-mp-3.4 works fine even though both clang 3.4
> and 3.7 are x86_64 only.
>> 
>> That's because it's actually just acting a s front-end to gcc for -arch ppc.
> 
> Thank you.
> 
> I'm now trying to rebuild everything as +universal (with ppc included
> in the list of universal architectures) and hope that it will work
> afterwards.
>> 
>> Nope.  That has nothing to do with it.  That just means what architectures 
>> the clang executable will run on, not which architectures and platforms it 
>> will target.
> 
> So I guess I can just an well uninstall "clang 3.4 +universal" a it
> makes absolutely no sense?
> 
> But I would be grateful for ideas about why clang 3.4
> would be able to create ppc binaries and clang 3.7 not.
>> 
>> 3.4 doesn't.
>> 3.7 does, but you didn't have the correct linker.
> 
> Thank you.
> 
> Mojca



smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev ma

Universal install script

[Craig Treleaven]

But we didn’t make the list.  ;

http://xkcd.com/1654/

Craig
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Why is one compiler on 10.6 able to generate PPC binaries and not the other?

[Mojca Miklavec]

Hi,

A few more questions:

(1) If I want to target 10.5 from 10.6 I probably need libmacho and
libunwind as well? What about these lines from libcxxabi? Are they
most likely needed or not?

pre-build {
system "nm -g ${prefix}/lib/libmacho.a 2> /dev/null | grep
' \[DST\] ' | awk '{print \$3}' >
${worksrcpath}/unexported_symbols_macho"
system "nm -g ${prefix}/lib/libunwind.a 2> /dev/null |
grep ' \[DST\] ' | awk '{print \$3}' | grep -v '^__Unwind' >
${worksrcpath}/unexported_symbols_unwind"
system "cat ${worksrcpath}/unexported_symbols_macho
${worksrcpath}/unexported_symbols_unwind >
${worksrcpath}/unexported_symbols"
}

build.env-append \
EXTRA_LDFLAGS="${prefix}/lib/libmacho.a
${prefix}/lib/libunwind.a -unexported_symbols_list
${worksrcpath}/unexported_symbols"


(2) Installing libunwind +universal (with clang 3.4) fails with
"clang: error: unknown argument: '-fno-integrated-as'". If I remove
that flag from the Portfile it fails with

ld: absolute addressing (perhaps -mdynamic-no-pic) used in
_unwind_phase2 from ./UnwindLevel1.o not allowed in slidable image.
Use '-read_only_relocs suppress' to enable text relocs

and if I try to compile it with clang 3.7 it start installing gdbm
(most likely it tries to build clang 3.7 + universal) and fails.

If I don't need libunwind on 10.6 (for 10.5), then I'll skip it. If I
do, I need to find a workaround.

Thank you,
Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Why is one compiler on 10.6 able to generate PPC binaries and not the other?

[Mojca Miklavec]

On 11 March 2016 at 09:35, Jeremy Huddleston Sequoia wrote:
>> On Mar 10, 2016, at 17:20, Mojca Miklavec wrote:
>> On 10 March 2016 at 21:26, Ryan Schmidt wrote:
 On Mar 10, 2016, at 1:00 PM, Mojca Miklavec wrote:

 Hi,

 While following
   https://trac.macports.org/wiki/LibcxxOnOlderSystems#Leopardppc
 on 10.6/x86_64 I tried to install clang 3.7 (thinking that version 3.7
 might have an even better support for PPC than 3.6).

 The problem is that clang-mp-3.7 doesn't want to produce ppc binaries,
 so I wasn't able to install libcxx. I get:

> clang++-mp-3.7 a.cc -arch ppc
 ld: unknown/unsupported architecture name for: -arch ppc
 clang: error: linker command failed with exit code 1 (use -v to see 
 invocation)
>
> The linker you have installed doesn't support ppc.  You need to install ld64 
> with the +ld64_127 variant to get the last version of the linker that 
> supported ppc.

Oh, thank you. That explains a lot.

I now did
sudo port -v -s install ld64 +ld64_127 +universal
and clang 3.7 indeed no longer complains about unsupported architecture.

It is still complaining about:

ld: warning: ignoring file
/opt/local/libexec/llvm-3.7/bin/../lib/clang/3.7.1/lib/darwin/libclang_rt.osx.a,
missing required architecture ppc in file

but it generates the binary as expected.

Now I'm stuck at

ld: symbol dyld_stub_binder not found (normally in libSystem.dylib).
Needed to perform lazy binding to function _abort for architecture ppc
clang: error: linker command failed with exit code 1 (use -v to see invocation)

from compiling libcxxabi:

/opt/local/bin/clang-mp-3.7 -I/opt/mp/10.5/include abort_message.o
cxa_aux_runtime.o cxa_default_handlers.o cxa_demangle.o
cxa_exception.o cxa_exception_storage.o cxa_guard.o cxa_handlers.o
cxa_new_delete.o cxa_personality.o cxa_thread_atexit.o
cxa_unexpected.o cxa_vector.o cxa_virtual.o exception.o
private_typeinfo.o stdexcept.o typeinfo.o -arch ppc -arch i386 -arch
x86_64 -o libc++abi.dylib -dynamiclib -nodefaultlibs -current_version
3.7.0 -compatibility_version 1 -install_name /usr/lib/libc++abi.dylib
-lSystem -std=c++11 -stdlib=libc++ -fstrict-aliasing
-Wstrict-aliasing=2 -Wsign-conversion -Wshadow -Wconversion
-Wunused-variable -Wmissing-field-initializers -Wchar-subscripts
-Wmismatched-tags -Wmissing-braces -Wshorten-64-to-32 -Wsign-compare
-Wstrict-aliasing=2 -Wstrict-overflow=4 -Wunused-parameter
-Wnewline-eof
ld: symbol dyld_stub_binder not found (normally in libSystem.dylib).
Needed to perform lazy binding to function _abort for architecture ppc
clang: error: linker command failed with exit code 1 (use -v to see invocation)

It must have something to do with the fact that I use
export MACOSX_DEPLOYMENT_TARGET="10.5"
but I didn't yet try to figure out how to modify Portfiles to actually
link against 10.5 SDK.

Before I spend half a day debugging: what's the easiest way to add
-isysroot /Developer/SDKs/MacOSX10.5.sdk
to the relevant ports and which ports are most likely relevant for
this error? Just libcxxabi?

I will also try to change "if {${os.major} < 10} { ... }" in libcxxabi
to "< 11" just in case.

 At the same time clang++-mp-3.4 works fine even though both clang 3.4
 and 3.7 are x86_64 only.
>
> That's because it's actually just acting a s front-end to gcc for -arch ppc.

Thank you.

 I'm now trying to rebuild everything as +universal (with ppc included
 in the list of universal architectures) and hope that it will work
 afterwards.
>
> Nope.  That has nothing to do with it.  That just means what architectures 
> the clang executable will run on, not which architectures and platforms it 
> will target.

So I guess I can just an well uninstall "clang 3.4 +universal" a it
makes absolutely no sense?

 But I would be grateful for ideas about why clang 3.4
 would be able to create ppc binaries and clang 3.7 not.
>
> 3.4 doesn't.
> 3.7 does, but you didn't have the correct linker.

Thank you.

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Why is one compiler on 10.6 able to generate PPC binaries and not the other?

[Jeremy Huddleston Sequoia]

> On Mar 10, 2016, at 17:20, Mojca Miklavec  wrote:
> 
> On 10 March 2016 at 21:26, Ryan Schmidt wrote:
>>> On Mar 10, 2016, at 1:00 PM, Mojca Miklavec wrote:
>>> 
>>> Hi,
>>> 
>>> While following
>>>   https://trac.macports.org/wiki/LibcxxOnOlderSystems#Leopardppc
>>> on 10.6/x86_64 I tried to install clang 3.7 (thinking that version 3.7
>>> might have an even better support for PPC than 3.6).
>>> 
>>> The problem is that clang-mp-3.7 doesn't want to produce ppc binaries,
>>> so I wasn't able to install libcxx. I get:
>>> 
 clang++-mp-3.7 a.cc -arch ppc
>>> ld: unknown/unsupported architecture name for: -arch ppc
>>> clang: error: linker command failed with exit code 1 (use -v to see 
>>> invocation)

The linker you have installed doesn't support ppc.  You need to install ld64 
with the +ld64_127 variant to get the last version of the linker that supported 
ppc.

>>> At the same time clang++-mp-3.4 works fine even though both clang 3.4
>>> and 3.7 are x86_64 only.

That's because it's actually just acting a s front-end to gcc for -arch ppc.

>>> I'm now trying to rebuild everything as +universal (with ppc included
>>> in the list of universal architectures) and hope that it will work
>>> afterwards.

Nope.  That has nothing to do with it.  That just means what architectures the 
clang executable will run on, not which architectures and platforms it will 
target.

>>> But I would be grateful for ideas about why clang 3.4
>>> would be able to create ppc binaries and clang 3.7 not.

3.4 doesn't.
3.7 does, but you didn't have the correct linker.

>>> Thank you,
>>>  Mojca
>>> 
>>> PS: I'm not actually using the PPC, I'm doing this all for fun and as
>>> a challenge. But I don't have any VM with 10.5, so I wanted to do the
>>> cross-compiling step on VM with 10.6.
>> 
>> Maybe:
>> 
>> https://trac.macports.org/changeset/129356
> 
> Weird. This changes predates the initial version of
>https://trac.macports.org/wiki/LibcxxOnOlderSystems
> that suggests cross-compiling libcxxabi with ppc support.
> 
> Judging from
>http://www.csl.cornell.edu/~fang/sw/llvm/
> I would imagine that there must be a way to compile libc++ (even on
> 10.4 and even if from another repository). The problem is a bit of a
> chicken-and-egg, requiring a working clang-3.6 (3.7?) compiler to
> build libc++; but 3.7 would refuse to do the linking step. Maybe I'll
> need to do that in multiple stages as described on that website.
> 
> I'm waiting for the universal build of clang 3.4 to finish first. I
> don't know if that will make any difference, but let's see.
> 
> Mojca

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev