Guile 3

[Werner LEMBERG]

Recent LilyPond development versions only compile with Guile 3.  It
would be great if

  https://github.com/macports/macports-ports/pull/14600

can be eventually finished and added to MacPorts.


Werner

Re: Lilypond documentation (info+man) installation?

[Werner LEMBERG]

> I'd say build it with +docs, but that failed for me:
> 
> :info:build Making Documentation/out/lilypond-contributor.info < texi
> :info:build bibtex: Not writing to 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_textproc_lilypond/lilypond/work/.tmp/tmpy0vuau0_/bib2texi-tmp.blg
>  (openout_any = p; no  extended check).
> :info:build bibtex exited with return code 1.
>
> [...]

This is new.  Most certainly `+docs` worked some time ago (at least on
my old Lion box, to which I won't have access in the near future
unfortunately).  What might be the reason of this failure?  I've never
seen this message before.

>> 2. Actually generate the documentation?

Only non-image info pages and man pages are generated and installed by
`+docs`; support for creating the remaining documentation files on a
Mac is yet to be done.  Any volunteers?


Werner

Re: pre-build packages for Lion

[Werner LEMBERG]

>> What are the intervals that pre-build packages for Lion are
>> generated?  For example, `libpaper` is already available, but
>> `ghostscript` is not
> 
> There will not be any prebuilt archives available for ghostscript
> for any macOS version where one of its dependents, e.g. libpaper, is
> using legacy-support:

D'oh, thanks.


Werner

pre-build packages for Lion

[Werner LEMBERG]

What are the intervals that pre-build packages for Lion are generated?
For example, `libpaper` is already available, but `ghostscript` is
not, and neither is 'texlive-bin'...

And while we are at it, 'ports.macports.org' reports that 'lilypond'
can't be build on Lion due to

```
Dependency 'poppler' with variants '+boost' has previously failed and is 
required.
```

(why is `+boost` needed?)

However, looking into the 'poppler' page on 'ports.macports.org' it
seems that the Lion build is healthy – and the variant '+boost' has
been just built from source on my computer without a problem...


Werner

Ghostscript upgrade will break LilyPond

[Werner LEMBERG]

Just a heads-up for all LilyPond users: Updating Ghostscript to the
most recent version (10.02.1) in MacPorts will break LilyPond.[*]

If possible, please wait until newer LilyPond versions (2.24.3 and
2.25.10) are available in MacPorts, which should happen soon.

If everything fails you might fall back to using the stand-alone
x86-64 Mac binaries from lilypond.org.


   Werner


[*] This Ghostscript security fix unfortunately removes functionality
used by the LilyPond's PS output.

Re: what is the meaning of a note that looks like a rhombus in a contrabass quartet arrangement?

[Werner LEMBERG]

> what is the meaning of a note that looks like a rhombus in a
> contrabass quartet arrangement?

I don't know how many people are both on the MacPorts and the LilyPond
mailing list (you sent this e-mail to the wrong one :-), so I'm going
to answer that: These notes are 'flageolet tones', also called
'harmonics', i.e., you only slightly touch the string at the notated
position.

> I don't see anything mentioned in the Notation Reference regarding
> this.

There are index entries for both terms.


Werner

Re: list of packages that are always compiled

[Werner LEMBERG]

Sorry for the late reply; only yesterday I had access again to my Mac.

>> is there an option to `port` that shows me the names of all packages
>> that must be built from source, and which are not available
>> pre-compiled from 'packages.macports.org'?  [...]
>
> List which ports do and don't have an archive available (for your
> current OS version and arch):
> 
> 
> List which ports are and aren't considered distributable:
> 

These scripts work fine, thank you very much!  I've opened
https://trac.macports.org/ticket/66653 regarding 'libpaper' thanks to
latter one.


Werner

Re: what is the MacPorts equivalent of homebrew pinning; freezing an installed version?

[Werner LEMBERG]

>> what is the MacPorts equivalent of homebrew pinning; freezing an
>> installed version?
> 
> There is none.
> 
> Just don't upgrade.

You might do

  sudo port upgrade outdated and not lilypond

to update everything buth LilyPond.


Werner

list of packages that are always compiled

[Werner LEMBERG]

Folks,


is there an option to `port` that shows me the names of all packages
that must be built from source, and which are not available
pre-compiled from 'packages.macports.org'?  Or maybe this list is
somewhere else, ideally also giving a reason?  [My use-case is
'ghostscript', for which I can't see why it is not provided
pre-compiled.]

Right now, I check 'packages.macports.org' directly whether there is a
directory, but this is inefficient IMHO – and it doesn't give the
reason :-)


Werner

Re: missing pre-compiled packages

[Werner LEMBERG]

>> I wonder why some pre-compiled packages are missing: [...]  If this
>> is expected, where is it documented?
> 
> Yes, it's expected that not all ports will have binaries available.
> See .

Thanks.

> The automated license checking doesn't have all the relevant
> information, so it errs on the side of not distributing.  Port
> maintainers can add some options manually if it gets it wrong.  I've
> done that for ccache now and binaries should be uploaded soon.
> [...]

And thanks for that, too.


Werner

missing pre-compiled packages

[Werner LEMBERG]

Folks,


I wonder why some pre-compiled packages are missing:

* ccache – the directory `https://packages.macports.org/ccache/` is
  empty

* git – the directory `https://packages.macports.org/git/` doesn't
  exist at all

If this is expected, where is it documented?


   Werner

Re: compiling emacs-devel on Mac OS X Lion fails

[Werner LEMBERG]

>> The 'emacs-devel' package of MacPorts is currently based on commit
>> 4650ea9c25514831d925e5006ea0c3679344333b (from 2022-Jul-12).
>>
>> On Mac OS X 10.7.5 (Lion), emacs 27.2 builds fine.  However, the above
>> commit fails with
>>
>> ```
>> ./temacs --batch  -l loadup --temacs=pbootstrap \
>>  --bin-dest /opt/local/bin/ \
>>  --eln-dest /opt/local/lib/emacs/29.0.50/
>> Warning: arch-independent data dir
>>   '/opt/local/share/emacs/29.0.50/etc/': Invalid argument
>> Warning: Lisp directory
>>   
>> '/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_editors_emacs/emacs-devel/work/emacs-20220712/lisp':
>>   Invalid argument
>> Error: /opt/local/share/emacs/29.0.50/etc/charsets: Invalid argument
>> Emacs will not function correctly without the character map files.
>> ```
> 
> What happens if you build without MacPorts, using the built-in
> Command Line Developer Tools instead?

Good idea!  Executing this script, which is based on the parameters
used in MacPorts' Portfile for 'emacs-devel',

```
./autogen.sh

CC=/usr/bin/clang \
CFLAGS='-pipe -Os -arch x86_64 -Wno-attributes' \
CPPFLAGS='-I/opt/local/include' \
LDFLAGS='-Wl,-headerpad_max_install_names -L/opt/local/lib -Wl,-no_pie -arch 
x86_64' \
./configure --disable-silent-rules \
--without-ns \
--without-x \
--without-dbus \
--without-gconf \
--without-libotf \
--without-m17n-flt \
--with-libgmp \
--with-gnutls \
--with-json \
--with-xml2 \
--with-modules \
--with-sqlite3 \
--with-webp

make -j2
```

within an Emacs git clone I could successfully compile and install
master (2024136d31) on my Mac OS X Lion box (and it works, too :-).
This is a build with the system's `/usr/bin/clang` but using a current
MacPorts installation for all additional tools and libraries.

Unfortunately, it is beyond my rudimentary Mac OS X knowledge to find
out why the above works, and why the similar `port install
emacs-devel` fails.

Attached is the log file; thanks to `-Wno-attributes` its uncompressed
size is around 0.5MB instead of 100MB (!).  I will write a separate
e-mail regarding these attribute warnings.


Werner


build-emacs.log.xz
Description: Binary data

compiling emacs-devel on Mac OS X Lion fails

[Werner LEMBERG]

The 'emacs-devel' package of MacPorts is currently based on commit
4650ea9c25514831d925e5006ea0c3679344333b (from 2022-Jul-12).

On Mac OS X 10.7.5 (Lion), emacs 27.2 builds fine.  However, the above
commit fails with

