Update cadabra and modglue

[kasper.peeters@…]

I am the author of modglue and cadabra, which currently both fail to build on Mountain Lion. Attached are two updated port files, which together with the updated sources, are all that is needed to make these ports work again. Can these please be included in the repositories? The diffs are no longer necessary. Thanks.

(Greg Wright used to do this for me in the past, but I haven't been able to reach him for some time).

[mf2k (Frank Schima)]

In the future, please Cc the Macports maintainer(s).

Please instead attach unified diffs of the Portfiles so we can easily see what changes you have made.

[kasper.peeters@…]

Unified diff for Portfile for modglue

[kasper.peeters@…]

Unified diff for Portfile for cadabra

[kasper.peeters@…]

Unified diffs are now attached. Apologies for not CC'ing Greg (sorry; I'm new here).

[kasper.peeters@…]

Note: cadabra needs a relatively new gcc, and I probably used a bit of a hack to force it to pick Apple's gcc-4.2. Neither clang nor llvm produce working code (for clang because of unsupported c++ features, for llvm I am not sure why). Building with a non-Apple gcc made the code link to two different libstdc++ versions at the same time, leading to malloc errors.

If there is a clean way to enforce building with the Apple gcc that makes it pick up precisely the version of libstdc++ to which all other Macports libraries are linked, without enforcing a specific version like I did, feel free to modify the Portfile.

[larryv (Lawrence Velázquez)]

Replying to kasper.peeters@…:

Note: cadabra needs a relatively new gcc, and I probably used a bit of a hack to force it to pick Apple's gcc-4.2. Neither clang nor llvm produce working code (for clang because of unsupported c++ features, for llvm I am not sure why).

There is no compiler called llvm. I assume you mean LLVM-GCC, which is llvm-gcc-4.2.

apple-gcc-4.2 represents the compiler provided by MacPorts’ apple-gcc42 port. Setting configure.compiler to this value precludes the use of Xcode’s GCC 4.2 on systems that have it. If Apple’s GCC 4.2 really is the only usable compiler, you should do this instead:

compiler.whitelist  gcc-4.2 apple-gcc-4.2

if {${configure.compiler} eq "apple-gcc-4.2"} {
    depends_build-append    port:apple-gcc42
}

[kasper.peeters@…]

Yes, I meant llvm-gcc.

I don't necessarily need apple-gcc-4.2, it can be any later version, but it has to be the apple one otherwise the resulting binary gets linked to two different libstdc++ libraries and that leads to all sorts of malloc errors. Or at least I did not figure out a way to use a non-apple-gcc compiler without running into this problem.

I have gcc-4.2 here as well, but if I remember correctly that also produced the double-libstdc++ problem.

So my question is really: how do I restrict to apple-gcc without restricting to a specific version?

(It took me quite some time to pin this down. It may thus be a good idea to discuss this problem somewhere more prominently on the Macports pages that discuss compiler choices, as I am apparently not the only one puzzled by these weird malloc errors. In general, as soon as you start excluding the default C++ compiler, all hell breaks loose...).

[larryv (Lawrence Velázquez)]

Replying to kasper.peeters@…:

I have gcc-4.2 here as well, but if I remember correctly that also produced the double-libstdc++ problem.

Let’s make sure we’re talking about the same things. As far as MacPorts compiler specifications are concerned, gcc-4.2 refers to Apple’s custom GCC 4.2 included with Xcode. Apple’s custom GCC 4.2 provided by MacPorts’s apple-gcc42 port is referred to as apple-gcc-4.2. FSF GCC 4.2 provided by the MacPorts gcc42 port is referred to as macports-gcc-4.2.

I see no reason why gcc-4.2 should compile your software differently than apple-gcc-4.2. They are more or less the same software.

So my question is really: how do I restrict to apple-gcc without restricting to a specific version?

The only versions of Apple’s GCC are 4.0 and 4.2; there are no newer ones, and there never will be. So I think the real question is, how do we (or you) fix your build process so that it does not link to multiple libstdc++ implementations?

(It took me quite some time to pin this down. It may thus be a good idea to discuss this problem somewhere more prominently on the Macports pages that discuss compiler choices, as I am apparently not the only one puzzled by these weird malloc errors. In general, as soon as you start excluding the default C++ compiler, all hell breaks loose...).

You may want to post a message to the macports-dev mailing list.

[kasper.peeters@…]

I see no reason why gcc-4.2 should compile your software differently than apple-gcc-4.2. They are more or less the same software.

