[Bug 266900] WITHOUT_MACHDEP_OPTIMIZATION build option fails on error: undefined symbol: __stpcpy

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266900

            Bug ID: 266900
           Summary: WITHOUT_MACHDEP_OPTIMIZATION build option fails on
                    error: undefined symbol: __stpcpy
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: bin
          Assignee: bugs@FreeBSD.org
          Reporter: editor@callfortesting.org

Created attachment 237151
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=237151&action=edit
src.conf that will reproduce the issue

Context: FreeBSD buildworld will succeed with all WITHOUT_* build options
enable, minus WITHOUT_AUTO_OBJ WITHOUT_UNIFIED_OBJDIR WITHOUT_INSTALLLIB. This
provides a far more efficient exercise of the the available build options than
the /usr/src/tools/tools/build_option_survey

This commit and review causes the WITHOUT_MACHDEP_OPTIMIZATION build option to
fail on "error: undefined symbol: __stpcpy":

https://reviews.freebsd.org/D36463

https://cgit.freebsd.org/src/commit/?id=c65e42dbde4198ce46aef7ddac061390abe672dc

Xin LI is aware of this issue and has kindly offered this clarification and
requested this ticket:

"The build broke because some MD files were used, and some were not.  For
strcpy()'s case, on amd64, it's a wrapper around the MD stpcpy() and naturally
it calls __stpcpy() which itself gets (correctly) excluded.

The MD C source was used because this line which is common for Makefile.inc's
in the subdirectories in libc:

.PATH: ${LIBC_SRCTOP}/${LIBC_ARCH}/string ${LIBC_SRCTOP}/string

which basically means, if you have foo.c in the MD directory, it's used in
favor of the MI version.

So these need to be fixed for ${MK_MACHDEP_OPTIMIZATIONS} == no case too.

I think this could have been avoided if the initial testing was done with two
clean buildworld builds with and without the new option; for build
infrastructure changes like this, I'd recommend doing full universe runs
locally or on universe14{a,b} at cluster in the future before pushing."

Thank you Xin for looking into this!

Attachments: a src.conf that reproduces the issue on main and stable/13

-- 
You are receiving this mail because:
You are the assignee for the bug.