conflicting declaration of 'char

[Masha Vecherkovskaya]

Hi.

Could someone please have a look, I can’t figure out this one myself. I’m
trying to build a program and make fails with

*error: *conflicting declaration of '*char* ctermid(char*)*' with '*C*'
linkage

  222 | char**ctermid*(char *);


I’ve attacheched all steps I’ve taken. I have also tried to use apple
clang, but configure fails

Masha
MacBook-Pro:build mashavecher$ export CXX=/opt/local/bin/g++-mp-11
MacBook-Pro:build mashavecher$ export CC=/opt/local/bin/gcc-mp-11
MacBook-Pro:build mashavecher$ /Applications/strelka/configure --jobs=4 
--prefix=/Applications/strelka
cmake version 3.21.4 (>= 2.8.12) is already installed
Using existing cmake: cmake
--  Initializing project cmake configuration 
-- BUILD_TYPE: Release
-- CMAKE_PARALLEL: 4
-- The C compiler identification is GNU 11.2.0
-- The CXX compiler identification is GNU 11.2.0
-- Checking whether C compiler has -isysroot
-- Checking whether C compiler has -isysroot - yes
-- Checking whether C compiler supports OSX deployment target flag
-- Checking whether C compiler supports OSX deployment target flag - yes
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /opt/local/bin/gcc-mp-11 - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Checking whether CXX compiler has -isysroot
-- Checking whether CXX compiler has -isysroot - yes
-- Checking whether CXX compiler supports OSX deployment target flag
-- Checking whether CXX compiler supports OSX deployment target flag - yes
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /opt/local/bin/g++-mp-11 - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- TARGET_ARCHITECTURE: x86_64
-- install prefix: /Applications/strelka
-- Found Boost: /opt/local/include (found suitable version "1.76.0", minimum 
required is "1.58.0")  
-- Boost component: date_time   status: STATIC LIBRARY NOT FOUND
-- Boost component: filesystem  status: STATIC LIBRARY NOT FOUND
-- Boost component: program_options status: STATIC LIBRARY NOT FOUND
-- Boost component: serialization   status: STATIC LIBRARY NOT FOUND
-- Boost component: system  status: STATIC LIBRARY NOT FOUND
-- Boost component: timer   status: STATIC LIBRARY NOT FOUND
-- Boost component: chrono  status: STATIC LIBRARY NOT FOUND
-- Boost component: unit_test_framework status: STATIC LIBRARY NOT FOUND
-- Boost version 1.58.0+ not found or found without all required components. 
Boost will be built from source distribution...
-- Unpacking boost library source
-- Configuring boost library
-- Building boost library
-- Successfuly built boost 1.58.0
-- Found Boost: /Applications/strelka/build/bootstrap/boost/include (found 
suitable version "1.58.0", minimum required is "1.58.0") found components: 
date_time filesystem program_options serialization system timer chrono 
unit_test_framework 
-- Building external tools
-- Found ZLIB: /opt/local/lib/libz.dylib (found version "1.2.11") 
-- zlib found
-- Verifying target directories access
-- Looking for floorf
-- Looking for floorf - found
-- Looking for round
-- Looking for round - found
-- Looking for roundf
-- Looking for roundf - found
-- Looking for powf
-- Looking for powf - found
-- Looking for pthread.h
CMake Warning (dev) at 
/opt/local/share/cmake-3.21/Modules/CheckIncludeFile.cmake:82 (message):
  Policy CMP0075 is not set: Include file check macros honor
  CMAKE_REQUIRED_LIBRARIES.  Run "cmake --help-policy CMP0075" for policy
  details.  Use the cmake_policy command to set the policy and suppress this
  warning.

  CMAKE_REQUIRED_LIBRARIES is set to:

m

  For compatibility with CMake 3.11 and below this check is ignoring it.
Call Stack (most recent call first):
  /opt/local/share/cmake-3.21/Modules/FindThreads.cmake:146 (CHECK_INCLUDE_FILE)
  src/cmake/cxxConfigure.cmake:79 (find_package)
  src/c++/CMakeLists.txt:38 (include)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE  
