Re: Building on OS X - how?

[Hubert Feyrer]

Good evening,

On Wed, 10 Aug 2016, Hubert Feyrer wrote:
I've added a bit more information below[2], but to cut a long story short - 
what excact build.sh options does one use these days to cross-build 
-current/amd64 from OS X? Did I miss any documentation[3]


It seems this was resolved somewhere after a "cvs update". Thanks to 
whoever the unsung hero is! And for the record, here is what I use to 
build now:


./build.sh -U -u -X ../xsrc-current -x -m amd64 -T tooldir.Darwin -O 
obj.amd64-Darwin-XXX -D destdir.amd64 -R release.amd64 -V HOST_CC=/usr/bin/cc 
-V HOST_CXX=/usr/bin/g++ release

There's one problem left but I will start a separate thread for that.


 - Hubert

Re: Building on OS X - how?

[Lloyd Parkes]

> On 16/08/2016, at 7:41 PM, matthew green  wrote:
> 
>> I've been trying to find when this breakage occurred,
> 
> it happened when your port switched to GCC 5.  sorry :-)

Yeah. While looking for the “backend” directory I saw gcc.old and gcc. A quick 
look showed me they were 4.x and 5.x and thought to myself “yeah, that’ll do 
it”.

The logs should now be available at 

https://www.must-have-coffee.gen.nz/LOG-distribution.txt 
 
https://www.must-have-coffee.gen.nz/LOG-cleandir.txt 
 
https://www.must-have-coffee.gen.nz/LOG-genmatch.txt 
 
https://www.must-have-coffee.gen.nz/libcpp-config.log 
 
https://www.must-have-coffee.gen.nz/libiberty-config.log 
 

Cheers,
Lloyd

Re: Building on OS X - how?

[Lloyd Parkes]

> On 12/08/2016, at 3:34 AM, Thor Lancelot Simon  wrote:
> 
> It's curious that this doesn't break the tools build, and doesn't
> prevent using the built tools to build a kernel!  If this can break
> the cross-build of the target compiler, I think we must have suddenly
> sprouted a rather serious instance of host/target confusion.

I’ve been trying to find when this breakage occurred, but I’ve given up because 
it seems to have been around for some months at least and other occasional 
compile problems with the tree aren’t helping be pick arbitrary dates in the 
past to build in.

I think you are right about the host/target confusion because the error 
messages refer to /usr/bin/cc and x86_68. I can also see Mach-O format object 
files outside the tools object directory, which I assume to be a sign of 
something going badly wrong.

I’ll try following mrg’s suggestion and see what I get.

Cheers,
Lloyd

re: Building on OS X - how?

[matthew green]

> I've been trying to find when this breakage occurred,

it happened when your port switched to GCC 5.  sorry :-)


.mrg.

Re: Building on OS X - how?

[Hubert Feyrer]

Hi Jaromir,

> Am 13.08.2016 um 22:06 schrieb Jaromír Doleček :
> FWIW, build of tools for both i386 and sparc64 finished without
> problems for me on Mac OS X host (10.11.6), building from clean
> sources.

Do you have the Mac OS X Command Line Tools installed?
It’s not part of XCode but needs extra installation.

 - Hubert

Re: Building on OS X - how?

[Thor Lancelot Simon]

On Sat, Aug 13, 2016 at 10:06:35PM +0200, Jarom??r Dole??ek wrote:
> FWIW, build of tools for both i386 and sparc64 finished without
> problems for me on Mac OS X host (10.11.6), building from clean
> sources.

The problem is not with the tools build.

Thor

Re: Building on OS X - how?

[Jaromír Doleček]

FWIW, build of tools for both i386 and sparc64 finished without
problems for me on Mac OS X host (10.11.6), building from clean
sources.

Jaromir

