graphviz @2.50.0+universal: malloc: *** error for object 0x10201f2c8: Non-aligned pointer being freed

[barracuda156]

Obviously I had to add muniversal 1.0, since it requires C++ 2011, and gcc11 (or any other supporting the standard) does not accept multiple arch flags.

Then the build fails at destroot with:

xinstall: mkdir /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_graphviz/graphviz/work/destroot-powerpc//opt/local/var/spool
xinstall: mkdir /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_graphviz/graphviz/work/destroot-powerpc//opt/local/www
xinstall: mkdir /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_graphviz/graphviz/work/destroot-powerpc//usr
xinstall: mkdir /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_graphviz/graphviz/work/destroot-intel
xinstall: mkdir /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_graphviz/graphviz/work/destroot-ppc-intel
xinstall: mkdir /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_graphviz/graphviz/work/destroot
dot(50880) malloc: *** error for object 0x10201f2c8: Non-aligned pointer being freed
*** set a breakpoint in malloc_error_break to debug
dot(50880) malloc: *** error for object 0x10201e698: Non-aligned pointer being freed
*** set a breakpoint in malloc_error_break to debug
dot(50880) malloc: *** error for object 0x10201e5b8: Non-aligned pointer being freed
*** set a breakpoint in malloc_error_break to debug
dot(50880) malloc: *** error for object 0x10201e628: Non-aligned pointer being freed
*** set a breakpoint in malloc_error_break to debug
dot(50880) malloc: *** error for object 0x10201e428: Non-aligned pointer being freed
*** set a breakpoint in malloc_error_break to debug
dot(50880) malloc: *** error for object 0x10201e2d8: Non-aligned pointer being freed
*** set a breakpoint in malloc_error_break to debug
dot(50880) malloc: *** error for object 0x10201e198: Non-aligned pointer being freed
*** set a breakpoint in malloc_error_break to debug
dot(50880) malloc: *** error for object 0x10201e238: Non-aligned pointer being freed
*** set a breakpoint in malloc_error_break to debug
dot(50880) malloc: *** error for object 0x10201e008: Non-aligned pointer being freed
*** set a breakpoint in malloc_error_break to debug
dot(50880) malloc: *** error for object 0x10201f148: Non-aligned pointer being freed
*** set a breakpoint in malloc_error_break to debug
dot(50880) malloc: *** error for object 0x10201f448: Non-aligned pointer being freed
*** set a breakpoint in malloc_error_break to debug
dot(50880) malloc: *** error for object 0x10201f458: Non-aligned pointer being freed
*** set a breakpoint in malloc_error_break to debug
dot(50880) malloc: *** error for object 0x10201f490: Non-aligned pointer being freed (2)
*** set a breakpoint in malloc_error_break to debug

[kencu (Ken)]

this is the standard error you see with the bad libgcc.

use this workaround ​https://github.com/macports/macports-ports/blob/b159711ad932b653f146364b0db4179a5ed44cf8/_resources/port1.0/group/legacysupport-1.1.tcl#L32 to fix it until Iain gets around to the real fix.

[ryandesign (Ryan Carsten Schmidt)]

intel destroot added when build is for ppc+ppc64

All destroot folders are always created on all architectures. It simplifies the implementation of the muniversal portgroup to do so.

Obviously I had to add muniversal 1.0, since it requires C++ 2011, and gcc11 (or any other supporting the standard) does not accept multiple arch flags.

As I've mentioned elsewhere I don't think we should be adding the muniversal portgroup manually to every port that uses gcc on PowerPC systems just to accommodate universal builds on PowerPC. Either MacPorts base should do so automatically, or gcc should be fixed to accept multiple -arch flags. I would prefer the latter solution since using the muniversal portgroup can have other consequences with certain ports' build systems which include build failures.

this is the standard error you see with the bad libgcc.

