Re: Help with pkgsrc configuration

Bob McGowan <[email protected]> Thu, 31 Dec 2020 19:40:17 -0800
Newsgroups gmane.os.netbsd.ports.macppc
Message-ID <[email protected]>
On 12/31/20 5:49 PM, Greg Troxel wrote:
> Bob McGowan <[email protected]> writes:
>
>> Well, this one is beyond my skill level, it seems.
>>
>> I'm trying to build samba4 to run on my Mac G3.  My build system is
>> Debian Gnu/Linux 10.7, set up per the instructions in
>> pkgsrc/doc/HOWTO-use-crosscompile.
>>
>> When samba4 failed, I tried some other packages, all of which fail at
>> some point.  But some cross compiles appear to work, for example in
>> pkgsrc/packages.powerpc/All there is a libhfs-3.2.6nb2.tgz file, after
>> running 'bmake package' in pkgsrc/sysutils/hfsutils.
> While pkgsrc has some cross compilation support, two important things to
> note:
>
>    not many people use it and I would not call it well tested
>
>    it is more or less necessary for the upstream packages to have cross
>    support, and many don't.
>
>> However, most of the compiles (hfsutils in this case) fail quickly
>> with link errors such as:
>>
>> /usr/bin/ld:
>> /home/rmcgowan/src/netbsd/usr/pkgsrc/sysutils/hfsutils/work.powerpc/.buildlink/lib/libhfs.a(volume.o):
>> \
>>          in function `v_readvbm':
>> (.text+0x62a): undefined reference to `__errno'
>> /usr/bin/ld: (.text+0x642): undefined reference to `__errno'
>> /usr/bin/ld:
>> /home/rmcgowan/src/netbsd/usr/pkgsrc/sysutils/hfsutils/work.powerpc/.buildlink/lib/libhfs.a(volume.o):
>> \
>>          in function `v_getthread':
>>
>> Working through the file I captured from the bmake, I found for
>> hfsutils, the following items were the primary errors:
>>
>>      undefined reference to `__ctime50'
>>      undefined reference to `__errno'
>>      undefined reference to `__gmtime50'
>>      undefined reference to `__locatime50'
>>      undefined reference to `__mktime50'
>>      undefined reference to `__sF'
>>      undefined reference to `__srget'
>>      undefined reference to `__stat50'
>>      undefined reference to `__swbuf'
>>      undefined reference to `_ctype_tab_'
>>      undefined reference to `_tolower_tab_'
> Smells like linking with the wrong libc which doesn't have the compat
> symbols.  Perhaps host/target confusion?
>
>> In a few other cases, it is a missing include file.  For example, I
>> tried building libgee, and it quit with the following:
>>
>> /usr/include/x86_64-linux-gnu/c++/8/bits/os_defines.h:39:10: fatal
>> error: features.h: No such file or directory
>>   #include <features.h>
>>                ^~~~~~~~~~~~
>>
>> Note that os_defines.h is found in the system include
>> /usr/include/... but that features.h, which is present in the system
>> directory /usr/include, isn't found.
>>
>> Based on the above I have to assume I've missed something in the
>> configuration or setup of pkgsrc for cross compiling.
> Generally, cross builds need to reference includes from a cross destdir
> which contains the base system for the target and the installed packages
> that the package depends on.   So it's an error for most builds to look
> in /usr/include on the host.
>
> However, some build systems need to build a program that runs on the
> host, to do a build step.
>
> So overall, this is pretty difficult.
>
> I would suggest you explore a few alternative approaches:
>
>    Configure and use ccache.  That will help when you have to do things
>    again.
>
>    do the builds on the G3.  Set up distcc, and configure the Debian
>    system as a remote builder with the NetBSD/macppc toolchain.
>
>    Think carefully about MAKE_JOBS.   Note that with distcc there is
>    latency from remote, so with a beefy x86 compiler you might want 8.
>    However, things other than gcc get done in parallel, and the G3 might
>    run out of RAM so that is probably on balance not wise.   I would
>    wildy guess 2 to 4 is about right, but I don't actually know so don't
>    take that seriously.
>
>    Set up a macppc emulator, which might be faster and/or have more
>    memory than your actual computer.  Even if it takes several weeks to
>    build, that is very likely faster than figuring out and fixing cross
>    build issues.  ccache and distcc make sense with an emulated system
>    too.
>
Greg,

Thanks for the suggestion.  I will see what I can do with an emulator.  
My Mac doesn't currently have enough memory to compile much of anything, 
which is why I was going for the cross-compile method.

Bob