```
./temacs --batch  -l loadup --temacs=pbootstrap \
 --bin-dest /opt/local/bin/ \
 --eln-dest /opt/local/lib/emacs/29.0.50/
Warning: arch-independent data dir
  '/opt/local/share/emacs/29.0.50/etc/': Invalid argument
Warning: Lisp directory
  
'/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_editors_emacs/emacs-devel/work/emacs-20220712/lisp':
  Invalid argument
Error: /opt/local/share/emacs/29.0.50/etc/charsets: Invalid argument
Emacs will not function correctly without the character map files.
```

Does this ring a bell?  I reported the problem already in

  https://lists.gnu.org/archive/html/emacs-devel/2022-04/msg00803.html

without progress then.  It also fails on Mountain Lion and Mavericks,
BTW; the earliest Mac OS version that successfully builds
'emacs-devel' is Yosemite.

For more details on the builds (including *huge* log files > 100MB
because of zillion compilation warnings that weren't present in 27.2)
see

  https://ports.macports.org/port/emacs-devel/details/


Werner

Re: ccache problem

[Werner LEMBERG]

>> It seems to be a problem with the 'ccache' package/port on MacOS
>> 10.7.5.  After updating to current git (and running `port sync`),
>> `port upgrade outdated` just tried to compile emacs 28.1, and
>> exactly the same problem happened.
> 
> It looks like /run/user//ccache-tmp is indeed a path hardcoded
> into the ccache program.

Thanks for checking.

> The documentation says:
> 
> https://ccache.dev/manual/4.6.html#config_temporary_dir
> 
> "The default is /run/user//ccache-tmp if /run/user/
> exists, otherwise /tmp."
> 
> If you are certain that /run/user/ does not exist, then perhaps
> the detection of its existence is faulty on Mac OS X 10.7.5.

It seems so.  I've just removed directory `/run/user/`, but
emacs configuration still aborts: the directory
`/run/user//ccache-tmp` has been created again (owner
'macports.staff', mode 'drwxr-xr-x') but `ccache` can't create any
files in it, failing in the same way as already reported.

I've just opened https://trac.macports.org/ticket/64983.

> To install an older version of a port, see
> https://trac.macports.org/wiki/howto/InstallingOlderPort

Thanks.


Werner

Re: ccache problem

[Werner LEMBERG]

>> ```
>> ccache /opt/local/bin/clang-mp-13 ... conftest.c >&5
>> ccache: error: Failed to create temporary file for
>>   /run/user/507/ccache-tmp/tmp.cpp_stdout.RTVNqj: Operation not permitted
>> ```
>> 
>> What's the reason that `port` tries to use
>> `/run/user/507/ccache-tmp/` (uid 507 = macports) instead of the
>> default ccache dir?
> 
> I've never heard of that happening before. macOS has never had a
> /run directory.

Well, I'm not a MacOS user – except doing regular updates for MacPorts
(and checking/adjusting the LilyPond port if necessary), this computer
isn't used for anything else.

> Is a path beginning with /run/user familiar to you?

No.

> Do you have something special set on your system that uses such
> paths?

No idea.  As mentioned in my previous e-mail, I haven't changed
anything in the configuration.

> Does this happen with any other ports or just lilypond-devel?  Maybe
> lilypond-devel's build system is doing something weird.

It seems to be a problem with the 'ccache' package/port on MacOS
10.7.5.  After updating to current git (and running `port sync`),
`port upgrade outdated` just tried to compile emacs 28.1, and exactly
the same problem happened.

How can I test most easily whether my assumption is correct?  What is
the recommended way to install an older version of 'ccache'?


Werner

ccache problem

[Werner LEMBERG]

[macports-base 5d637741b5ae04b63f7e99a9057c6764d29fd7fd (Mar 10 2022)]
[macports-ports b6d340c43cdb2bef077f72edb075a124148832ed (Apr 1 2022)]


I'm trying to install `lilypond-devel` on my macOS 10.7.5 box; due to
using variants this must be compiled.  Previously, this always worked,
however, I now get an error during the `configure` step.  In
`config.log` file I see

```
ccache /opt/local/bin/clang-mp-13 ... conftest.c >&5
ccache: error: Failed to create temporary file for 
/run/user/507/ccache-tmp/tmp.cpp_stdout.RTVNqj: Operation not permitted
```

In my `macports.conf` file I have `configureccache yes` (unchanged
since a very long time), and `ccache_dir` is unset.  After doing

```
sudo port uninstall cccache
sudo port clean --all ccache
sudo port install cccache
```

I can see that `/opt/local/var/macports/build/.ccache` has been
created anew (together with some subdirectories); the permissions are
755, and the owner is 'macports.wheel'.  In comparison,
`/run/user/507/ccache-tmp/` has the same permissions but the owner is
'macports.staff'.  [I haven't changed anything manually.]

What's the reason that `port` tries to use `/run/user/507/ccache-tmp/`
(uid 507 = macports) instead of the default ccache dir?

Is this a bug with the new `ccache` version (which `port` compiled,
too)?  Am I doing something wrong?


Werner

Re: 'doctor' script

[Werner LEMBERG]

>> So: Is there a command (or a simple shell invocation) to walk over
>> all packages to check whether all dependencies are fulfilled?  I
>> suppose that `sudo port upgrade outdated` doesn't do this for
>> efficiency.
> 
> Upgrading a port will first install any missing dependencies, so 'sudo
> port upgrade installed' should do what you want.

Perfect, thanks!


Werner

Re: 'doctor' script

[Werner LEMBERG]

>> is there a 'doctor' script that walks over all installed MacPorts
>> ports and checks whether its dependencies are installed, too?  In
>> general, what's the right action(s) to thoroughly check the
>> integrity of a MacPorts installation?
>> 
>> I have forcibly uninstalled some ports by accident, and due to
>> using mosh I can't scroll backwards to see which they are...
> 
> sudo port rev-upgrade
> 
> https://man.macports.org/port-rev-upgrade.1.html
> 
> MacPorts also runs this automatically every time you install or
> upgrade a port, unless you've disabled that functionality.

Thanks, but it seems to check binaries only, not packages.  In
particular, it seems to not check Perl or Python package dependencies.

So: Is there a command (or a simple shell invocation) to walk over all
packages to check whether all dependencies are fulfilled?  I suppose
that `sudo port upgrade outdated` doesn't do this for efficiency.

> There's also
> 
> port diagnose
> 
> which was intended to be analogous to Homebrew's doctor.
> 
> https://man.macports.org/port-diagnose.1.html

Thanks again.


Werner

'doctor' script

[Werner LEMBERG]

Folks,


is there a 'doctor' script that walks over all installed MacPorts
ports and checks whether its dependencies are installed, too?  In
general, what's the right action(s) to thoroughly check the integrity
of a MacPorts installation?

I have forcibly uninstalled some ports by accident, and due to using
mosh I can't scroll backwards to see which they are...


Werner

license for stuff in `macports-www`

[Werner LEMBERG]

Looking at

  https://github.com/macports/macports-www/

I can't find a license statement that applies to the stuff in the
repository.  So: What license is it under?  I suggest to add a small
`README.md` file that mention it...


Werner

Re: after `sync -d`, installed versions are too new

[Werner LEMBERG]

>> sudo port -pb install outdated
> 
> -p is discouraged and harmful.

OK.

> We used to get numerous reports from users that expected
> 
>   sudo port install bison @3.7.4_0
> 
> to install bison 3.7.4, when in fact "install" ignores the version
> specifier (except in cases where you already have a copy of 3.7.4
> installed and "install" really just means "activate"). Since this
> was a common misconception, jmr extended install to check the
> version specification against the current version in the tree and
> raise an error on mismatch: [...]

Ah, ok.

> The solution to the problem is not using "install", but using
> "upgrade", which does not have the version check:
> 
>   sudo port upgrade outdated

This worked, thanks a lot!  No idea why I suddenly used 'install',
since previously I always used 'upgrade'...

>> PS: The mailing list archive at
> 
>> https://lists.macports.org/pipermail/macports-users/
> 
>> is rather useless; it neither provides a search function, nor does
> 
> We recommend using your search engine of choice to search the archives, e.g.
> using a site:lists.macports.org specifier.

OK, thanks.  Savannah uses Namazu for indexing; this is what I've
found on that topic.

  
https://wiki.list.org/DOC/4.08%20How%20can%20I%20add%20Namazu%20as%20a%20search%20engine%20for%20my%20Mailman%20list%20archives%3F

>> it display the dates for messages within the monthly views. What
>> I expect is something like this:
> 
>> https://lists.gnu.org/archive/html/lilypond-devel/
> 
>> It would be great if those features could be activated.
> 
> If that's a standard feature of mailman and you can point me to the
> necessary setting I can look into enabling this.

Uh, oh, I can't help here, sorry.  I have no idea how to handle
mailman at all.


Werner

after `sync -d`, installed versions are too new

[Werner LEMBERG]

Folks,


I'm running MacPorts directly from the git repository, using macOS
10.7.5.  Today, I've done my usual incantation

  git fetch upstream && git merge upstream/master && git push
  port -d sync

Calling

  port outdated

gives the expected output:

  The following installed ports are outdated:
  bison  3.7.4_0 < 3.7.5_0 
  bison-runtime  3.7.4_0 < 3.7.5_0 
  cctools927.0.2_7 < 949.0.1_0 
  cmake  3.19.3_0 < 3.19.4_0   
  gcc8   8.4.0_2 < 8.4.0_3 
  gcc9   9.3.0_4 < 9.3.0_5 
  gd22.3.0_0 < 2.3.1_0 
  ghostscript9.53.3_0 < 9.53.3_1   
  graphviz   2.40.1_3 < 2.40.1_4   
  libgcrypt  1.9.0_1 < 1.9.1_0 
  libmacho-headers   927.0.2_0 < 949.0.1_0 
  lilypond-devel 2.21.82_0 < 2.23.0_0  
  mc 4.8.25_1 < 4.8.26_0   
  meson  0.55.3_1 < 0.56.2_0   
  ncurses6.2_0 < 6.2_1 
  p5.28-io-socket-ssl2.68.0_0 < 2.69.0_0   
  p5.28-role-tiny2.2.3_0 < 2.2.4_0 
  poppler20.12.1_0 < 20.12.1_1 

However, calling

  sudo port -pb install outdated

yields errors that I haven't seen before:

  Error: bison version 3.7.4_0 is not available (current version is 3.7.5_0)
  Error: bison-runtime version 3.7.4_0 is not available (current version is 
3.7.5_0)
  Error: cctools version 927.0.2_7 is not available (current version is 
949.0.1_0)
  Error: cmake version 3.19.3_0 is not available (current version is 3.19.4_0)
  Error: gcc8 version 8.4.0_2 is not available (current version is 8.4.0_3)
  Error: gcc9 version 9.3.0_4 is not available (current version is 9.3.0_5)
  Error: gd2 version 2.3.0_0 is not available (current version is 2.3.1_0)
  Error: ghostscript version 9.53.3_0 is not available (current version is 
9.53.3_1)
  Error: graphviz version 2.40.1_3 is not available (current version is 
2.40.1_4)
  Error: libgcrypt version 1.9.0_1 is not available (current version is 1.9.1_0)
  Error: libmacho-headers version 927.0.2_0 is not available (current version 
is 949.0.1_0)
  Error: lilypond-devel version 2.21.82_0 is not available (current version is 
2.23.0_0)
  Error: mc version 4.8.25_1 is not available (current version is 4.8.26_0)
  Error: meson version 0.55.3_1 is not available (current version is 0.56.2_0)
  Error: ncurses version 6.2_0 is not available (current version is 6.2_1)
  Error: p5.28-io-socket-ssl version 2.68.0_0 is not available (current version 
is 2.69.0_0)
  Error: p5.28-role-tiny version 2.2.3_0 is not available (current version is 
2.2.4_0)
  Error: poppler version 20.12.1_0 is not available (current version is 
20.12.1_1)

Just to be sure, I've deleted the `PortIndex` files, then regenerated
with them with `port -d sync`, but the errors persist.  I've also
updated MacPorts itself to the latest git version, with no difference.

What's the right solution to this?

A few days ago, everything was OK...


Werner


PS: The mailing list archive at

  https://lists.macports.org/pipermail/macports-users/

is rather useless; it neither provides a search function, nor does
it display the dates for messages within the monthly views.  What
I expect is something like this:

  https://lists.gnu.org/archive/html/lilypond-devel/

It would be great if those features could be activated.

Re: 'LANG=' produces German output

[Werner LEMBERG]

 on my Lion box, calling
 
 LANG= bison ...
 
 I suddenly get *German* output!  [...]
>> 
>> It's seems to be a new feature of gettext 0.21, which comes with
>> improved MacOS support.  In the NEWS file I read
> 
> Then you should not be seeing this problem with MacPorts since we
> still use gettext 0.19.8.1.

OK.  Maybe it's another change, but essentially it doesn't matter :-)
I added a patch to my lilypond-devel PR (which will also be soon part
of lilypond upstream) to fix it.


Werner

Re: 'LANG=' produces German output

[Werner LEMBERG]

Hello Bruno,


thanks for your detailed answer.

>> I'm not sure whether I like this feature.  At least on the command
>> line, I consider it surprising.
> 
> There is the opposite expectation: "I have set that I want the
> programs to talk to me in German.  Why do I need to specify it a
> second time, through an environment variable, for the command-line
> programs?"

Because we did this the last 20 years?  As written above, I consider
it surprising, not necessarily bad...


Werner

Re: 'LANG=' produces German output

[Werner LEMBERG]

[CCing Bruno Haible]

>> on my Lion box, calling
>>
>>  LANG= bison ...
>>
>> I suddenly get *German* output!  Ditto for other programs like
>> 'info', 'ggrep', etc., that come with '.po' files.  Is this normal?
>> Is this a new gettext feature?
>
> I would suppose that without a valid locale LANG or the LC_*
> variables, there would be some other default - that it's not
> randomly picking a locale.

You are correct.

> On a "normal" Unix/Linux system, I would expect "C" locale (or
> perhaps a system setting) to be that default.  But Macs are a bit
> odd; their native apps get some defaults from system preference
> settings.  What are your language and region settings there?

It's seems to be a new feature of gettext 0.21, which comes with
improved MacOS support.  In the NEWS file I read

  * Runtime behaviour:
- The interpretation of the language preferences on macOS has been
  improved, especially in the case where a system locale does not
  exist for the combination of the selected primary language and
  the selected territory.

In my shell, `set` shows

  LANG=en_US.UTF-8

(and `LANGUAGE` is not set).

Some test results:

   bison --helpEnglish output
   LANG= bison --help  German output
   LANGUAGE= bison --help  English output
   LANG=C bison --help English output

On my GNU/Linux box that still uses gettext 0.19.8.1, I get the
following with the same `LANG` setting.

   bison --helpEnglish output
   LANG= bison --help  English output
   LANGUAGE= bison --help  English output
   LANG=C bison --help English output

My MacOS Lion box *is* a German one, so it seems that gettext extracts
language information from some other places if neither `LANGUAGE` nor
`LANG` is unset or set to an empty value.

I'm not sure whether I like this feature.  At least on the command
line, I consider it surprising.


 Werner

'LANG=' produces German output

[Werner LEMBERG]

[macports-ports 83eb0fba14b88745b29c0efa5d29aa73ee69c04b from 2020-02-12]


Folks,


on my Lion box, calling

  LANG= bison ...

I suddenly get *German* output!  Ditto for other programs like 'info',
'ggrep', etc., that come with '.po' files.  Is this normal?  Is this a
new gettext feature?


Werner

Re: linking problems

[Werner LEMBERG]

> Probably the problem is that you have specified CXX=clang-mp-9.0 --
> that's a C compiler.  You want the C++ compiler here:
> CXX=clang++-mp-9.0

Doh.  That's it.  I was blind.  Fortunately I did first ask here
before investing hours into delving this non-issue.

Thanks a lot!


Werner

linking problems

[Werner LEMBERG]

On my Mac Lion box running an up-to-date MacPorts, for experimentation
reasons I try to build the current git version of lilypond directly
from the repository – this is, I use the MacPorts infrastructure for
compilation with a recent clang version, but without any adaptations
of lilypond's source code.

Building in a separate directory I configure with

  /path/to/lilypond/git/configure \
  CC=clang-mp-9.0 \
  CXX=clang-mp-9.0 \
  --prefix=... \
  
--with-texgyre-dir="/usr/local/texlive/2018/texmf-dist/fonts/opentype/public/tex-gyre"
 \
  --with-flexlexer-dir="/opt/local/include" \
  --disable-documentation \
  --disable-optimising

then calling `make`.  However, this fails at the linking stage; I get
zillion of messages like

  Undefined symbols for architecture x86_64:
"std::__1::basic_string
  ,
   std::__1::allocator >::copy
 (char*,
  unsigned long,
  unsigned long) const", referenced from:
  ly_format(scm_unused_struct*, scm_unused_struct*)
in general-scheme.o

I guess I miss some linker flags due to the need of a special C++
library.

* Which linker flags do I miss?

* Why doesn't the above invocation of the `configure` script
  automatically handle this?  Or to ask differently, why doesn't
  `clang-mp-9.0` find its own library files automatically (at least I
  presume this is the problem)?


Werner

Re: problem with perl's `PAR' module

[Werner LEMBERG]

>>   Perl lib version (5.26.3) doesn't match executable
>> 'perl' version (5.26.1) at
>> /opt/local/lib/perl5/5.26/darwin-thread-multi-2level/Config.pm line 62.
>>   Compilation failed in require at
>> /opt/local/lib/perl5/site_perl/5.26/PAR.pm line 7.
>>
>>

> It could be a Perl port maintainer's issue or a texlive port issue,
> or even farther upstream in Perl 5.26 and the PAR maintainer on
> CPAN.
> 
> Try installing the PAR port before texlive and see if that pulls the
> right dependency.
> 
> The version requirement is so close you could probably get away by
> relaxing the requirement at
> /opt/local/lib/perl5/site_perl/5.26/PAR.pm line 7 to just 5.26

Thanks for the tips, but the problem was something completely
different: The `biber' binary is built with perl's `PAR:packer'
module, and I accidentally stripped the binary.  For this reason the
built-in 5.26.1 perl interpreter was retained, but the 5.26.3 support
files from MacPorts were used.  Reinstalling the (unstripped) `biber'
binary solved the issue.


Werner

Re: problem with perl's `PAR' module

[Werner LEMBERG]

Ryan,


thanks for your help.

> If you really want to use perl 5.26, then verify that [...]

All of this is exactly as you describe.  Since the `biber' program
from TeXLive 2018 works I suspect a problem with the new binary from
TeXLive 2019, which I will report upstream.


Werner

problem with perl's `PAR' module

[Werner LEMBERG]

Folks,


I've installed perl's `PAR` module, needed for TeXLive's (self-compiled)
`biber` binary, with

  sudo cpan-5.26 install PAR

on my up-to-date Lion box (using MacPorts from git).  However,
executing `biber --help` fails with

  Perl lib version (5.26.3) doesn't match executable
'perl' version (5.26.1) at
/opt/local/lib/perl5/5.26/darwin-thread-multi-2level/Config.pm line 62.
  Compilation failed in require at /opt/local/lib/perl5/site_perl/5.26/PAR.pm 
line 7.

Indeed, port shows

  port info perl5.26
  -> perl5.26 @5.26.3_2 (lang)

  port info perl5
  -> perl5 @5.26.1 (lang)

It seems that other Perl modules are not sensitive to different lib
and binary versions...  How can I fix that?


Werner

Re: package version and variant info in `main.log`

[Werner LEMBERG]

 I've noticed that in `main.log` files there is no information
 what version and variants have been requested – for example,
 
 ImageMagick @6.9.9-40_7+x11
 
 Wouldn't it make sense to make `port` add this information to the
 very top of `main.log`? This would also help identify various
 `make.log` files more easily.
>>
>> OK.  Shall I open a ticket?
> 
> Sure

Here it is.

  https://trac.macports.org/ticket/59643


Werner

Re: package version and variant info in `main.log`

[Werner LEMBERG]

>> I've noticed that in `main.log` files there is no information what
>> version and variants have been requested – for example,
>> 
>>  ImageMagick @6.9.9-40_7+x11
>> 
>> Wouldn't it make sense to make `port` add this information to the
>> very top of `main.log`? This would also help identify various
>> `make.log` files more easily.
> 
> If that's not already in there,

It seems so.

> then yes, that would be good to have.

OK.  Shall I open a ticket?


Werner

libunwind-headers issue

[Werner LEMBERG]

On Mac Lion, installing a fresh MacPorts from scratch, then calling

  port -N mpkg lilypond-devel +mactex +perl5_28 +python37

always causes a (harmless) abort.  The reason is that
`libunwind-headers' gets installed as part of the dependencies rather
early, but one of the very last steps is installation of `libgcc9',
which doesn't work with activated `libunwind-headers'.

Is it possible to somehow tell `port' in the above command that
`libunwind-headers' has to be deactivated before building `libgcc9'?


Werner

package version and variant info in `main.log`

[Werner LEMBERG]

I've noticed that in `main.log` files there is no information what
version and variants have been requested – for example,

  ImageMagick @6.9.9-40_7+x11

Wouldn't it make sense to make `port` add this information to the very
top of `main.log`? This would also help identify various `make.log` files
more easily.


Werner

Re: dmgbuild ports disappeared

[Werner LEMBERG]

> I looked for "dmgbuild" in all mailing list, tracker and github
> commit messages and found only:

What about

  https://pypi.org/project/dmgbuild/


Doesn't it work to install with pip (or pip2/pip3)?


Werner

Re: mpkg package variants

[Werner LEMBERG]

>>> I believe you can just specify the variants that you want (for the
>>> port and all of its dependencies) at the command line when you run
>>> `port mpkg`, can't you?  As in:
>>>
>>>  sudo port mpkg lilypond-devel +mactex +perl5_28
>>
>> This seems to work, thanks!  Maybe it's worth to document that.
>
> Surely it's already documented that variants you specify are passed
> down to any dependencies that get built (but not to any that don't
> need to be built)?

If it is, I have missed that.

> But maybe it is worth mentioning that for mpkg, all packages get
> rebuilt, so the specified variants are applied to all of the ports,
> even those that were already installed (if that's not already
> mentioned in the guide).

It's either missing or I have missed that, too :-)

>> Of course, the next question is whether MacPorts variant strings
>> form a consistent set without contradictions.
>
> What does that mean?

Since MacPorts contains thousands of packages there might be a clash
somewhere in the variant names.  Assuming that package X needs
`+foo' and package Y needs `-foo', I would have to specify

  mpkg ... +foo -foo

which obviously doesn't work.

>> Another issue: There are many files in the mpkg file that are
>> definitely unnecessary to run the final program (in my case the
>> `lilypond' binary from `lilypond-devel'), for example test files
>> for python, or header files of C libraries, or (most of the)
>> documentation.  Is there any support from `port' to not package
>> that?
>
> MacPorts ports always install header files where possible.  Many
> ports also install examples or documentation.  If these files are
> unwanted in your package, you may need to manually edit the package
> after it's been made.

OK, thanks.  This was my conclusion, too.

> As for test files, if you mean tests that get run by the `port test`
> command, then I would not expect those to be installed by a port;
> they would be used at test time and would not be needed afterwards.

I'm not sure about the `port test` thing, but the python 2.7 and 3.7
bundles contains zillions of files in directories

  .../Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test
  .../Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest

and

  .../Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/test
  .../Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/unittest

Are these files of any use after installation?


Werner

Re: mpkg package variants

[Werner LEMBERG]

>> Let me reformulate my question: Does the way how I have installed
>> MacPorts packages on my computer influence how `port mpkg' works
>> for a given package?  Given that `port mpkg' rebuilds all packages,
>> I would expect no.  Instead, I would expect some control file (or a
>> special command line sequence) to control variants of package
>> dependencies.
> 
> I believe you can just specify the variants that you want (for the
> port and all of its dependencies) at the command line when you run
> `port mpkg`, can't you?  As in:
> 
>   sudo port mpkg lilypond-devel +mactex +perl5_28

This seems to work, thanks!  Maybe it's worth to document that.

Of course, the next question is whether MacPorts variant strings form
a consistent set without contradictions.

Another issue: There are many files in the mpkg file that are
definitely unnecessary to run the final program (in my case the
`lilypond' binary from `lilypond-devel'), for example test files for
python, or header files of C libraries, or (most of the)
documentation.  Is there any support from `port' to not package that?


Werner

Re: mpkg package variants

[Werner LEMBERG]

>> I wonder how package variants are handled while creating `mpkg'
>> bundles.  As an example, consider the output of
>>
>>   port rdeps lilypond-devel +mactex
>>
>> Looking at it you can see
>>
>>   ...
>>   ossp-uuid
>> perl5.26
>> ...
>>
>> and
>>
>>   ...
>>   llvm-3.4
>> perl5
>>   perl5.28
>>   ...
>>
>> The created `mpgk-packages' directory indeed contains both perl
>> 5.26 and 5.28.
>>
>> However, it is possible to install `ossp-uuid' as
>>
>>   port install ossp-uuid +perl5_28
>>
>> In other words, it would be possible to omit a dependency on
>> `perl5.26' altogether.  What must I do to enforce this for `port
>> mpkg'?  This would reduce the size of the bundle by approx
>> 16MByte...
>
> On my machine "port info ossp-uuid" says that default in 5.28 now,
> but you might have installed it when 5.26 was still the default, so
> I'm not quite sure what goes wrong here (does installing with 5.28
> variant help?).