2016-08-12 21:54 GMT+02:00 matthew green :
> Thor Lancelot Simon writes:
>> On Thu, Aug 11, 2016 at 04:05:06PM +0100, Robert Swindells wrote:
>> >
>> > >2) /usr/bin/cc:
>> > >Undefined symbols for architecture x86_64: "_iconv"
>> > >in external/gpl3/gcc/usr.bin/backend
>> >
>> > This should be in libc.
>>
>> For what value of "should"?  _iconv is in the implementation-defined
>> namespace.
>>
>> It's curious that this doesn't break the tools build, and doesn't
>> prevent using the built tools to build a kernel!  If this can break
>> the cross-build of the target compiler, I think we must have suddenly
>> sprouted a rather serious instance of host/target confusion.
>
> this fails building the native gcc, which requires a bunch of host
> tools to run.  going on your following post, there is a problem
> with genmatch.  i don't have access to any osx to test, so i'm not
> sure where to start looking.  there aren't too many rules used in
> the creation of "genmatch" binary - can you run "make cleandir"
> in usr.bin/backend/ and then "make MAKEVERBOSE=2 genmatch", and
> post all the commands run?  there probably will be a configure
> run in here, and perhaps the output of it also matters.
>
>
> .mrg.

Re: Building on OS X - how?

[Joerg Sonnenberger]

On Sat, Aug 13, 2016 at 03:17:16PM +0200, Hubert Feyrer wrote:
> 
> Hi,
> 
> On Sat, 13 Aug 2016, matthew green wrote:
> > this fails building the native gcc, which requires a bunch of host
> > tools to run.  going on your following post, there is a problem
> > with genmatch.  i don't have access to any osx to test, so i'm not
> > sure where to start looking.  there aren't too many rules used in
> > the creation of "genmatch" binary - can you run "make cleandir"
> > in usr.bin/backend/ and then "make MAKEVERBOSE=2 genmatch", and
> > post all the commands run?  there probably will be a configure
> > run in here, and perhaps the output of it also matters.
> 
> I've put script(1) output here:
> http://www.feyrer.de/Misc/priv/build-fail-macos.txt

Consider adding am_cv_func_iconv=no in
external/gpl3/gcc/usr.bin/host-libcpp/Makefile's configure call.

Joerg

re: Building on OS X - how?

[Hubert Feyrer]

Hi,

On Sat, 13 Aug 2016, matthew green wrote:

this fails building the native gcc, which requires a bunch of host
tools to run.  going on your following post, there is a problem
with genmatch.  i don't have access to any osx to test, so i'm not
sure where to start looking.  there aren't too many rules used in
the creation of "genmatch" binary - can you run "make cleandir"
in usr.bin/backend/ and then "make MAKEVERBOSE=2 genmatch", and
post all the commands run?  there probably will be a configure
run in here, and perhaps the output of it also matters.


I've put script(1) output here:
http://www.feyrer.de/Misc/priv/build-fail-macos.txt

Thanks in advance for having a look!


 - Hubert

Re: Building on OS X - how?

[Michael Plass]

On Aug 12, 2016, at 6:44 PM, Michael Plass wrote:

> The config.status for host-libcpp is at 
> https://gist.github.com/mfplass/6a75e12339bc97223854953fee1fa9fc

And the relevant diffs with the working (in-jail) build is

619,620c619,620
< S["LTLIBICONV"]="-L/usr/local/lib -liconv -R/usr/local/lib"
< S["LIBICONV"]="/usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib"
---
> S["LTLIBICONV"]=""
> S["LIBICONV"]=""
656c656
< S["CPPFLAGS"]="-I/usr/local/include"
---
> S["CPPFLAGS"]=""

so maybe the linker flags for LIBICONV aren't getting pulled in where they 
should be?

Re: Building on OS X - how?

[Michael Plass]

On Aug 12, 2016, at 12:54 PM, matthew green wrote:

> Thor Lancelot Simon writes:
>> On Thu, Aug 11, 2016 at 04:05:06PM +0100, Robert Swindells wrote:
>>> 
 2) /usr/bin/cc:
   Undefined symbols for architecture x86_64: "_iconv"
   in external/gpl3/gcc/usr.bin/backend
>>> 
>>> This should be in libc.
>> 
>> For what value of "should"?  _iconv is in the implementation-defined
>> namespace.
>> 
>> It's curious that this doesn't break the tools build, and doesn't
>> prevent using the built tools to build a kernel!  If this can break
>> the cross-build of the target compiler, I think we must have suddenly
>> sprouted a rather serious instance of host/target confusion.
> 
> this fails building the native gcc, which requires a bunch of host
> tools to run.  going on your following post, there is a problem
> with genmatch.  i don't have access to any osx to test, so i'm not
> sure where to start looking.  there aren't too many rules used in
> the creation of "genmatch" binary - can you run "make cleandir"
> in usr.bin/backend/ and then "make MAKEVERBOSE=2 genmatch", and
> post all the commands run?  there probably will be a configure
> run in here, and perhaps the output of it also matters.
> 
> 
> .mrg.
> 
> 

