neomutt @20160916_3: build fails on 10.5 and 10.6 due to autoconf linking bug

[lbschenkel (Leonardo Brondani Schenkel)]

From buildbot: ​https://build.macports.org/builders/ports-10.5_ppc_legacy-watcher/builds/632 ​https://build.macports.org/builders/ports-10.5_ppc_legacy-builder/builds/5905/steps/install-port/logs/stdio

I reported that to upstream (NeoMutt) here: ​https://github.com/neomutt/neomutt/issues/168

The maintainer of NeoMutt has said that apparently it's an autoconf bug. I don't know yet if the bug was introduced in NeoMutt or in Mutt nor why it only triggers on OS X 10.5 PPC. He said that it'll be fixed in the next NeoMutt release which is bound to happen in the next few days.

I'm opening this ticket just to keep track of this issue.

[ken-cunningham-webuse]

Hi. It's not just on 10.5 PPC:

also 10.6 64bit intel

/opt/local/bin/clang-mp-3.7  -pipe -Os -arch x86_64  -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 -stdlib=libc++ -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -o mutt_dotlock mutt_dotlock.o strndup.o strnlen.o wcscasecmp.o regex.o 
Undefined symbols for architecture x86_64:
  "_safe_malloc", referenced from:
      _strndup in strndup.o
ld: symbol(s) not found for architecture x86_64

comparing link lines from a successful build on 10.11

/usr/bin/clang  -pipe -Os -arch x86_64 -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64-L/opt/local/lib \
 -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -o pgpring pgppubring.o pgplib.o lib.o extlib.o sha1.o md5.o pgppacket.o \
ascii.o regex.o -lintl -liconv 

and an unsucessful build on 10.6

/opt/local/bin/clang-mp-3.7  -pipe -Os -arch x86_64  -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 -stdlib=libc++ -L/opt/local/lib \
 -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -o pgpring pgppubring.o pgplib.o lib.o extlib.o sha1.o md5.o pgppacket.o \
ascii.o strndup.o strnlen.o wcscasecmp.o regex.o -lintl -liconv 

Undefined symbols for architecture x86_64:
  "_safe_malloc", referenced from:
      _strndup in strndup.o
ld: symbol(s) not found for architecture x86_64

it looks like the autoconf - added strndup.o, strnlen.o, and wcscasecmp.o haven't pulled in the extra library they need to link against to find _safe_malloc.

So it's an upstream bug, as he says.

[lbschenkel (Leonardo Brondani Schenkel)]

Right. It's strange that I only got e-mails from the buildbot regarding the 10.5 PPC build and not any other one.

Is there a good/easy way in which I can find the builds for other version/arch combinations in the buildbot? If I could compare the outputs in the way you did I could have provided much more contextual information to upstream.

[ryandesign (Ryan Carsten Schmidt)]

Replying to leonardo.schenkel@…:

Is there a good/easy way in which I can find the builds for other version/arch combinations in the buildbot?

Not at this time. Hopefully that will be integrated with a new MacPorts web site in the future.

If I could compare the outputs in the way you did I could have provided much more contextual information to upstream.

Here are the buildbot's failed builds on 10.6:

• ​https://build.macports.org/builders/ports-10.6_i386_legacy-builder/builds/6705
• ​https://build.macports.org/builders/ports-10.6_x86_64_legacy-builder/builds/5923

And its successful build on 10.7:

• ​https://build.macports.org/builders/ports-10.7_x86_64_legacy-builder/builds/11052

[ryandesign (Ryan Carsten Schmidt)]

Replying to leonardo.schenkel@…:

It's strange that I only got e-mails from the buildbot regarding the 10.5 PPC build and not any other one.

We only just got email notifications working on the buildbot. I think they were not yet working by the time the Intel build workers completed their neomutt builds. The PowerPC worker is much slower and has been busy building a batch of other ports for several weeks, so it got to neomutt later than the others, by which time we had set up the email notifications.

[ken-cunningham-webuse]

When you see errors like this on builds of open source software on systems prior to 10.7, it's almost always due to a short list of library enhancements Jeremy (the MacPorts deep-guts-of-the-system genius and apple compiler engineer) added to libc++ 10.7 that software has come to expect over time.

"memmem, strndup, strnlen, strncpy, getline, getdelim, dprintf, and few others", as per his posting on another ticket.

it's quite easy to replace these functions, but can be a pain to do it manually. Autoconf usually does it quite well.

I've been working on a library to add them across the board for all builds, automagically, that might someday come out of the file cabinet.

[dgonyier (Dwaine Gonyier)]

Cc Me!

[lbschenkel (Leonardo Brondani Schenkel)]

I don't know how to trigger a build manually, so could somebody please check if the new release on #52485 fixes the build?

[larryv (Lawrence Velázquez)]

I applied the 20161002 update in r153493, which is available from Subversion immediately and should be available from rsync shortly.

[larryv (Lawrence Velázquez)]

The update succeeded on the 10.6 buildslaves (​x86_64, ​i386).

The 10.5 buildslave is extremely backlogged, so someone with access to a 10.5 machine will have to test it.

[ken-cunningham-webuse]

thanks for getting this all fixed up. It looks like a great application. I installed it and I'm working my way through the documentation now. I appreciate the extra bit of effort you went to to find out the issues with the older systems and help get them resolved. In the end, it looks like it was a bug the author was happy to have fixed.

[larryv (Lawrence Velázquez)]

I’m going to assume this works on Leopard now. Anyone who observes otherwise can reopen this ticket.

[dgonyier (Dwaine Gonyier)]

Replying to larryv@…:

I’m going to assume this works on Leopard now. Anyone who observes otherwise can reopen this ticket.

I tried installing with

$ uname -m
Power Macintosh

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.5.8
BuildVersion:   9L31a

$ sudo port install neomutt@+compress+gdbm+headercache+idn+imap+pop+sidebar+smtp+ssl

and the install completes successfully, but running mutt causes a "bus error". I tried using gdb to get a strack trace (not an expert)

bash-3.2$ gdb mutt
GNU gdb 6.3.50-20050815 (Apple version gdb-967) (Tue Jul 14 02:15:14 UTC 2009)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "powerpc-apple-darwin"...Reading symbols for shared l
ibraries ........... done

(gdb) run
Starting program: /opt/local/bin/mutt
Reading symbols for shared libraries ++++++++++...... done
ESC[?1049hESC[1;24rESC(BESC[mESC[4lESC[?7hESC[39;49mESC[?1hESC=
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x919e43d0 in realpath$DARWIN_EXTSN ()
(gdb) bt
#0  0x919e43d0 in realpath$DARWIN_EXTSN ()
#1  0x000459d8 in mx_open_mailbox ()
#2  0x0003b334 in main ()
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) n
Program not restarted.
(gdb) continue
Continuing.

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x919e43d0 in realpath$DARWIN_EXTSN ()
(gdb) bt
#0  0x919e43d0 in realpath$DARWIN_EXTSN ()
#1  0x000459d8 in mx_open_mailbox ()
#2  0x0003b334 in main ()
(gdb) q
The program is running.  Exit anyway? (y or n) y
bash-3.2$ exit
exit

[lbschenkel (Leonardo Brondani Schenkel)]

It looks like a null pointer dereference. I'm afraid that is beyond my capacity to fix, what I can do is to report it upstream.

[lbschenkel (Leonardo Brondani Schenkel)]

I have reported it at: ​https://github.com/neomutt/neomutt/issues/187

I'm not sure if we should track this issue in this same Trac ticket or open another one.

[dgonyier (Dwaine Gonyier)]

Replying to leonardo.schenkel@…:

I have reported it at: ​https://github.com/neomutt/neomutt/issues/187

I'm not sure if we should track this issue in this same Trac ticket or open another one.

Thanks. I'll follow the thread on github too. Since it is a runtime bug rather than a compile/install issue as this bug was originally for, it makes sense to open a different Trac ticket and point to the github issue.

[larryv (Lawrence Velázquez)]

Yes, please open a different ticket for this new problem.