-- No ccache found
-- Using compiler: g++ version 11.2.0
-- Building in developer mode: treating compiler warnings as errors
-- Adding c++ library subdirectory: test
-- Adding c++ library subdirectory: strelka_common
-- Adding c++ library subdirectory: starling_common
-- Adding c++ test subdirectory:starling_common/test
-- Adding c++ library subdirectory: alignment
-- Adding c++ test subdirectory:alignment/test
-- Adding c++ library subdirectory: assembly
-- Adding c++ test subdirectory:assembly/test
-- Adding c++ library subdirectory: blt_common
-- Adding c++ test subdirectory:blt_common/test
-- Adding c++ library subdirectory: calibration
-- Adding c++ library subdirectory: errorAnalysis
-- Adding c++ library subdirectory: options
-- 

Re: Variance Handling Question

[Sriranga Veeraraghavan]

Hi Jim,

According to a recent posting to this list, it may be possible to use the Xcode 
13.1 command line tools (CLT) on Big Sur 11.6.1:

https://lists.macports.org/pipermail/macports-users/2021-November/050466.html 


I am still using Xcode 12, so I cannot confirm whether this works.

Re your other question - in older versions of MacOSX it was possible to ignore 
App Store updates by right clicking on them and selecting “Hide Update”, but 
this seems to no longer work on Big Sur. 

From Catalina 10.15.6 (and Mojave / High Sierra Security Update 2020-004) 
onwards, it appears that a Mac must be in a "Apple School Manager, Apple 
Business Manager, or a user-approved MDM” to hide Major new releases of macOS. 
(See https://support.apple.com/en-us/HT210642 
), so unfortunately it isn’t easy to 
hide the Monterey update.

Best,

-ranga