I did install `ossp-uuid' with 5.28, but a new run of `port mpkg'
(without a `port clean', though) gives the same result.

Let me reformulate my question: Does the way how I have installed
MacPorts packages on my computer influence how `port mpkg' works for a
given package?  Given that `port mpkg' rebuilds all packages, I would
expect no.  Instead, I would expect some control file (or a special
command line sequence) to control variants of package dependencies.

Is this flawed thinking?


Werner

mpkg package variants

[Werner LEMBERG]

Folks,


I wonder how package variants are handled while creating `mpkg'
bundles.  As an example, consider the output of

  port rdeps lilypond-devel +mactex

Looking at it you can see

  ...
  ossp-uuid
perl5.26
...

and

  ...
  llvm-3.4
perl5
  perl5.28
  ...

The created `mpgk-packages' directory indeed contains both perl 5.26
and 5.28.

However, it is possible to install `ossp-uuid' as

  port install ossp-uuid +perl5_28

In other words, it would be possible to omit a dependency on
`perl5.26' altogether.  What must I do to enforce this for `port
mpkg'?  This would reduce the size of the bundle by approx 16MByte...


Werner

Re: libuv fails to build on 10.8.5

[Werner LEMBERG]

> I do appreciate your time and fully understand that this is not your
> concern but would be still thankful if anyone could advice on how to
> configure MacPorts to use the recent ssl.

Try this for bootstrapping:

  https://try.gitea.io/donbright/lm


Werner

Re: problem with reactivating ports

[Werner LEMBERG]

Hello Ryan!


> Do you need those old inactive versions?  If not, you could
> uninstall the inactive ports before beginning the exercise.

Is there a safe command to uninstall all inactive ports in one rush?

>> Irrespective of the problems I wonder whether it is a valid
>> approach to deactivate everything – since `port' started with zero
>> packages at the very beginning, it should work, right?
> 
> Yes, deactivating all ports should work successfully. We do that on
> the buildbot workers after every build.

Verified thanks, after building `port' with an external curl library
(I used https://try.gitea.io/donbright/lm for my Lion box).

>> Ah, my fault, I was imprecise: `port' complained not being able to
>> deactivate `libgcc8' because it wasn't active.  This implies that
>> `port' has implicitly already deactivated it and then stumbled over
>> the direct command to deactivate.
> 
> I have seen this error with libgcc8 on the buildbot workers as well.
> I think we probably forgot a step back when the libgcc7/libgcc8
> ports were introduced.  For example, we may have forgotten to
> increase the revision of all the ports that depend on those ports.

OK, thanks for the info.

> Of course, macOS is not GNU/Linux and there are some differences.
> For example, whereas GNU/Linux uses its package manager to install
> everything, macOS comes with libraries like libcurl that are not
> managed by a package manager and we use them.  There is no need to
> link with them statically, nor do we want to, for all the usual
> reasons: If that library is ever updated by Apple, we would not
> benefit from that update.

Well, this is true for MacOS versions still supported by Apple, but
not for older ones.  I'm glad that MacPorts is on the conservative
side.  For the young kids who always use the newest stuff there is
Homebrew...

> The problem only arises when you do something unsupported, like
> linking MacPorts to libraries it itself installed. Please don't do
> that! :)

Lesson learned :-)

> I continue to believe that we should bundle a recent version of curl
> and libressl with MacPorts to avoid the too-old-openssl problem that
> we see on older macOS systems, but we have not reached consensus
> that we want to do that.  See https://trac.macports.org/ticket/51516

Yes!  Actually, I don't understand the many objections raised in the
ticket.  For older MacOS versions, `macports-base' could be configured
to build private, statically linked libcurl & ssl versions only once,
namely for `port' itself – let's call the resulting binary
`port-bootstrap' –, and there would be no need to always use the most
recent and most secure versions since you only use it to start
MacPorts package management.  The first action could be then to
download a `port' package (which doesn't exist yet) that uses the most
recent libraries, and which receives the usual updates.  If someone is
going to delete that `port' package accidentally, the original
`port-bootstrap' binary would be still available as a backup.

>> I want to document how to build.  Compiling all lilypond flavours
>> from scratch (including documentation) takes almost a day (using
>> approx. 20GByte of disk space), so it is quite important to know
>> what MacPorts packages must be installed before starting
>> compilation for obvious reasons.  [...]
> 
> I don't think there's a good way to figure that out automatically.
> [...]

OK, thanks.


Werner

Re: problem with reactivating ports

[Werner LEMBERG]

Hello Mojca,


thanks for replying!

>>   port echo active > macports.active
>>   sudo port deactivate `cat macports.active`
>>
>> to deactivate all MacPorts packages.  I tried with the `-y' flag in
>> advance, just to be sure...
> 
> I understand the first command, but a much better way for the second
> one would be
>
> sudo port deactivate active

It's simpler, yes, but why is it `much better'?  As far as I
understand, later on I can't simply say

  sudo port activate inactive

since the list of inactive ports is much larger due to updates.  In
other words, I have to store the list of active packages somewhere.

>> It seems now that this was actually a bad idea.  First of all,
>> `port' aborted in the middle, talking about not being able to
>> deactivate `libgcc8' (which is on the `macports.active' list).
> 
> I'm not really sure, but one thing that might happen is that the
> list of ports to be deactivated comes in wrong order.  If B depends
> on A and you call
>
> sudo port deactivate A B
>
> then I might fail to deactivate since port is processing them in the
> same order as they are written and complains that B depends on A, so
> A cannot be deactivated unless you force it or run it in a recursive
> way.

Hmm.  Shouldn't `port' handle such situations gracefully?  It gets all
packages to be deactivated as a single call, it thus can reorder as
necessary.

Irrespective of the problems I wonder whether it is a valid approach
to deactivate everything – since `port' started with zero packages at
the very beginning, it should work, right?

> (Reading further, another reason could be that the ports you tried
> to deactivate cannot be deactivated as they are needed for the port
> command itself.)

Ah, my fault, I was imprecise: `port' complained not being able to
deactivate `libgcc8' because it wasn't active.  This implies that
`port' has implicitly already deactivated it and then stumbled over
the direct command to deactivate.

>>  Secondly, restarting `port' no longer works; [...]
>
> This is somewhat strange.  This is my blind guess [...]

Yes, this is it, I presume.  Will work on that soon.

> If you want to use a different libcurl, you could install that
> libcurl somewhere else.  You can install two parallel macports (just
> make sure that you configure it properly to avoid clashes in
> /Applications/MacPorts, disable the services etc.) and then use one
> of them just as "supporting system" for the other one.  We would
> have fixed this long ago if it wasn't for the chicken-and-egg issue
> :)

Yes, this was explained to me on the list, but I was too lazy to go
that route.  Now the issue knocked me down :-) IMHO, the best solution
would be to build a statically linked `port' program that is immune to
DLL problems – AFAIK, most GNU/Linux distributions do exactly that for
the central package manager (zypper, apt, rpm, etc.)

>> * Is there a simple way to protocol needed MacPorts packages?
> 
> Needed by/for what? You can list recursive dependencies, inside the
> port you can run trace mode to make sure that no other files are
> used, listing active packages is possible (but note that you'll
> probably end up with build dependencies as well if you are building
> from source ...)

I want to build `gub', the lilypond packager.  Assuming that it works
I want to document how to build.  Compiling all lilypond flavours from
scratch (including documentation) takes almost a day (using
approx. 20GByte of disk space), so it is quite important to know what
MacPorts packages must be installed before starting compilation for
obvious reasons.

As an example, I can't directly start `gub' because Lion's python
version is too old.  I thus have to install `python' via MacPorts
before I can explore what else is missing.


Werner

problem with reactivating ports

[Werner LEMBERG]

[macports running from git]


Folks,


I wanted to compile a project under MacPorts, and at the same time I
wanted to protocol what MacPorts packages must be installed in advance
before starting compilation.  My glorious idea was to say

  port echo active > macports.active
  sudo port deactivate `cat macports.active`

to deactivate all MacPorts packages.  I tried with the `-y' flag in
advance, just to be sure...

It seems now that this was actually a bad idea.  First of all, `port'
aborted in the middle, talking about not being able to deactivate
`libgcc8' (which is on the `macports.active' list).  Secondly,
restarting `port' no longer works; it complains as follows

  dlopen(/opt/local/libexec/macports/lib/pextlib1.0/Pextlib.dylib, 6):
Library not loaded: /opt/local/lib/libcurl.4.dylib
  Referenced from: /opt/local/libexec/macports/lib/pextlib1.0/Pextlib.dylib
  Reason: Incompatible library version:
Pextlib.dylib requires version 10.0.0 or later,
but libcurl.4.dylib provides version 7.0.0

As a first aid I tried to re-install `port' from `macports-base', but
I still get this error.

