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