I still have a log from the maybe-similar failure on freebsd:

https://gist.github.com/mfplass/98801ea2ab2cd3d5abd92faa3c47ab1c

It, too, is trying to build genmatch.

The config.status for host-libcpp is at 
https://gist.github.com/mfplass/6a75e12339bc97223854953fee1fa9fc

- Michael

re: Building on OS X - how?

[matthew green]

Thor Lancelot Simon writes:
> On Thu, Aug 11, 2016 at 04:05:06PM +0100, Robert Swindells wrote:
> > 
> > >2) /usr/bin/cc:
> > >Undefined symbols for architecture x86_64: "_iconv"
> > >in external/gpl3/gcc/usr.bin/backend
> > 
> > This should be in libc.
> 
> For what value of "should"?  _iconv is in the implementation-defined
> namespace.
> 
> It's curious that this doesn't break the tools build, and doesn't
> prevent using the built tools to build a kernel!  If this can break
> the cross-build of the target compiler, I think we must have suddenly
> sprouted a rather serious instance of host/target confusion.

this fails building the native gcc, which requires a bunch of host
tools to run.  going on your following post, there is a problem
with genmatch.  i don't have access to any osx to test, so i'm not
sure where to start looking.  there aren't too many rules used in
the creation of "genmatch" binary - can you run "make cleandir"
in usr.bin/backend/ and then "make MAKEVERBOSE=2 genmatch", and
post all the commands run?  there probably will be a configure
run in here, and perhaps the output of it also matters.


.mrg.

Re: Building on OS X - how?

[Martin Husemann]

On Thu, Aug 11, 2016 at 12:15:32PM -0400, Thor Lancelot Simon wrote:
> If that is the case, then it means that the compilation of a *target*
> executable is using *host* header files.  That will eventually cause corrupt
> builds even in a NetBSD-on-NetBSD build.

It is in host-libiberty and runs a local configure there, doesn't it?

Martin

Re: Building on OS X - how?

[Michael Plass]

On Aug 11, 2016, at 8:32 AM, Thor Lancelot Simon wrote:

> On Thu, Aug 11, 2016 at 04:29:54PM +0200, Hubert Feyrer wrote:
>> 
>> 2) /usr/bin/cc:
>>   Undefined symbols for architecture x86_64: "_iconv"
>>   in external/gpl3/gcc/usr.bin/backend
> 
> This bug has appeared within the past few days and breaks my builds
> on OS X 10.9.5 as well.  I'm not having much luck tracking it down.
> 
> Thor
> 
> 

That sounds like it may be related to a problem I ran into when cross-building
from FreeBSD (11 beta something). With a package for libiconv installed, the 
compile
must have found the header in /usr/local/include, but the link step did not use 
the 
right library.  I worked around this by building in a jail with no packages 
installed.

- Michael

Re: Building on OS X - how?

[Thor Lancelot Simon]

On Thu, Aug 11, 2016 at 04:05:06PM +0100, Robert Swindells wrote:
> 
> >2) /usr/bin/cc:
> >Undefined symbols for architecture x86_64: "_iconv"
> >in external/gpl3/gcc/usr.bin/backend
> 
> This should be in libc.

For what value of "should"?  _iconv is in the implementation-defined
namespace.

It's curious that this doesn't break the tools build, and doesn't
prevent using the built tools to build a kernel!  If this can break
the cross-build of the target compiler, I think we must have suddenly
sprouted a rather serious instance of host/target confusion.

Thor

Re: Building on OS X - how?

[Thor Lancelot Simon]

On Thu, Aug 11, 2016 at 09:00:35AM -0700, Michael Plass wrote:
> 
> That sounds like it may be related to a problem I ran into when cross-building
> from FreeBSD (11 beta something). With a package for libiconv installed, the 
> compile
> must have found the header in /usr/local/include, but the link step did not 
> use the 
> right library.  I worked around this by building in a jail with no packages 
> installed.