My questions.

* How can I restore (i.e., re-activate) all installed MacPorts
  packages?  Given that I'm on Lion, I would *really* avoid
  recompiling everything from scratch...

* Is there a simple way to protocol needed MacPorts packages?


Werner

Re: strange error code 71

[Werner LEMBERG]

>>  Exit code: 71
>>  Error: Failed to configure grep: configure failure: command
>>  execution failed
>
> [...] open a ticket and attach your full build log

Done.

  https://trac.macports.org/ticket/57814


Werner

strange error code 71

[Werner LEMBERG]

[d3b59876b6dde9a4a26135a9c6b59320080eb23f]

While doing

  sudo port -v install grep

I get

  sandbox-exec: sh: No such file or directory
  Command failed:  \
cd

"/opt/local/var/macports/build/_opt_macports_macports-ports_sysutils_grep/grep/work/grep-3.3"
 \
./configure --prefix=/opt/local --program-prefix=g 
  Exit code: 71
  Error: Failed to configure grep: configure failure: command execution failed

What does this mean?  What can I do?  Up to now all macports updates
were without problems...


Werner

Re: extractpdfmark build failure on 10.6

[Werner LEMBERG]

>> something like this from another port earlier today should do, until
>> this issue finally gets fixed in the compiler run deps.
>> 
>> > >
> 
> Small comment, but cctools works fine on all OSes versions, so there
> is really no need to put it inside a Darwin version check. In fact,
> for all OSes using Xcode 7 or older it provides a newer toolchain. I
> would just remove the Darwin version check..