I agree, they all probably produce the same code. The problem is linking to libstdc++. If one library used by cadabra links to a different libstdc++ than cadabra itself, malloc errors occur. It would have made sense if all gcc-4.2 versions lead to the same linking pattern, but as far as I remember that is not true. (It may still be that I did something wrong, but let's take this to the mailing list, there definitely is an issue).

The only versions of Apple’s GCC are 4.0 and 4.2; there are no newer ones, and there never will be. So I think the real question is, how do we (or you) fix your build process so that it does not link to multiple libstdc++ implementations?

Fair enough. I think this is an issue for macports-dev, as it concerns other packages as well, and it isn't really something I want to spend a lot of time on anyway.

For the time being, I would suggest using my Portfile as-is, because the version in the repos does not lead to a working binary at all, and it turns out I have quite a few more waiting users on OS X than I thought ;-)

[kasper.peeters@…]

Could someone please have a look at this and (if there are no further issues) upload these changes to the repos?

The version in the repos right now does not work at all and this fix, while sub-optimal, at least leads to a working binary.

Many thanks.

[cooljeanius (Eric Gallager)]

Cc Me!

[larryv (Lawrence Velázquez)]

I’ll take care of this in the morning.

[larryv (Lawrence Velázquez)]

I updated modglue in r108085.

The cadabra port depends on texlive, which is a metaport that does not install anything. Does it need any TeX Live ports in addition to texlive-bin-extra?

[kasper.peeters@…]

It needs the 'dvipng' program as well as the 'breqn.sty' style file; am not sure what is the minimal depends entry that gives me that.

[larryv (Lawrence Velázquez)]

Replying to kasper.peeters@…:

It needs the 'dvipng' program as well as the 'breqn.sty' style file; am not sure what is the minimal depends entry that gives me that.

Fortunately, I happen to have both present. You can use port provides FOO to determine which port, if any, provides the file “FOO”.

% find /opt/local -type f \( -name dvipng -or -name breqn.sty \) -exec port provides {} + 2> /dev/null
/opt/local/bin/dvipng is provided by: dvipng
/opt/local/share/texmf-texlive/tex/latex/mh/breqn.sty is provided by: texlive-latex-recommended
%

Do they need to be present at build time, or only at runtime?

[kasper.peeters@…]

Needed at build time with the present Portfile. Can be dropped from build dependencies by adding the '--disable-runtime-dependency-check' flag to configure. Sorry, I see that I messed that up (am not usually on a Mac).

[larryv (Lawrence Velázquez)]

Replying to kasper.peeters@…:

Needed at build time with the present Portfile. Can be dropped from build dependencies by adding the '--disable-runtime-dependency-check' flag to configure. Sorry, I see that I messed that up (am not usually on a Mac).

No worries. To be clear, are those in addition to something from texlive-bin-extra, or are those the only TeX Live components needed?

[kasper.peeters@…]

It does need a basic pdflatex installation to work, but I have no idea how to specify that. On linux distributions I usually require 'the basic texlive without any fancy packages + dvipng + whatever package that contains breqn'.

[larryv (Lawrence Velázquez)]

Replying to kasper.peeters@…:

It does need a basic pdflatex installation to work, but I have no idea how to specify that. On linux distributions I usually require 'the basic texlive without any fancy packages + dvipng + whatever package that contains breqn'.

If you just need to be able to run pdflatex, you should be okay with depending on texlive-latex. I’m attaching a list of the contents of my texlive-latex @30738_0+doc installation.

[larryv (Lawrence Velázquez)]

contents of texlive-latex @30738_0+doc

[kasper.peeters@…]

Ok, that should do.

[larryv (Lawrence Velázquez)]

Updated in r108122:108123, with some changes:

• Added license.
• Switched to RIPEMD160 and SHA256 checksums.
• Didn’t bother blacklisting any compilers because explicitly setting configure.compiler disables blacklists and whitelists.
• Replaced the weird “maintainer_tests” variant and post-build script by enabling the test phase. To run the tests, use port test.
• Obsoleted the “no_gui” variant with a “gui” variant that’s enabled by default.
• Narrowed down the TeX Live dependencies.
• Keep explicit execution of ${prefix}/bin/texhash in post-activate to make sure it runs MacPorts’ texhash.

Let me know if there are any problems.

[larryv (Lawrence Velázquez)]

Replying to larryv@…:

Let me know if there are any problems.

That is, after grabbing r108138 and r108140. Oy vey.

[kasper.peeters@…]

I'm a total newbie at this: how long does it take for this to be available to mere mortals? Do they need to do something special? Thanks!

[larryv (Lawrence Velázquez)]

Replying to kasper.peeters@…:

I'm a total newbie at this: how long does it take for this to be available to mere mortals? Do they need to do something special? Thanks!

Ordinarily a selfupdate after 30 minutes would suffice, but we’re currently having issues that have yet to be resolved.

[larryv (Lawrence Velázquez)]

#39652 has been resolved, so the fixes are available now.