If that is the case, then it means that the compilation of a *target*
executable is using *host* header files.  That will eventually cause corrupt
builds even in a NetBSD-on-NetBSD build.

Thor

Re: Building on OS X - how?

[Thor Lancelot Simon]

On Thu, Aug 11, 2016 at 04:29:54PM +0200, Hubert Feyrer wrote:
> 
> 2) /usr/bin/cc:
>Undefined symbols for architecture x86_64: "_iconv"
>in external/gpl3/gcc/usr.bin/backend

This bug has appeared within the past few days and breaks my builds
on OS X 10.9.5 as well.  I'm not having much luck tracking it down.

Thor

Re: Building on OS X - how?

[Robert Swindells]

Hubert Feyrer  wrote:
>On Wed, 10 Aug 2016, co...@sdf.org wrote:
>> There shouldn't be anything special about building from OS X.
>> You just ran into a setup that happens to not work with it.
>
>Well, that's my question: what _does_ work?
>
>I have OS X 10.10.5 (Yosemite) and no wish to upgrade,
>so pointers on where to get proper Xcode, Command line tools etc. would 
>help.

Can you compile a "Hello World" C program with either set of tools ?

>> It'd be good to file a bug report for it, or at least mention where it
>> fails.
>
>Here are the details and errors for two builds, 1) with GCC/LLVM 
>(/Developer/usr/bin/cc) and 2) with LLVM/CLANG (/usr/bin/cc).
>
>Short:
>1) /Developer/usr/bin/cc:
>error: 'LONG_MIN' undeclared
>in tools/binutils

This should be in limits.h, it is a part of the C standard.

>2) /usr/bin/cc:
>Undefined symbols for architecture x86_64: "_iconv"
>in external/gpl3/gcc/usr.bin/backend

This should be in libc.

Robert Swindells

Re: Building on OS X - how?

[Hubert Feyrer]

On Wed, 10 Aug 2016, co...@sdf.org wrote:

There shouldn't be anything special about building from OS X.
You just ran into a setup that happens to not work with it.


Well, that's my question: what _does_ work?

I have OS X 10.10.5 (Yosemite) and no wish to upgrade,
so pointers on where to get proper Xcode, Command line tools etc. would 
help.




It'd be good to file a bug report for it, or at least mention where it
fails.


Here are the details and errors for two builds, 1) with GCC/LLVM 
(/Developer/usr/bin/cc) and 2) with LLVM/CLANG (/usr/bin/cc).


Short:
1) /Developer/usr/bin/cc:
   error: 'LONG_MIN' undeclared
   in tools/binutils

2) /usr/bin/cc:
   Undefined symbols for architecture x86_64: "_iconv"
   in external/gpl3/gcc/usr.bin/backend


Long:

1) /Developer/usr/bin/cc: error: 'LONG_MIN' undeclared

===> build.sh command:./build.sh -U -r -X ../xsrc-current -x -m amd64 
-T tooldir.Darwin -O obj.amd64-Darwin-XXX -D destdir.amd64 -R 
release.amd64 -V HOST_CC=/Developer/usr/bin/cc -V 
HOST_CXX=/Developer/usr/bin/c++ release

...
dependall ===> tools/binutils
...
/Developer/usr/bin/cc -c -DHAVE_CONFIG_H -O -O2 -no-cpp-precomp  -I. 
-I/Users/feyrer/work/NetBSD/cvs/src-current/tools/binutils/../../external/gpl3/binutils/dist/libiberty/../include 
-W -Wall -W write-strings -Wc++-compat -Wstrict-prototypes -pedantic  -D_GNU_SOURCE 
/Users/feyrer/work/NetBSD/cvs/src-current/tools/binutils/../../external/gpl3/binutils/dist/libiberty/fibheap.c 
-o ./fibheap.o

