Opened 6 months ago
Last modified 4 weeks ago
#69990 new defect
cmake-bootstrap fails to link on 10.4 due to changes in ncurses 6.5.0
Reported by: | miles-martin-66 (Miles Martin) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | tiger | Cc: | |
Port: | cmake-bootstrap |
Description (last modified by kencu (Ken))
iMac G3 400Mhz, 1 G ram, OSX 10.4.11, Macports V2.9.3 (self update to latest), Xcode 2.5
Im following these instruction to build a usable browser on this old mac. https://github.com/classilla/tenfourfox/wiki/HowToBuildFPR
I have managed to use "sudo port install" to build and install almost every package required as a pre requisite except any that have cmake-bootstrap as a dependancy. I have run 'sudo port clean' and following that attempted to install only cmake-bootsrap with no success. I have attached the main.log file which indicates that linking is failing (excerpt below) but I don't see why. I have investigated as far as my knowledge and experience can take me.
:info:build [ 94%] Building CXX object Source/CMakeFiles/ccmake.dir/CursesDialog/ccmake.cxx.o :info:build cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake-bootstrap/cmake-bootstrap/work/cmake-3.9.6/Source && /opt/local/bin/g++-apple-4.2 -DCMAKE_BUILD_WITH_CMAKE -DCURL_STATICLIB -DLIBARCHIVE_STATIC -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake-bootstrap/cmake-bootstrap/work/cmake-3.9.6/Utilities -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake-bootstrap/cmake-bootstrap/work/cmake-3.9.6/Source -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake-bootstrap/cmake-bootstrap/work/cmake-3.9.6/Source/LexerParser -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake-bootstrap/cmake-bootstrap/work/cmake-3.9.6/Utilities/cmcompress -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake-bootstrap/cmake-bootstrap/work/cmake-3.9.6/Source/CTest -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake-bootstrap/cmake-bootstrap/work/cmake-3.9.6/Source/CPack -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake-bootstrap/cmake-bootstrap/work/cmake-3.9.6/Source/CursesDialog/form -pipe -Os -arch ppc -mmacosx-version-min=10.4 -o CMakeFiles/ccmake.dir/CursesDialog/ccmake.cxx.o -c /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake-bootstrap/cmake-bootstrap/work/cmake-3.9.6/Source/CursesDialog/ccmake.cxx :info:build [ 94%] Linking CXX executable ../bin/ccmake :info:build cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake-bootstrap/cmake-bootstrap/work/cmake-3.9.6/Source && /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake-bootstrap/cmake-bootstrap/work/cmake-3.9.6/Bootstrap.cmk/cmake -E cmake_link_script CMakeFiles/ccmake.dir/link.txt --verbose=ON :info:build /opt/local/bin/g++-apple-4.2 -pipe -Os -arch ppc -mmacosx-version-min=10.4 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/opt/local/libexec/cmake-bootstrap/lib -Wl,-headerpad_max_install_names -arch ppc CMakeFiles/ccmake.dir/CursesDialog/cmCursesOptionsWidget.cxx.o CMakeFiles/ccmake.dir/CursesDialog/cmCursesBoolWidget.cxx.o CMakeFiles/ccmake.dir/CursesDialog/cmCursesCacheEntryComposite.cxx.o CMakeFiles/ccmake.dir/CursesDialog/cmCursesDummyWidget.cxx.o CMakeFiles/ccmake.dir/CursesDialog/cmCursesFilePathWidget.cxx.o CMakeFiles/ccmake.dir/CursesDialog/cmCursesForm.cxx.o CMakeFiles/ccmake.dir/CursesDialog/cmCursesLabelWidget.cxx.o CMakeFiles/ccmake.dir/CursesDialog/cmCursesLongMessageForm.cxx.o CMakeFiles/ccmake.dir/CursesDialog/cmCursesMainForm.cxx.o CMakeFiles/ccmake.dir/CursesDialog/cmCursesPathWidget.cxx.o CMakeFiles/ccmake.dir/CursesDialog/cmCursesStringWidget.cxx.o CMakeFiles/ccmake.dir/CursesDialog/cmCursesWidget.cxx.o CMakeFiles/ccmake.dir/CursesDialog/ccmake.cxx.o -o ../bin/ccmake libCMakeLib.a CursesDialog/form/libcmForm.a kwsys/libcmsys.a ../Utilities/cmexpat/libcmexpat.a ../Utilities/cmlibarchive/libarchive/libcmlibarchive.a ../Utilities/cmliblzma/libcmliblzma.a -framework CoreServices ../Utilities/cmbzip2/libcmbzip2.a ../Utilities/cmcompress/libcmcompress.a ../Utilities/cmcurl/lib/libcmcurl.a ../Utilities/cmzlib/libcmzlib.a ../Utilities/cmjsoncpp/libcmjsoncpp.a ../Utilities/cmlibrhash/libcmlibrhash.a -framework CoreFoundation /usr/lib/libncurses.dylib :info:build ld: warning: directory '/opt/local/libexec/cmake-bootstrap/lib' following -L not found :info:build ld: warning: object file compiled with -mlong-branch which is no longer needed. To remove this warning, recompile without -mlong-branch: /opt/local/lib/apple-gcc42/gcc/powerpc-apple-darwin8/4.2.1/crt3.o :info:build Undefined symbols: :info:build "_getattrs", referenced from: :info:build _Display_Or_Erase_Field in libcmForm.a(frm_driver.c.o) :info:build "_getmaxx", referenced from: :info:build cmCursesLongMessageForm::PrintKeys() in cmCursesLongMessageForm.cxx.o :info:build cmCursesLongMessageForm::Render(int, int, int, int)in cmCursesLongMessageForm.cxx.o :info:build cmCursesLongMessageForm::UpdateStatusBar() in cmCursesLongMessageForm.cxx.o :info:build cmCursesMainForm::PrintKeys(int) in cmCursesMainForm.cxx.o :info:build cmCursesMainForm::Generate() in cmCursesMainForm.cxx.o :info:build cmCursesMainForm::Generate() in cmCursesMainForm.cxx.o :info:build cmCursesMainForm::Configure(int) in cmCursesMainForm.cxx.o :info:build cmCursesMainForm::Configure(int) in cmCursesMainForm.cxx.o :info:build cmCursesMainForm::HandleInput() in cmCursesMainForm.cxx.o :info:build cmCursesMainForm::HandleInput() in cmCursesMainForm.cxx.o :info:build cmCursesMainForm::HandleInput() in cmCursesMainForm.cxx.o :info:build cmCursesMainForm::HandleInput() in cmCursesMainForm.cxx.o :info:build cmCursesMainForm::HandleInput() in cmCursesMainForm.cxx.o :info:build cmCursesMainForm::UpdateStatusBar(char const*)in cmCursesMainForm.cxx.o :info:build cmCursesStringWidget::PrintKeys() in cmCursesStringWidget.cxx.o :info:build cmCursesStringWidget::HandleInput(int&, cmCursesMainForm*, _win_st*) in cmCursesStringWidget.cxx.o :info:build _onsig in ccmake.cxx.o :info:build _main in ccmake.cxx.o :info:build _post_form in libcmForm.a(frm_post.c.o) :info:build _Window_To_Buffer in libcmForm.a(frm_driver.c.o) :info:build _Buffer_To_Window in libcmForm.a(frm_driver.c.o) :info:build "_getmaxy", referenced from: :info:build cmCursesOptionsWidget::HandleInput(int&, cmCursesMainForm*, _win_st*) in cmCursesOptionsWidget.cxx.o :info:build cmCursesOptionsWidget::HandleInput(int&, cmCursesMainForm*, _win_st*) in cmCursesOptionsWidget.cxx.o :info:build cmCursesBoolWidget::HandleInput(int&, cmCursesMainForm*, _win_st*) in cmCursesBoolWidget.cxx.o :info:build cmCursesLongMessageForm::PrintKeys() in cmCursesLongMessageForm.cxx.o :info:build cmCursesLongMessageForm::HandleInput() in cmCursesLongMessageForm.cxx.o :info:build cmCursesLongMessageForm::Render(int, int, int, int)in cmCursesLongMessageForm.cxx.o :info:build cmCursesLongMessageForm::Render(int, int, int, int)in cmCursesLongMessageForm.cxx.o :info:build cmCursesLongMessageForm::UpdateStatusBar() in cmCursesLongMessageForm.cxx.o :info:build cmCursesMainForm::PrintKeys(int) in cmCursesMainForm.cxx.o :info:build cmCursesMainForm::UpdateProgress(char const*, float, void*)in cmCursesMainForm.cxx.o :info:build cmCursesMainForm::Generate() in cmCursesMainForm.cxx.o :info:build cmCursesMainForm::Generate() in cmCursesMainForm.cxx.o :info:build cmCursesMainForm::Generate() in cmCursesMainForm.cxx.o :info:build cmCursesMainForm::Configure(int) in cmCursesMainForm.cxx.o :info:build cmCursesMainForm::Configure(int) in cmCursesMainForm.cxx.o :info:build cmCursesMainForm::Configure(int) in cmCursesMainForm.cxx.o :info:build cmCursesMainForm::HandleInput() in cmCursesMainForm.cxx.o :info:build cmCursesMainForm::HandleInput() in cmCursesMainForm.cxx.o :info:build cmCursesMainForm::HandleInput() in cmCursesMainForm.cxx.o :info:build cmCursesMainForm::HandleInput() in cmCursesMainForm.cxx.o :info:build cmCursesMainForm::HandleInput() in cmCursesMainForm.cxx.o :info:build cmCursesMainForm::HandleInput() in cmCursesMainForm.cxx.o :info:build cmCursesMainForm::HandleInput() in cmCursesMainForm.cxx.o :info:build cmCursesMainForm::HandleInput() in cmCursesMainForm.cxx.o :info:build cmCursesMainForm::UpdateStatusBar(char const*)in cmCursesMainForm.cxx.o :info:build cmCursesMainForm::UpdateStatusBar(char const*)in cmCursesMainForm.cxx.o :info:build cmCursesMainForm::Render(int, int, int, int)in cmCursesMainForm.cxx.o :info:build cmCursesPathWidget::OnTab(cmCursesMainForm*, _win_st*) in cmCursesPathWidget.cxx.o :info:build cmCursesStringWidget::PrintKeys() in cmCursesStringWidget.cxx.o :info:build cmCursesStringWidget::HandleInput(int&, cmCursesMainForm*, _win_st*) in cmCursesStringWidget.cxx.o :info:build cmCursesStringWidget::HandleInput(int&, cmCursesMainForm*, _win_st*) in cmCursesStringWidget.cxx.o :info:build cmCursesStringWidget::HandleInput(int&, cmCursesMainForm*, _win_st*) in cmCursesStringWidget.cxx.o :info:build _onsig in ccmake.cxx.o :info:build _main in ccmake.cxx.o :info:build _main in ccmake.cxx.o :info:build _main in ccmake.cxx.o :info:build _post_form in libcmForm.a(frm_post.c.o) :info:build _Window_To_Buffer in libcmForm.a(frm_driver.c.o) :info:build _Buffer_To_Window in libcmForm.a(frm_driver.c.o) :info:build _Field_Grown in libcmForm.a(frm_driver.c.o) :info:build __nc_Refresh_Current_Field in libcmForm.a(frm_driver.c.o) :info:build __nc_Refresh_Current_Field in libcmForm.a(frm_driver.c.o) :info:build __nc_Refresh_Current_Field in libcmForm.a(frm_driver.c.o) :info:build __nc_Set_Current_Field in libcmForm.a(frm_driver.c.o) :info:build ld: symbol(s) not found :info:build collect2: ld returned 1 exit status :info:build make[2]: *** [bin/ccmake] Error 1 :info:build make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake-bootstrap/cmake-bootstrap/work/cmake-3.9.6' :info:build make[1]: *** [Source/CMakeFiles/ccmake.dir/all] Error 2 :info:build make[1]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake-bootstrap/cmake-bootstrap/work/cmake-3.9.6' :info:build make: *** [all] Error 2 :info:build make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake-bootstrap/cmake-bootstrap/work/cmake-3.9.6' :info:build Command failed: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake-bootstrap/cmake-bootstrap/work/cmake-3.9.6" && /usr/bin/make -w all VERBOSE=ON :info:build Exit code: 2 :error:build Failed to build cmake-bootstrap: command execution failed :debug:build Error code: CHILDSTATUS 1373 2 :debug:build Backtrace: command execution failed :debug:build while executing :debug:build "system {*}$notty {*}$callback {*}$nice $fullcmdstring" :debug:build invoked from within :debug:build "command_exec -callback portprogress::target_progress_callback build" :debug:build (procedure "portbuild::build_main" line 10) :debug:build invoked from within :debug:build "$procedure $targetname" :error:build See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake-bootstrap/cmake-bootstrap/main.log for details.
Attachments (3)
Change History (31)
Changed 6 months ago by miles-martin-66 (Miles Martin)
Attachment: | cmake-bootstrap-main.log added |
---|
comment:1 Changed 6 months ago by kencu (Ken)
Description: | modified (diff) |
---|
comment:2 Changed 6 months ago by kencu (Ken)
let me see if this port still builds on Tiger ppc for me…
comment:3 Changed 6 months ago by kencu (Ken)
although this did build for me recently:
$ port -v installed cmake-bootstrap The following ports are currently installed: cmake-bootstrap @3.9.6_0 (active) requested_variants='' platform='darwin 8' archs='ppc' date='2023-11-18T11:16:51-0800'
when I try to rebuild it now, I get the same error as you.
I don't presently know what has changed to cause this error. Perhaps we can sort it out.
comment:4 Changed 6 months ago by jmroot (Joshua Root)
Keywords: | tiger added |
---|---|
Port: | cmake-bootstrap added |
Summary: | Linking of cmake-bootsrap fails → cmake-bootstrap fails to link on 10.4 |
comment:5 Changed 6 months ago by ryandesign (Ryan Carsten Schmidt)
getattrs
, getmaxx
and getmaxy
are part of ncurses. cmake code calls gettattrs
directly once. It doesn't call getmaxx
or getmaxy
directly; it calls getmaxyx
which is an ncurses macro that expands to getmaxx
and getmaxy
. cmake-bootstrap is supposed to have no dependencies, so it's supposed to be using the older ncurses that comes with macOS rather than the newer ncurses in MacPorts. Maybe having MacPorts ncurses installed while building cmake-bootstrap is causing this problem. I can see from the log that it is using the macOS ncurses library, but maybe it is inadvertently using the MacPorts ncurses headers; such a mismatch could cause problems.
comment:6 Changed 6 months ago by ryandesign (Ryan Carsten Schmidt)
However I don't see any evidence in the log that that is happening. I don't, for example, see -I/opt/local/include
anywhere. The Portfile goes to some lengths to ensure that MacPorts headers and libraries will not be used—by clearing compiler.cpath
and compiler.library_path
and overriding prefix
.
If you want to test if MacPorts ncurses could be interfering, try this:
sudo port clean cmake-bootstrap sudo port -f deactivate ncurses sudo port -s install cmake-bootstrap
Later you can sudo port activate ncurses
again.
comment:7 Changed 6 months ago by ryandesign (Ryan Carsten Schmidt)
I do see from the log that MacPorts ar
and ranlib
are being used. If you want to test if those are interfering, do the same as above, except that the port to deactivate before and reactivate after is cctools.
It would help to do these tests one at a time so that we know which of the two ports, if any, are causing the problem.
comment:8 Changed 6 months ago by kencu (Ken)
Although I don't know why as yet, when I downgrade ncurses to 6.4.1, cmake-bootstrap builds through.
Changed 6 months ago by kencu (Ken)
cmake-bootstrap-main-with-ncurses-6.4.1.log
comment:9 Changed 6 months ago by kencu (Ken)
I attached the log from the successful build of cmake-bootstrap on Tiger with ncurses 6.4.1 instead of 6.5 active.
comment:10 Changed 6 months ago by kencu (Ken)
the difference seems to be that in ncurses 6.4.1 and earlier, NCURSES_OPAQUE
is 0, whereas in ncurses 6.5.0, it is "1".
and in curses.h, this appears to change whether these functions (_getattrs
, etc) are visible and defined or not.
comment:11 Changed 6 months ago by kencu (Ken)
Summary: | cmake-bootstrap fails to link on 10.4 → cmake-bootstrap fails to link on 10.4 due to changes in ncurses 6.5.0 |
---|
comment:12 Changed 6 months ago by ryandesign (Ryan Carsten Schmidt)
Can we work out why or how cmake-bootstrap is using MacPorts ncurses and how to prevent it? Worst case we can use the conflicts_build portgroup.
comment:13 follow-up: 15 Changed 6 months ago by kencu (Ken)
we should do that, yes. conflicts_build with ncurses gets ugly fast, though, I found. tons of stuff depends on it.
it looks like the default for NCURSES_OPAQUE
toggling to ON in the new ncurses is likely going to cause troubles elsewhere, though.
there are lots of reports about this on the net.
you can set
#define NCURSES_OPAQUE 0
to force the old behaviour.
comment:14 follow-up: 17 Changed 6 months ago by miles-martin-66 (Miles Martin)
Thanks so much for looking at this!
I gather that, as a workaround, should I set #define NCURSES_OPAQUE 0
?
If so, and forgive the possible silly question, but where would I set it?
comment:15 Changed 6 months ago by ryandesign (Ryan Carsten Schmidt)
Replying to kencu:
we should do that, yes. conflicts_build with ncurses gets ugly fast, though, I found. tons of stuff depends on it.
Ok but we're not talking about tons of stuff; we're talking about cmake-bootstrap only. Users wishing to install that can deactivate ncurses first and reactivate it later. Users receiving a binary of cmake-bootstrap won't even have to do that.
it looks like the default for
NCURSES_OPAQUE
toggling to ON in the new ncurses is likely going to cause troubles elsewhere, though.
Ok but that's not a problem we need to solve in this ticket. In this ticket, our only objective is to ensure that cmake-bootstrap doesn't try to use MacPorts ncurses, or any other MacPorts ports.
Also, I don't have any problem building cmake-bootstrap on macOS 12 even when I do not use trace mode and MacPorts ncurses 6.5 is installed.
comment:16 follow-up: 19 Changed 6 months ago by kencu (Ken)
I wonder if there might be some ncurses-config binary that is being used, and is finding the macports version on the PATH…
comment:17 follow-up: 18 Changed 6 months ago by kencu (Ken)
Replying to miles-martin-66:
Thanks so much for looking at this!
I gather that, as a workaround, should I set
#define NCURSES_OPAQUE 0
?If so, and forgive the possible silly question, but where would I set it?
I'm trying a few things.
For the moment, if you do what Ryan suggested:
sudo port -f deactivate ncurses sudo port -v install cmake-bootstrap
Ignore any failures that happen after installation on rev-upgrade --- there will probably be a great many of them.
Then:
sudo port -v install ncurses
and now rev-upgrade will run again and should be clean this time
you should get cmake-bootstrap installed at least.
comment:18 Changed 6 months ago by ryandesign (Ryan Carsten Schmidt)
Replying to kencu:
Ignore any failures that happen after installation on rev-upgrade --- there will probably be a great many of them.
Well, just disable rev-upgrade by passing the --no-rev-upgrade
flag.
comment:19 Changed 6 months ago by ryandesign (Ryan Carsten Schmidt)
Replying to kencu:
I wonder if there might be some ncurses-config binary that is being used, and is finding the macports version on the PATH…
When I build cmake-bootstrap in trace mode on macOS 12, there are whole lot of things that it is looking for and might use if trace mode were off:
---> Configuring cmake-bootstrap Warning: The following existing files were hidden from the build system by trace mode: /opt /opt/local /opt/local/bin/ar /opt/local/bin/ccache /opt/local/bin/ctest /opt/local/bin/cvs /opt/local/bin/fakeroot /opt/local/bin/git /opt/local/bin/gmake /opt/local/bin/gunzip /opt/local/bin/gzip /opt/local/bin/hg /opt/local/bin/ld /opt/local/bin/nm /opt/local/bin/objdump /opt/local/bin/pkg-config /opt/local/bin/ranlib /opt/local/bin/strip /opt/local/bin/svn /opt/local/include/atk-1.0/atk/atk.h /opt/local/include/cairo/cairo.h /opt/local/include/fontconfig/fontconfig.h /opt/local/include/freetype2/freetype/config/ftheader.h /opt/local/include/freetype2/ft2build.h /opt/local/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixbuf.h /opt/local/include/glib-2.0/glib-object.h /opt/local/include/glib-2.0/glib.h /opt/local/include/gtk-2.0/gdk/gdk.h /opt/local/include/gtk-2.0/gtk/gtk.h /opt/local/include/pango-1.0/pango/pango.h /opt/local/lib/cmake/Qt5Core/Qt5CoreConfig.cmake /opt/local/lib/cmake/Qt5Widgets/Qt5WidgetsConfig.cmake /opt/local/lib/glib-2.0/include/glibconfig.h /opt/local/lib/gtk-2.0/include/gdkconfig.h /opt/local/var /opt/local/var/macports /opt/local/var/macports/build /opt/local/var/macports/build/_Volumes_Shared_macports-ports_devel_cmake-bootstrap /opt/local/var/macports/build/_Volumes_Shared_macports-ports_devel_cmake-bootstrap/cmake-bootstrap /private/var/select/sh /usr/X11R6 /usr/X11R6/include/cairo/cairo.h /usr/X11R6/include/fontconfig/fontconfig.h /usr/X11R6/include/freetype2/freetype/config/ftheader.h /usr/X11R6/include/freetype2/ft2build.h
I'm surprised it's doing this. We're using the --no-system-libs
configure flag which is defined as "use all cmake-provided third-party libraries".
There are no ncurses files among the above but I wanted to see if ncurses files would be found if I added the pkgconfig port to depends_build, but even when I did this, trace mode hid the pkg-config program; I'm not sure why it did that.
comment:20 Changed 6 months ago by ryandesign (Ryan Carsten Schmidt)
The compiler being used is g++-apple-4.2, which is the Apple fork of g++ 4.2 as installed by the MacPorts apple-gcc42 port. Could we have patched that compiler to have /opt/local/include in its default include paths? If you run this, it should show what the default include paths are:
g++-apple-4.2 -x c++ -E - -v </dev/null
Maybe it's nothing but I noticed that to build the bootstrap cmake it invokes the compiler with -Qstd=c++14
which is weird because
- the reason this port exists is it's the last version of cmake that doesn't require c++11 so what's with the c++14 reference?
- this compiler doesn't support c++14 (nor c++11)
-Qstd=c++14
isn't how you enable c++14 on any compiler I know about (-std=c++14
is)
comment:21 follow-up: 28 Changed 6 months ago by kencu (Ken)
I think you've hit on the issue. Indeed, /opt/local/include comes ahead of /usr/include on the default include path for this compiler.
Well done!
$ g++-apple-4.2 -x c++ -E - -v </dev/null Using built-in specs. Target: powerpc-apple-darwin8 Configured with: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_apple-gcc42/apple-gcc42/work/objroot/src/configure --disable-checking --enable-werror --prefix=/opt/local --mandir=/opt/local/share/man --enable-languages=c,c++,objc,obj-c++ --libexecdir=/opt/local/libexec/apple-gcc42 --libdir=/opt/local/lib/apple-gcc42 --includedir=/opt/local/include/apple-gcc42 --program-suffix=-apple-4.2 --with-system-zlib --disable-nls --with-slibdir=/usr/lib --build=powerpc-apple-darwin8 --with-gxx-include-dir=/usr/include/c++/4.0.0 --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 Thread model: posix gcc version 4.2.1 (Apple Inc. build 5666) (dot 3) (MacPorts apple-gcc42 5666.3_16) /opt/local/libexec/apple-gcc42/gcc/powerpc-apple-darwin8/4.2.1/cc1plus -E -quiet -v -D__DYNAMIC__ - -fPIC -mmacosx-version-min=10.4 -D__private_extern__=extern ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/opt/local/lib/apple-gcc42/gcc/powerpc-apple-darwin8/4.2.1/../../../../powerpc-apple-darwin8/include" #include "..." search starts here: #include <...> search starts here: /usr/include/c++/4.0.0 /usr/include/c++/4.0.0/powerpc-apple-darwin8 /usr/include/c++/4.0.0/backward /opt/local/include /opt/local/lib/apple-gcc42/gcc/powerpc-apple-darwin8/4.2.1/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list. # 1 "<stdin>" # 1 "<built-in>" # 1 "<command-line>" # 1 "<stdin>"
comment:22 follow-up: 23 Changed 6 months ago by kencu (Ken)
I tried a few simple workarounds...
setting -DNCURSES_OPAQUE=0
actually doesn't work out, as the macports curses header overrides it anyway unless other, less palatable, defines are also set.
I tried forcing compiler.cpath /usr
on Tiger -- but I was both disappointed and surprised that didn't work either.
We could copy the system curses.h into a folder and set that as an include folder to be used ahead of others, but hacks like that often come back to bite you later. Still, that is on the easy side.
Or we (someone we) could figure out where ${prefix}/include
is being added to the default include path for the gcc compilers, fix that, and then revbump the compiler. I checked, and gcc7 on TIger (at least) does the same search order, and so I suspect all the gcc compilers do that -- and they should probably all not do that any longer :> Now there is a project for a hearty individual to take on.
We could also change the newer ncurses 6.5.0 to use NCURSES_OPAQUE=0
by default again, at least on systems where it is needed to be so (where the system curses library apparently doesn't have the accessor functions to make OPAQUE=1 work). That is Josh's port, and I'm not getting involved in suggesting changes to ncurses that will almost certainly get shot down anyway.
Of all these options -- I guess copying the system curses.h into a folder in the build tree and prioritizing that include folder is the easiest. Or some trickery that accomplishes the same outcome, such as adding /usr/include
to the standard include path, so it gets accessed ahead of the system include path.
comment:23 Changed 6 months ago by ryandesign (Ryan Carsten Schmidt)
Replying to kencu:
Or we (someone we) could figure out where
${prefix}/include
is being added to the default include path for the gcc compilers, fix that, and then revbump the compiler. I checked, and gcc7 on TIger (at least) does the same search order, and so I suspect all the gcc compilers do that -- and they should probably all not do that any longer :> Now there is a project for a hearty individual to take on.
This seems like the right fix. gcc12 and gcc13 on macOS 12 don't have ${prefix}/include in the include path. I haven't checked earlier ones.
I thought I remembered that we had modified the clang compilers to have ${prefix}/include in the include path too, but upon inspection that doesn't seem to be the case.
comment:24 Changed 6 months ago by kencu (Ken)
It’s probably this option: with-local-prefix
that we should not be setting.
although it is being used on every gcc build in MacPorts, so why you aren’t seeing it used in gcc12 and gcc13 is a question to ponder.
comment:25 Changed 6 months ago by ryandesign (Ryan Carsten Schmidt)
That flag does seem related. We first added --with-local-prefix
to gcc33 19 years ago to prevent the compiler from searching in /usr/local/include and have been adding it to every gcc port since then. The documentation for this flag says that it causes the given prefix to be searched instead of /usr/local. And although we do sometimes encounter problems building ports when users have headers in /usr/local/include, disabling this feature is probably wrong. After all, the user may want to use the compiler outside of MacPorts and may expect it to find things in /usr/local as compilers typically do.
Notably, the apple-gcc40 and apple-gcc42 ports do not use this flag, yet we're seeing apple-gcc42 exhibit the behavior.
With gcc12 and gcc13 on macOS 12 I see neither /usr/local/include nor /opt/local/include in the list; I would have expected to see one or the other.
comment:26 Changed 6 months ago by kencu (Ken)
while this is all getting sorted out for the formal big fix, one simple fix is to disable the failing curses gui of cmake-bootstrap, which we really don't need for anything anyway.
patch attached.
Changed 6 months ago by kencu (Ken)
Attachment: | patch-cmake-bootstrap-disable-curses-gui.diff added |
---|
comment:27 Changed 6 months ago by kencu (Ken)
comment:28 Changed 4 weeks ago by jmroot (Joshua Root)
Replying to kencu:
I think you've hit on the issue. Indeed, /opt/local/include comes ahead of /usr/include on the default include path for this compiler.
This is #44141, which was closed as wontfix because the maintainer wasn't going to fix it, but there is an invitation to reopen if someone can provide a fix.
main.log