I think the version check makes sense, since it is a reminder why the
code is there at all.  It is a gentle reminder that it should be
removed as soon the problem gets fixed at a higher level.

Apropos higher level & extractpdfmarks' Portfile: Shall I simply wait
until the c++11 portgroup file has been fixed?  I've already submitted

  https://github.com/macports/macports-ports/pull/2893

which would be unnecessary then.


Werner

Re: extractpdfmark build failure on 10.6

[Werner LEMBERG]

> something like this from another port earlier today should do, until
> this issue finally gets fixed in the compiler run deps.
> 
> 

Thanks!


Werner

extractpdfmark build failure on 10.6

[Werner LEMBERG]

Folks,


please have a look at this build log

  
https://build.macports.org/builders/ports-10.6_x86_64_legacy-builder/builds/83428

It fails with

  /usr/bin/ranlib: object:

libextractpdfmark-poppler-core.a(libextractpdfmark_poppler_core_a-pagemode.o)
malformed object (unknown load command 2)

Searching in the web, I've found a similar report w.r.t. ranlib:

  https://lists.macports.org/pipermail/macports-dev/2018-September/039282.html

It essentially says that `cctools' needs to be installed.  Is this a
dependency that I should add to extrapdfmark's Portfile?  Looking into
other Portfiles, maybe

  platform darwin 10 {
  depends_build-append   port:cctools
  }

is the right fix – is this sufficient to make macports use the newer
`ranlib' binary?

Another issue: extractpdfmark doesn't really need GhostScript for
compilation and execution; however, it will be optionally used for
some `make check' tests.  On the other hand, using the program makes
only sense if the calling Makefile (or whatever) feeds
extractpdfmark's output into GS.  Shall this be somehow reflected in
the Portfile, maybe an `optional dependency'?  If yes, how do I do
that?


Werner

Re: `port install' from github tarball fails

[Werner LEMBERG]

>> I have to use `sync' anyway since I'm running MacPorts directly
>> from the git repositories.

> If you mean you've compiled a newer version of macports from the
> macports-base git repository, then it's true that selfupdate won't
> update it, though it won't do any harm either; it'll still sync.

OK, thanks.


Werner

Re: `port install' from github tarball fails

[Werner LEMBERG]

> Don't be put off too much by this.  It takes only about 10 minutes
> to fix, if you care to.  I use it on every machine < 10.9 routinely.
> [...]

Thanks, Mojca and Ken!  Configuring with

  ./configure ac_cv_have_decl_rl_username_completion_function=yes \
  --enable-readline \
  --with-curlprefix=/opt/local

(cf. https://trac.macports.org/ticket/57160#ticket, which I've just
filed) gives me a `port' program that can download files from github.

> There is one hiccup. Updating macports with "sudo port selfupdate"
> does not respect the curlprefix.
> 
> So instead, "sync" macports instead of "selfupdating" it
> 
> sudo port -v sync

I have to use `sync' anyway since I'm running MacPorts directly from
the git repositories.


Werner

Re: git stash problem with `port sync'

[Werner LEMBERG]

> Mostly likely because the global settings are under your home area,
> whilst the checkout below is not.  [...]

> MacPorts automatically switches to the user owning the top-level
> ports tree directory to run the 'git pull'. [...]

Thanks for the tips.  It now works again.


Werner

git stash problem with `port sync'

[Werner LEMBERG]

Folks,


after doing various network hacks, calling `port -d sync' now fails.

  --->  Updating the ports tree
  Synchronizing local ports tree from file:///opt/macports/macports-ports
  DEBUG: /opt/local/bin/git pull --rebase --autostash
  DEBUG: system -W /opt/macports/macports-ports: /opt/local/bin/git pull 
--rebase --autostash

  *** Please tell me who you are.

  Run

git config --global user.email "y...@example.com"
git config --global user.name "Your Name"

  to set your account's default identity.
  Omit --global to set the identity only in this repository.

  fatal: unable to auto-detect email address (got '...@...')
  Cannot save the current index state
  Cannot autostash
  Command failed: /opt/local/bin/git pull --rebase --autostash
  Exit code: 1

Note that I already have set user name and e-mail adress globally, but
the error persists.  Manually calling `git stash' works also just fine.

Any ideas how to solve this?


Werner

Re: compilers on Lion

[Werner LEMBERG]

> If you try to avoid the troubles of installing a zillion compilers
> for the sake of installing poppler, what about switching to a super
> lightweight pplib (currently available only inside LuaTeX sources)?
> :) :) :)

I'm already using Emacs, I won't become an apostate :-)

> You can manually specify the compiler being used to compile a
> particular port.  [...]

Thanks for the explanations.  Meanwhile, I bit the bullet and let
macports install and compile whatever was necessary to get clang-6.0.
My knowledge (and interest) is too limited to fiddle around with the
intricate details.  After almost a day of compiling I got it...

>> OK.  BTW, I see on
>>
>>   https://libcxx.llvm.org/docs/UsingLibcxx.html#using-libc-with-gcc
>>
>> that gcc on MacOS actually *can* use libc++...
> 
> This means that someone would need to spend a bit of time to try to
> get it working correctly.

For developers and porters it might be worth the trouble IMHO.

> Apparently gcc8 fully supports C++11, but doesn't require a working
> C++11 compliant compiler to build (bootstrap?) itself.

Exactly.  It only needs C++98.

> (Maybe we should sometimes in fact allow using a bit more of gcc for
> bootstrapping purposes.)

At least for older platforms I second that – the clang people
themselves write that you can use gcc for bootstrapping.  However, it
is not me who is going to work on this.

>> And what about installing clang-7.0 instead of 5.0?  Will `port'
>> accept that for C++11 stuff as a default?
> 
> Yes.  The instructions were probably written when there was no newer
> clang compiler available.

I was told on this list some days ago that clang-7.0 is (still) too
new; clang-6.0 is thus preferred.


Werner

Re: compilers on Lion

[Werner LEMBERG]

>>> There _is_ indeed a way for gcc to build against libc++, as you
>>> pointed out in a subsequent email, and one of our contributors
>>> (Rene) went to the trouble of patching gcc to allow it to accept
>>> the "-stdlib=libc++" flag to make this easy.  But in the end, he
>>> could not get any purchase for his work either from MacPorts or
>>> from gcc, and so it went dormant.
>> 
>> Please post a link.  Is Rene's patch integrated into macports?
> 
> I think this is all of it
> .
> There may be some more to it in the associated Portfile.  Rene would
> be happy to hear someone found a good use for it.

