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

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

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

[Brandon Allbery]

On Thu, Mar 10, 2016 at 8:20 PM, Mojca Miklavec  wrote:

> >> 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).


I just noticed this... my own assumption would be that, as availability of
PPC test hosts is ever-decreasing, newer versions of things would be more
likely to have bitrotted PPC support.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
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 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)
>>
>> At the same time clang++-mp-3.4 works fine even though both clang 3.4
>> and 3.7 are x86_64 only.
>>
>> 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. But I would be grateful for ideas about why clang 3.4
>> would be able to create ppc binaries and clang 3.7 not.
>>
>> 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

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

[Ryan Schmidt]

> 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)
> 
> At the same time clang++-mp-3.4 works fine even though both clang 3.4
> and 3.7 are x86_64 only.
> 
> 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. But I would be grateful for ideas about why clang 3.4
> would be able to create ppc binaries and clang 3.7 not.
> 
> 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



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

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

[Mojca Miklavec]

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)

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

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. But I would be grateful for ideas about why clang 3.4
would be able to create ppc binaries and clang 3.7 not.

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.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev