Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#38938 closed update (fixed)

Update cadabra and modglue

Reported by: kasper.peeters@… Owned by: larryv (Lawrence Velázquez)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: cooljeanius (Eric Gallager)
Port: cadabra modglue

Description

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).

Attachments (5)

Portfile.modglue (656 bytes) - added by kasper.peeters@… 8 years ago.
Portfile.cadabra (2.1 KB) - added by kasper.peeters@… 8 years ago.
diff_modglue (1016 bytes) - added by kasper.peeters@… 8 years ago.
Unified diff for Portfile for modglue
diff_cadabra (1.9 KB) - added by kasper.peeters@… 8 years ago.
Unified diff for Portfile for cadabra
texlive-latex-contents.txt (94.2 KB) - added by larryv (Lawrence Velázquez) 8 years ago.
contents of texlive-latex @30738_0+doc

Download all attachments as: .zip

Change History (28)

Changed 8 years ago by kasper.peeters@…

Attachment: Portfile.modglue added

Changed 8 years ago by kasper.peeters@…

Attachment: Portfile.cadabra added

comment:1 Changed 8 years ago by mf2k (Frank Schima)

Keywords: modglue cadabra removed
Owner: changed from macports-tickets@… to gwright@…
Port: modglue added
Summary: Request to update portfileUpdate cadabra and modglue
Version: 2.1.3

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.

Changed 8 years ago by kasper.peeters@…

Attachment: diff_modglue added

Unified diff for Portfile for modglue

Changed 8 years ago by kasper.peeters@…

Attachment: diff_cadabra added

Unified diff for Portfile for cadabra

comment:2 Changed 8 years ago by kasper.peeters@…

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

comment:3 Changed 8 years ago by 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.

comment:4 in reply to:  3 Changed 8 years ago by 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
}

comment:5 Changed 8 years ago by 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...).

Last edited 8 years ago by kasper.peeters@… (previous) (diff)

comment:6 in reply to:  5 ; Changed 8 years ago by 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.

comment:7 in reply to:  6 Changed 8 years ago by 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 ;-)

comment:8 Changed 8 years ago by 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.

comment:9 Changed 8 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:10 Changed 8 years ago by larryv (Lawrence Velázquez)

Owner: changed from gwright@… to larryv@…
Status: newassigned

I’ll take care of this in the morning.

comment:11 Changed 8 years ago by 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?

comment:12 Changed 8 years ago by 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.

comment:13 in reply to:  12 Changed 8 years ago by 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?

comment:14 Changed 8 years ago by 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).

comment:15 in reply to:  14 Changed 8 years ago by 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?

comment:16 Changed 8 years ago by 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'.

comment:17 in reply to:  16 Changed 8 years ago by 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.

Changed 8 years ago by larryv (Lawrence Velázquez)

Attachment: texlive-latex-contents.txt added

contents of texlive-latex @30738_0+doc

comment:18 Changed 8 years ago by kasper.peeters@…

Ok, that should do.

comment:19 Changed 8 years ago by larryv (Lawrence Velázquez)

Resolution: fixed
Status: assignedclosed

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.

comment:20 in reply to:  19 Changed 8 years ago by larryv (Lawrence Velázquez)

Replying to larryv@…:

Let me know if there are any problems.

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

comment:21 Changed 8 years ago by 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!

comment:22 in reply to:  21 Changed 8 years ago by 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.

comment:23 in reply to:  21 Changed 8 years ago by larryv (Lawrence Velázquez)

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

Note: See TracTickets for help on using tickets.