Greetings, We are following Rich Lowe's advice and managing to build on a 133 system, and now managing to update to these new bits.
We are getting some rather scary looking build warnings ( tons of these ) in the "build noise" section possibly related to the obsolete closed bins we are using. ( Complaints about closed binaries not being properly unpacked, needing to build libc_i18n.a, a whole bunch of java classes being unchecked or unsafe, Dmake failing for a whole bunch of commanss (such as agents, aux, chown,cmd-inet,crle ...and so on) More disturbing are things like: make: Warning: Target `libc.so.1' not remade because of errors < dmake: Warning: Target `libc_hwcap1.so.1' not remade because of errors < dmake: Warning: Target `libc_hwcap2.so.1' not remade because of errors < dmake: Warning: Target `libc_hwcap3.so.1' not remade because of errors 259,349d162 < ld: fatal: file /tank/nola/gb_134.0/usr/src/common/mapfiles/gen/amd64_cc_map.noexeglobs: stat failed: No such file or directory < ld: fatal: file /tank/nola/gb_134.0/usr/src/common/mapfiles/gen/i386_cc_map.noexeglobs: stat failed: No such file or directory < ld: fatal: file processing errors. No output written to bootconfchk < ld: fatal: file processing errors. No output written to cpu.so < ld: fatal: file processing errors. No output written to cpumem-retire.so < ld: fatal: file processing errors. No output written to dev.so < ld: fatal: file processing errors. No output written to devfsadm < ld: fatal: file processing errors. No output written to dhcpagent On one hand, these show up in the build noise section, and probably closed-bins related. But they appear to be build and link errors..can we just ignore these? My understanding was, that the osnet incorporation provides (almost) everything that the build is dependent on. ( ie. "build dependencies") Can someone explain what other components impact the build? Obviously -SunStudio ( 12u1 may be missing some patches, we had to fall back to an earlier version) -Closed bins ( all we have available is in-ips 132. The snv closed bins do not seem to work) -Build tools. ( we are using the tools.scripts are as the first search location in PATH) Looks like some binaries are accessed from the build machine's /opt/onbld area Is this the reason of the build machine OS dependency? -Maybe some OS header files from /usr/include? -Maybe some libraries from the build system? > Automatic dependency generation during the build used to output > duplicate dependencies. This was fixed in the pkg gate in build 133, > prior to this fix on_ips used to run a small script to remove these > duplicates. This script stopped being run after 133 became available, > since it was no longer necessary as a workaround. What matters is the > build running on the host on which your package repository was built, > not the version being upgraded or the version being upgraded to. > > -- Rich Steve Gonczi [email protected] skype:steve_gonczi_work _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