> On Nov 18, 2021, at 11:15, James Secan  wrote:
> 
> I’m moving to a Big Sur system, and since I don’t use Xcode for anything I 
> manually download and install the CLI tools by themsleves.  I installed 
> v12.5.1 as per the info on the MacPorts wiki 
> (https://trac.macports.org/wiki/XcodeVersionInfo) about which Xcode goes with 
> which macOS.  Now the softwareupdater is nagging me to update to v13.0 (along 
> with the already annoying nag to update to Monterey).
> 
> I am assuming that this upgrade to CLI toolkit v13.0 is not a good idea until 
> I move up to Monterey.  Is this correct?  If so, is there some way to may the 
> softwareupdater stop the nagging?
> 
> Jim
> 3222 NE 89th St
> Seattle, WA 98115
> (206) 430-0109
> 

Variance Handling Question

[James Secan]

I’m moving to a Big Sur system, and since I don’t use Xcode for anything I 
manually download and install the CLI tools by themsleves.  I installed v12.5.1 
as per the info on the MacPorts wiki 
(https://trac.macports.org/wiki/XcodeVersionInfo) about which Xcode goes with 
which macOS.  Now the softwareupdater is nagging me to update to v13.0 (along 
with the already annoying nag to update to Monterey).

I am assuming that this upgrade to CLI toolkit v13.0 is not a good idea until I 
move up to Monterey.  Is this correct?  If so, is there some way to may the 
softwareupdater stop the nagging?

Jim
3222 NE 89th St
Seattle, WA 98115
(206) 430-0109

Re: Does MacPorts depend on Spotlight?

[Craig Treleaven]

> On Nov 18, 2021, at 9:47 AM, Eric Gallager via macports-users 
>  wrote:
> 
> On Thu, Nov 18, 2021 at 3:02 AM Ryan Schmidt  wrote:
>> 
>> MacPorts base doesn't do anything with Spotlight. It doesn't depend on it 
>> existing, nor does it tell Spotlight to index or not to index anything. 
>> MacPorts predates the existence of Spotlight.
>> 
>> As far as I know, ports don't depend on Spotlight having indexed the 
>> MacPorts prefix or the build directory. On the MacPorts buildbot machines, I 
>> exclude /opt/local and /Applications/MacPorts from the Spotlight index in 
>> order to reduce disk writes. As far as I know, this hasn't caused any build 
>> failures.
>> 
>> I do recall at least one port where we discovered that it was using `mdfind` 
>> (the command line utility for finding files using the Spotlight index) to 
>> find something it needed (Xcode, if I recall), and this failed for a user 
>> who had excluded either /Applications or maybe their whole disk from 
>> Spotlight or turned Spotlight off entirely, so I don't recommend doing that.
>> 
> 
> Didn't MacPorts start doing `chflags hidden` on
> /opt/local/var/macports at some point to stop Spotlight from indexing
> it? If it wasn't actually to stop Spotlight from indexing it, then why
> hide it? Also Fink makes Spotlight avoid its build directory by giving
> it a `.build` suffix; apparently a `.noindex` suffix ought to work,
> too; I've thought for a while that MacPorts should use one of these
> suffixes as well. Also Fink supplies a package that provides an
> importer that allows Spotlight to index its info files, which is
> something that I've wondered if it could be ported to MacPorts to
> create an `.mdimporter` for Portfiles, too:
> https://github.com/fink/fink-distributions/blob/4b95ece57eb9acdf68b7d4390914b59e16370bff/10.4/stable/main/finkinfo/devel/finkinfofile.info


There was some discussion of alternative ways to avoid indexing, all the way 
back in 2014:

https://www.mail-archive.com/macports-dev@lists.macosforge.org/msg26538.html 


Craig

Re: Does MacPorts depend on Spotlight?

[Richard L. Hamilton]

sh-3.2$ ls -ld@O /opt/local/var/macports
drwxr-xr-x@ 13 root  wheel  - 416 Apr 16  2021 /opt/local/var/macports
com.apple.FinderInfo 32 

sh-3.2$ lsmac /opt/local/var
[...]
I-   11 items  - macports/ 
[...]

Mine doesn't have the BSD (Windows compatibility) hidden flag, but it does have 
the Finder info "invisible" flag ( the "I" on the left in the 2nd output shown 
above) - two different things, no idea why both exist, probably compatibility).

I've never before seen mention of either flag blocking Spotlight in discussions 
of ways to block Spotlight from indexing certain files or folders/directories.


> On Nov 18, 2021, at 09:47, Eric Gallager  wrote:
> 
> On Thu, Nov 18, 2021 at 3:02 AM Ryan Schmidt  wrote:
>> 
>> MacPorts base doesn't do anything with Spotlight. It doesn't depend on it 
>> existing, nor does it tell Spotlight to index or not to index anything. 
>> MacPorts predates the existence of Spotlight.
>> 
>> As far as I know, ports don't depend on Spotlight having indexed the 
>> MacPorts prefix or the build directory. On the MacPorts buildbot machines, I 
>> exclude /opt/local and /Applications/MacPorts from the Spotlight index in 
>> order to reduce disk writes. As far as I know, this hasn't caused any build 
>> failures.
>> 
>> I do recall at least one port where we discovered that it was using `mdfind` 
>> (the command line utility for finding files using the Spotlight index) to 
>> find something it needed (Xcode, if I recall), and this failed for a user 
>> who had excluded either /Applications or maybe their whole disk from 
>> Spotlight or turned Spotlight off entirely, so I don't recommend doing that.
>> 
> 
> Didn't MacPorts start doing `chflags hidden` on
> /opt/local/var/macports at some point to stop Spotlight from indexing
> it? If it wasn't actually to stop Spotlight from indexing it, then why
> hide it? Also Fink makes Spotlight avoid its build directory by giving
> it a `.build` suffix; apparently a `.noindex` suffix ought to work,
> too; I've thought for a while that MacPorts should use one of these
> suffixes as well. Also Fink supplies a package that provides an
> importer that allows Spotlight to index its info files, which is
> something that I've wondered if it could be ported to MacPorts to
> create an `.mdimporter` for Portfiles, too:
> https://github.com/fink/fink-distributions/blob/4b95ece57eb9acdf68b7d4390914b59e16370bff/10.4/stable/main/finkinfo/devel/finkinfofile.info
> 

-- 
eMail:  mailto:rlha...@smart.net

Re: Does MacPorts depend on Spotlight?

[Eric Gallager via macports-users]

On Thu, Nov 18, 2021 at 3:02 AM Ryan Schmidt  wrote:
>
> MacPorts base doesn't do anything with Spotlight. It doesn't depend on it 
> existing, nor does it tell Spotlight to index or not to index anything. 
> MacPorts predates the existence of Spotlight.
>
> As far as I know, ports don't depend on Spotlight having indexed the MacPorts 
> prefix or the build directory. On the MacPorts buildbot machines, I exclude 
> /opt/local and /Applications/MacPorts from the Spotlight index in order to 
> reduce disk writes. As far as I know, this hasn't caused any build failures.
>
> I do recall at least one port where we discovered that it was using `mdfind` 
> (the command line utility for finding files using the Spotlight index) to 
> find something it needed (Xcode, if I recall), and this failed for a user who 
> had excluded either /Applications or maybe their whole disk from Spotlight or 
> turned Spotlight off entirely, so I don't recommend doing that.
>

Didn't MacPorts start doing `chflags hidden` on
/opt/local/var/macports at some point to stop Spotlight from indexing
it? If it wasn't actually to stop Spotlight from indexing it, then why
hide it? Also Fink makes Spotlight avoid its build directory by giving
it a `.build` suffix; apparently a `.noindex` suffix ought to work,
too; I've thought for a while that MacPorts should use one of these
suffixes as well. Also Fink supplies a package that provides an
importer that allows Spotlight to index its info files, which is
something that I've wondered if it could be ported to MacPorts to
create an `.mdimporter` for Portfiles, too:
https://github.com/fink/fink-distributions/blob/4b95ece57eb9acdf68b7d4390914b59e16370bff/10.4/stable/main/finkinfo/devel/finkinfofile.info

Re: xorg-server

[Christopher Jones]

See https://trac.macports.org/ticket/63990 


rev bumping the xinit port fixed things, at least for me. Please if you are 
having trouble with the X11 server see if that update helps...

> On 18 Nov 2021, at 8:02 am, Ryan Schmidt  wrote:
> 
> On Nov 15, 2021, at 15:11, Tom wrote:
> 
>> On 12. Nov 2021, at 21:17, Chris Jones wrote:
>>> 
>>> Impossible to say without more data.
>>> 
>>> Do you have any crash logs in Console ? Any other messages ?
>>> 
>>> What application are you running ? Try install a simple one like xclock and 
>>> see if that works ?
>>> 
>>> Have you tired removing then reinstalling the xorg-server port ?
>>> 
>>> Are you actually using the xorg-server X11 server or do you perhaps have 
>>> another one installed instead ?
>>> 
>>> Have you logged out and back in again, as required by the xorg-server 
>>> instalation ?
>> 
>> Same problem with xclock. Where can I find the log file of the xorg-server?
> 
> On macOS, crash logs are located in ~/Library/Logs/DiagnosticReports.
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: xorg-server

[Ryan Schmidt]

On Nov 15, 2021, at 15:11, Tom wrote:

> On 12. Nov 2021, at 21:17, Chris Jones wrote:
>> 
>> Impossible to say without more data.
>> 
>> Do you have any crash logs in Console ? Any other messages ?
>> 
>> What application are you running ? Try install a simple one like xclock and 
>> see if that works ?
>> 
>> Have you tired removing then reinstalling the xorg-server port ?
>> 
>> Are you actually using the xorg-server X11 server or do you perhaps have 
>> another one installed instead ?
>> 
>> Have you logged out and back in again, as required by the xorg-server 
>> instalation ?
> 
> Same problem with xclock. Where can I find the log file of the xorg-server?

On macOS, crash logs are located in ~/Library/Logs/DiagnosticReports.

Re: Does MacPorts depend on Spotlight?

[Ryan Schmidt]

MacPorts base doesn't do anything with Spotlight. It doesn't depend on it 
existing, nor does it tell Spotlight to index or not to index anything. 
MacPorts predates the existence of Spotlight.

As far as I know, ports don't depend on Spotlight having indexed the MacPorts 
prefix or the build directory. On the MacPorts buildbot machines, I exclude 
/opt/local and /Applications/MacPorts from the Spotlight index in order to 
reduce disk writes. As far as I know, this hasn't caused any build failures.

I do recall at least one port where we discovered that it was using `mdfind` 
(the command line utility for finding files using the Spotlight index) to find 
something it needed (Xcode, if I recall), and this failed for a user who had 
excluded either /Applications or maybe their whole disk from Spotlight or 
turned Spotlight off entirely, so I don't recommend doing that.