couldn't understand kern.osversion `14.5.0'
/Users/feyrer/work/NetBSD/cvs/src-current/tools/binutils/../../external/gpl3/binutils/dist/libiber
ty/fibheap.c: In function 'fibheap_replace_key_data':
/Users/feyrer/work/NetBSD/cvs/src-current/tools/binutils/../../external/gpl3/binutils/dist/libiber
ty/fibheap.c:220: error: 'LONG_MIN' undeclared (first use in this function)
/Users/feyrer/work/NetBSD/cvs/src-current/tools/binutils/../../external/gpl3/binutils/dist/libiber
ty/fibheap.c:220: error: (Each undeclared identifier is reported only once
/Users/feyrer/work/NetBSD/cvs/src-current/tools/binutils/../../external/gpl3/binutils/dist/libiber
ty/fibheap.c:220: error: for each function it appears in.)
/Users/feyrer/work/NetBSD/cvs/src-current/tools/binutils/../../external/gpl3/binutils/dist/libiber
ty/fibheap.c: In function 'fibheap_delete_node':
/Users/feyrer/work/NetBSD/cvs/src-current/tools/binutils/../../external/gpl3/binutils/dist/libiber
ty/fibheap.c:261: error: 'LONG_MIN' undeclared (first use in this function)
*** Failed target:  ./fibheap.o


2) /usr/bin/cc:

===> build.sh command:./build.sh -U -r -X ../xsrc-current -x -m amd64 
-T tooldir.Darwin -O obj.amd64-Darwin-XXX -D destdir.amd64 -R release.amd64 -V HOST_CC=/usr/bin/cc 
-V HOST_CXX=/usr/bin/g++ release

...
dependall ===> external/gpl3/gcc/usr.bin/backend
...
#  link  backend/genmatch
/usr/bin/g++ -O 
-I/Users/feyrer/work/NetBSD/cvs/src-current/obj.amd64-Darwin-XXX/external/gpl3/gcc
/usr.bin/host-libiberty/libiberty -I. 
-I/Users/feyrer/work/NetBSD/cvs/src-current/external/gpl3/gc
c/usr.bin/backend/../gcc/arch/x86_64 -DIN_GCC -DHAVE_CONFIG_H 
-I/Users/feyrer/work/NetBSD/cvs/src-
current/external/gpl3/gcc/dist/gcc 
-I/Users/feyrer/work/NetBSD/cvs/src-current/external/gpl3/gcc/d
ist/gcc/. 
-I/Users/feyrer/work/NetBSD/cvs/src-current/external/gpl3/gcc/dist/gcc/../include 
-I/Use
rs/feyrer/work/NetBSD/cvs/src-current/external/gpl3/gcc/dist/gcc/../libcpp/include 
-I/Users/feyrer
/work/NetBSD/cvs/src-current/external/gpl3/gcc/dist/gcc/../libdecnumber 
-I/Users/feyrer/work/NetBS
D/cvs/src-current/external/gpl3/gcc/dist/gcc/../libdecnumber/dpd 
-I/Users/feyrer/work/NetBSD/cvs/s
rc-current/external/gpl3/gcc/dist/gcc/../libbacktrace -DGENERATOR_FILE 
-I/Users/feyrer/work/NetBSD
/cvs/src-current/external/gpl3/gcc/usr.bin/backend/..  -o genmatch 
genmatch.lo build-errors.lo bui
ld-vec.lo build-hash-table.lo 
-L/Users/feyrer/work/NetBSD/cvs/src-current/tooldir.Darwin/lib -lnbc
ompat 
/Users/feyrer/work/NetBSD/cvs/src-current/obj.amd64-Darwin-XXX/external/gpl3/gcc/usr.bin/hos
t-libcpp/libcpp/libcpp.a 
/Users/feyrer/work/NetBSD/cvs/src-current/obj.amd64-Darwin-XXX/external/g

pl3/gcc/usr.bin/host-libiberty/libiberty/libiberty.a
Undefined symbols for architecture x86_64:
  "_iconv", referenced from:
  convert_using_iconv(void*, unsigned char const*, unsigned long, 
_cpp_strbuf*) in libcpp.a(ch

arset.o)
 (maybe you meant: __Z14cpp_init_iconvP10cpp_reader, 
__cpp_destroy_iconv )

  "_iconv_close", referenced from:
  __cpp_destroy_iconv in libcpp.a(charset.o)
  __cpp_convert_input in libcpp.a(charset.o)
  "_iconv_open", referenced from:
  init_iconv_desc(cpp_reader*, char const*, char const*) in 
libcpp.a(charset.o)

ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Re: Building on OS X - how?

[coypu]

There shouldn't be anything special about building from OS X.
You just ran into a setup that happens to not work with it.

It'd be good to file a bug report for it, or at least mention where it
fails.