Thanks for the link.  In case I get problems with lilypond I will have
a closer look.


Werner

Re: TeXLive distribution and macports

[Werner LEMBERG]

Hello Mojca!


> Warmly welcome to another addictive distraction (aka. MacPorts :),

So true...

> it's nice to see you here as well.

Thanks – it's time to meet again sometimes in the nearer future :-)

>> Ports that are ok with using MacTeX instead will have declared
>> their dependencies in such a way (using the bin: specification
>> instead of the port: specification) that MacTeX versions will
>> satisfy them.
>>
>> If you have MacPorts set up in this way, and you install a port,
>> and it still pulls in MacPorts texlive ports, then either those
>> ports' dependencies need to be fixed to use bin: instead of port:,
>> or there is a specific reason why those ports can't do it that way.
> 
> I wanted to reply something similar (but wouldn't be able to express
> myself as nicely as Ryan did).

Yeah, this sounds very promising!

> TeX Live is a bit special in the sense that it's a 5 GB(?) monster

More than 6GByte meanwhile...

> with only a bunch of command-line utilities (as opposed to providing
> libraries to link against, which would be prohibitive to make this
> kind of an exception) and advanced users would usually want their
> own special setup, or perhaps super up-to-date packages.

Exactly.  This year it is probably even more important than usual to
have access to an up-to-date repository since the LaTeX team decided
to make UTF-8 encoding the default in LaTeX, which causes quite a
number of packages to fail, and these failures are only detected now.

Additionally, packages for xetex and luatex are in most cases under
constant development.

> Before going into further detail I would like to point out that in
> the beginning I kind of tried to fight the same battle as you do now
> and tried to avoid installing TeX Live from MacPorts at all
> costs.

Hehe :-)

> We sometimes get requests for supporting installation of tlmgr only.
> This is something that's a lot more tricky in my eyes than just
> letting the user install TL himself and allowing some ports to
> forgive the dependency on texlive when that package is not
> present. (Code to prove us wrong is of course always welcome :)

I fully agree.

> 1.) Some ports like "dblatex" introduce a "+mactex" variant [...]

Yes.

> 2.) As Ryan already mentioned, one can specify a dependency in
> "bin:" form specification, so that either a local
> TeX installation or a port installed by the texlive port will
> satisfy the dependency.  If the specified binary doesn't exist,
> MacPorts will install the specified port. If it does exist, it
> won't install anything in additional.  See ftgl as an example of
> such a port.

Yes.  Looks very promising.

> The disadvantage is that it's nearly impossible to guarantee that
> the build will be successful in the case of a local TeX
> installation.

I can live with that, since it is an external dependency.  IMHO, it's
the job of the package's `configure' script to test that.

> [...]  For all those reasons I never bothered enabling external TL
> dependencies for asymptote and I'm still not sure if it is worth it.

Fortunately, the packages I'm interested in don't pose such problems.

> So in short: it definitely is possible to avoid installing any
> texlive-related packages from MacPorts.  The question is whether you
> care enough about this functionality to be willing to go into some
> extra troubles, and in any case there are probably a lot of ports
> that might need a patch to work as desired.

Yeah, will try to work on that.


Werner

Re: compilers on Lion

[Werner LEMBERG]

 * Where can I get a concise and up-to-date description of
 portfiles?  `portfiles.7' seems to be heavily out of date...
>>> 
>>> What would you like to know?
>> 
>> A list of all available variables/keywords, with a description.
> 
> Yup, that's supposed to be what's in the guide and the manpage.

I see that the guide contains much more details; hopefully, the
transition to AsciiDoc will yield a uniform output again in the near
future.

> There are also many portgroups (similar concept to include files
> in C), which, when included into a port, may add new variables or
> keywords of their own.  About half of the portgroups are documented
> in the guide.

And it would be great if the other half gets added too.  Speaking as
the FreeType maintainer, it costs me an incredible amount of time to
document the stuff I'm going to add or change – progress in FreeType
is thus quite slow since the non-programming tasks are so huge...


Werner

Re: TeXLive distribution and macports

[Werner LEMBERG]

>> Ah, I assumed too much knowledge, sorry.  TeXLive itself comes with
>> binaries for MacOS (both legacy platforms, i.e., 10.6-10.10, and
>> recent versions, i.e., 10.10-10.13).  By simply prepending the path
>> to those binaries to PATH, the `texlive-*' ports from MacPorts
>> would be completely hidden and thus useless, more or less: TeXLive
>> wouldn't use any data, binaries, or libraries from MacPorts.
>> 
>> However, to build various packages like `lilypond', `port' needs to
>> believe that some `texlive-*' ports are installed.  What certainly
>> works is to create a small port repository similar to René Bertin's
>> `macstrop' repository to override MacPorts with dummy ports.  My
>> question was whether macports itself provides a simpler solution
>> similar to `texlive-dummy-opensuse', where I have to install just a
>> single .rpm file...  I guess the answer is no.
> 
> Its quite simple.  The macports build of lilypond should be
> configured to use the MacPorts provided builds of TexLive.

I was still unclear, sorry.  To continue with lilypond as an example:
This program uses only TeXLive *programs* and data, but no libraries.
In general, this is true for all other programs within MacPorts that
depend on texlive ports.  It is thus irrelevant whether MacPorts
itself contains the necessary data and binaries, or whether they are
provided externally (in this case, by the native TeXLive
distribution).

> If these ports do not provide what is needed, then just provide an
> additional port for what is missing.

There are no misses.  My `problem' is that the `texlive-*' ports
within MacPorts use a few GByte, doubling everything native TeXLive
already provides!  I want to use native TeXLive directly so that I can
actually call `tlmgr' (or the SVN repository) to update the TeX stuff.
For this reason I want to have some dummy portfiles to make `port'
believe that the `texlive-*' ports are present.  This will take a few
kBytes only...


Werner

Re: TeXLive distribution and macports

[Werner LEMBERG]

> If I understand what you are asking correctly, you are asking how to
> setup a port that does nothing other than depend on other ports, so
> installing it drags in all the dependencies, in one go?

No, I want the opposite.  For example, I want to create a replacement
for `texlive-basic' that does nothing except fulfilling the
dependency.  This is, after installing this dummy `texlive-basic',
`port' shall believe that `texlive-basic' is indeed installed.

Ditto for all other `texlive-*' ports.  Ideally, I would like to have
all this stuff in a single file, to be automatically created from the
actual list of `texlive-*' ports as in texlive-dummy-opensuse,
cf. 
https://github.com/rolfn/texlive-dummy-opensuse/blob/ba0bc1e2f866c379f750046439b6f4e40725805f/Makefile#L61
and following lines.

> If so we have plenty of these in MacPorts.  [...]

Thanks; I've already seen such meta-packages.  One of them is actually
`texlive' itself :-)


Werner

TeXLive distribution and macports

[Werner LEMBERG]

My computer for daily use is an openSuSE GNU/Linux box; for TeX
processing, however, I'm directly using tlmgr.[*] Regardless of this I
don't have any dependency issues with `zypper', openSuSE's package
manager, since I'm using the nifty `texlive-dummy-opensuse' package,

  https://github.com/rolfn/texlive-dummy-opensuse.git   .

This package tells zypper that all TeXLive packages provided by
openSuSE are installed, without installing them actually.

I would like to have something similar for MacPorts.  My questions:

* Has anyone already written such a dummy package?