use this workaround ​​https://github.com/macports/macports-ports/blob/b159711ad932b653f146364b0db4179a5ed44cf8/_resources/port1.0/group/legacysupport-1.1.tcl#L32 to fix it until Iain gets around to the real fix.

I'm not familiar with the problem you're referring to or the workaround you're suggesting. Are you saying he should add legacysupport.redirect_bins yes to the graphviz portfile?

[kencu (Ken)]

I'm not familiar with the problem you're referring to or the workaround you're suggesting. Are you saying he should add legacysupport.redirect_bins yes to the graphviz portfile?

It’s several years now this has been needed at times, but only on < 10.6 linking against libstdc++.dylib, so you likely didn’t notice.

See ​https://github.com/macports/macports-ports/blob/03071a773df7c47ed314a4dd92011771fe8f9cae/devel/cmake/Portfile#L56 for ticket references and usage in a Portfile.

[barracuda156]

Replying to ryandesign:

As I've mentioned elsewhere I don't think we should be adding the muniversal portgroup manually to every port that uses gcc on PowerPC systems just to accommodate universal builds on PowerPC. Either MacPorts base should do so automatically, or gcc should be fixed to accept multiple -arch flags. I would prefer the latter solution since using the muniversal portgroup can have other consequences with certain ports' build systems which include build failures.

I am certainly not gonna try pushing muniversal addition to every port that requires it; indeed, some global fix is needed. Fixing gcc would be awesome, but apparently it is not on Iain’s priority list, and no one else can do it (well, I can’t, too advanced stuff).

[barracuda156]

Replying to ryandesign:

intel destroot added when build is for ppc+ppc64

All destroot folders are always created on all architectures. It simplifies the implementation of the muniversal portgroup to do so.

On a side-note, thanks for this, then my Python universal fix-up may not have any issue. (It worked totally fine, but I thought that I messed smth up with extra destroot folders.)

[kencu (Ken)]

Adding the muniversal PG in base would be hard to make work reliably. Too many Portfile tweaks are often needed to support it.

adding the muniversal PG to 25,000 ports to support building ppc/ppc64 on LeopardPPC is rather a stretch of patience.

[kencu (Ken)]

putting effort into fixing driverdriver.c and possibly having gcc use libc++ would be more fruitful.

[barracuda156]

Replying to kencu:

putting effort into fixing driverdriver.c and possibly having gcc use libc++ would be more fruitful.

Okay, Ken, could you advise me whether a) it is feasible in principle for someone who is not Iain or yourself (I am not an expert in compilers, not at all); b) if yes, what material should I read to gain a relevant expertise (in a case you can refer to something specific, of course I can do googling on my own).

[kencu (Ken)]

Sergey, what you bring to the table is great enthusiasm and willingness to put time in. Iain brings great expertise but little time available. I bring neither, but perhaps might fall in between. There are others interested too, as you have seen.

The first thing for you to do is understand exactly what is needed. Using apple-gcc42 from MacPorts, built it universal as ppc/ppc64 and use it to built simple universal software (eg a simple hello.c executable). See and understand what driverdriver.c does to make this work. It is actually quite straitforward. Read the driverdriver.c code until you understand what parts are in it, and what each part does.

Then choose one single newer gcc version to work on. I would say gcc7 perhaps as that is what macports uses now. There is already a ticket where a very smart person has worked on updating driverdriver.c for newer gcc versions here

#48857

and see here for how to build and use it (only the driverdriver.c part is needed for now)

​https://github.com/devernay/macportsGCCfixup

that file needs some updating to work with gcc7. Once you are to that point, people will probably contribute small fixes if the effort gets stuck.

Fred got this far, but then got bogged down in politics, you might say. I have a feeling you might blast through that.

Once gcc7 works, then update it to work with gcc11.

[barracuda156]

Replying to kencu:

Thank you very much for the advice and references, I will see what I could do. Any testing is feasible next month only, but I will try to cope with a theoretical part to some extent in the meanwhile.

[mascguy (Christopher Nielsen)]

Reassigning to Sergey, who's working on this.