* If not, how can I construct `empty packages' that only exist to
  fulfill package dependencies?


Werner


[*] To be more precise, I don't use tlmgr at all but directly
TeXLive's SVN repository.  However, this distinction doesn't
matter here.

Re: compilers on Lion

[Werner LEMBERG]

> As Chris mentioned, ports use a compiler of their choosing, not of
> yours.

Yeah, it takes time to let this paradigm change sink in. :-)

> In fact, it takes the unusual and not-recommended step of completely
> discarding MacPorts base's list of preferred compilers and
> substituting its own list, which begins with MacPorts gcc6, so
> that's the compiler it will use.  Probably gcc6 was the latest
> stable version when that list was last updated, so it would be
> reasonable to add gcc7 and gcc8 to the list.

Yes.  I will do this.

> The best solution would be to fix lilypond so that it builds with
> clang, but that's something to be discussed with the developers of
> lilypond.

I'm listening :-) Unfortunately, my C++ capabilities are quite
limited, and normally we do cross-compilation to create a lilypond
binary for the Mac.  Since our personal resources are very limited,
there isn't a high priority to make lilypond compile with clang – of
course we gladly accept patches.

Fortunately, macports provides guile 1.8.8, since guile 2.2.x doesn't
reliably work with lilypond (and vice versa).  This is becoming a very
serious issue since most GNU/Linux distributions have already dropped
1.8.8 or will do so in the very near future...

>> * I'm missing the ability to say
>> 
>>port select --set emacs emacs23   .
> 
> If you install the emacs port, it will install /opt/local/bin/emacs;
> assuming /opt/local/bin precedes /usr/bin in your PATH, as it will
> by default after you install MacPorts, the emacs port's emacs binary
> will be used instead of Lion's older emacs binary.

Ah, I missed to type `hash -r'; I thought that, similar to gcc,
macports doesn't provide an `emacs' alias.  Now everything works fine.

>> * It's impossible to guess the difference between the `emacs' and
>>  `emacs-app' port from the output of `port info'.  [...]
>
> Please file bug reports against those ports if changes are needed.

Will do.

>>  *Four* compilers are necessary for poppler?
> 
> I agree this is highly undesirable.  It seems to me like it should
> be possible to significantly reduce that list, but I have not
> analyzed the problem in depth.

I think one part of the problem is that `libomp' is a separate
package.  Since recent versions of clang include it, the artificial
splitting automatically introduces `clang-3.7' as a dependency,
regardless which clang version gets installed...

> Certainly, I think we have bugs in our compiler selection process.
> Especially on systems older than OS X Mavericks, while installing
> ports, you may see warnings to the effect that all compilers were
> blacklisted, but the build succeeds anyway.

Until now I haven't experienced this – but I guess I will see that
soon...

> An overhaul of the MacPorts base compiler selection process was
> proposed here:
> 
> https://github.com/macports/macports-base/pull/88
> 
> You might try recompiling MacPorts base from that PR to see if its
> new compiler selection process results in any improvements for this
> problem.

Looks interesting.  Hopefully, I find some time to test it!

>> * Where can I get a concise and up-to-date description of
>>  portfiles?  `portfiles.7' seems to be heavily out of date...
> 
> What would you like to know?

A list of all available variables/keywords, with a description.

> If portfile.7 or the guide are out of date (and I have no doubt they
> are), let us know in what ways (by filing bug reports) so that
> someone can fix them, or you can fork our repositories, make the
> needed changes and send pull requests.

Will try to file reports.


Werner

compilers on Lion

[Werner LEMBERG]

Folks,


macports newbie here :-)

I'm running a Lion box and I'm running macports from git, which works
just fine.  I've followed the advice on LibcxxOnOlderSystems and did

  cxx_stdlib libc++
  buildfromsourcealways.

Attached you can see the list of software that I've installed so far.
In particular, I've installed `gcc8' and set it up as the default gcc
compiler, which I think is a good choice later on for lilypond-devel,
which doesn't like to be compiled with clang, AFAIK.  As the
maintainer of FreeType and ttfautohint I'm also curious whether my
stuff works correctly – there are some glitches here and there which I
want to fix eventually with macport push requests as soon as I'm more
acquainted with the system.

Note that I'm an old GNU/Linux user; I only work on the Mac for
software testing.

Now to my problems.  I stumbled across various issues for which I
can't find an explanation or solution in the net.  Some of them should
probably be directed directly to the tracker I guess...

* The concept of `subports' is not mentioned in `man port'.  Where is
  it described?  I can more or less deduce now how it works, but a
  formal description would be nice.

* I'm missing the ability to say

port select --set emacs emacs23   .

  I see that there is https://trac.macports.org/ticket/56949, but even
  then it would be nice to have this since Lion comes with its own
  emacs binary.

* It's impossible to guess the difference between the `emacs' and
  `emacs-app' port from the output of `port info'.  The description of
  the former should mention that it is TTY only, while the latter uses
  the GUI.  Additionally, `emacs --help' contains a bunch of options
  for controlling the (X11) display, which are completely useless of
  course if Emacs can only be run on the terminal...

* Saying

port install poppler

  returns

--->  Computing dependencies for poppler
The following dependencies will be installed: 
 clang-3.7
 clang-3.9
 clang-4.0
 clang-5.0
 libomp
 llvm-3.7
 llvm-3.9
 llvm-4.0
 llvm-5.0.

  For me, this looks like a bad joke!  *Four* compilers are necessary
  for poppler?  Additionally, it seems that since clang 3.8 it is no
  longer necessary to have a separate `libomp' package at all, cf.

https://openmp.llvm.org/.

  Theoretically, my already installed gcc8 should compile this package
  just fine, right?  Why doesn't `port' consider it?  Looking into
  poppler's Portfile I don't see any compilers blacklisted.

  Please advise how to escape this dependency hell...

* Where can I get a concise and up-to-date description of portfiles?
  `portfiles.7' seems to be heavily out of date...

I will certainly find more issues soon, but this e-mail is already too
long :-)


Werner

autoconf @2.69_5 (active)
autoconf-archive @2018.03.13_0 (active)
automake @1.16.1_0 (active)
bison @3.1_0 (active)
bison-runtime @3.1_0 (active)
bzip2 @1.0.6_0 (active)
cairo @1.14.12_0+quartz+x11 (active)
cctools @895_7+llvm34 (active)
clang-3.4 @3.4.2_12+analyzer+arm_runtime (active)
clang_select @2_0 (active)
cmake @3.12.1_0 (active)
curl @7.61.1_0+ssl (active)
curl-ca-bundle @7.61.1_1 (active)
db48 @4.8.30_4 (active)
dejavu-fonts @2.37_0 (active)
djvulibre @3.5.27_0 (active)
docbook-xml @5.0_3 (active)
docbook-xml-4.1.2 @5.0_1 (active)
docbook-xml-4.2 @5.0_1 (active)
docbook-xml-4.3 @5.0_1 (active)
docbook-xml-4.4 @5.0_1 (active)
docbook-xml-4.5 @5.0_1 (active)
docbook-xml-5.0 @5.0_1 (active)
emacs @26.1_2 (active)
emacs-app @26.1_3 (active)
expat @2.2.6_1 (active)
fftw-3 @3.3.8_0 (active)
flex @2.6.4_0 (active)
fontconfig @2.13.1_0 (active)
fontforge @20120731_3 (active)
freetype @2.9.1_0 (active)
fribidi @0.19.7_1 (active)
gcc8 @8.2.0_0 (active)
gcc_select @0.1_8 (active)
gd2 @2.2.5_0+x11 (active)
gdbm @1.16_0 (active)
gdk-pixbuf2 @2.36.12_0+x11 (active)
gettext @0.19.8.1_0 (active)
ghostscript @9.24_0+x11
ghostscript @9.24_1+x11 (active)
giflib @4.2.3_0+x11 (active)
git @2.18.0_0+credential_osxkeychain+doc+pcre+perl5_26 (active)
glib2 @2.56.2_0+x11 (active)
gmp @6.1.2_1 (active)
gnome-common @3.18.0_0 (active)
gnutls @3.5.19_0+doc (active)
gobject-introspection @1.56.1_1 (active)
gperf @3.1_0 (active)
graphite2 @1.3.9_0 (active)
graphviz @2.40.1_1+pangocairo+x11 (active)
groff @1.22.3_5 (active)
gts @0.7.6_3 (active)
guile18 @1.8.8_6 (active)
harfbuzz @1.8.8_0 (active)
harfbuzz-icu @1.8.8_0 (active)
help2man @1.47.6_0 (active)
icu @58.2_2 (active)
ilmbase @2.2.1_0 (active)
ImageMagick @6.9.9-40_2+x11 (active)
intltool @0.51.0_4 (active)
isl @0.18_0 (active)
jasper @2.0.14_0 (active)
jbig2dec @0.14_0
jbig2dec @0.15_0 (active)
jbigkit @2.1_0 (active)
joe @4.6_0 (active)
jpeg @9c_0 (active)
kerberos5 @1.16.1_0 (active)
lcms2 @2.9_1 (active)
ld64 @3_1 (active)
ld64-latest @274.2_2+llvm34 (active)
libarchive @3.3.2_1 (active)
libcomerr @1.44.3_0 (active)
libcroco @0.6.12_0 (active)
libcxx @5.0.1_2+universal (active)
libedit