Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#37151 closed defect (fixed)

bahamut: build fails with clang; build system doesn't notice; proceeds to destroot, which fails

Reported by: robotoad (Preston Sumner) Owned by: ryandesign (Ryan Carsten Schmidt)
Priority: Normal Milestone:
Component: ports Version: 2.1.2
Keywords: clang Cc: jeremyhu (Jeremy Huddleston Sequoia)
Port: bahamut

Description (last modified by ryandesign (Ryan Carsten Schmidt))

On OS X 10.8.2, on a fresh installation of MacPorts, Bahamut fails to install. Attached to this ticket is the main.log. The console error output is:

--->  Staging bahamut into destroot
Error: org.macports.destroot for port bahamut returned: error renaming "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_irc_bahamut/bahamut/work/destroot/opt/local/ircd": no such file or directory
Please see the log file for port bahamut for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_irc_bahamut/bahamut/main.log
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: Processing of port bahamut failed

Attachments (2)

main.log (53.8 KB) - added by robotoad (Preston Sumner) 11 years ago.
The main.log specified in the console output.
patch-src-m_who.c.diff (327 bytes) - added by ryandesign (Ryan Carsten Schmidt) 11 years ago.

Download all attachments as: .zip

Change History (10)

Changed 11 years ago by robotoad (Preston Sumner)

Attachment: main.log added

The main.log specified in the console output.

comment:1 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)

Description: modified (diff)
Keywords: bahamut installation removed
Summary: Bahamut error during stagingbahamut: build fails; build system doesn't notice; proceeds to destroot, which fails

The relevant error in the log appears to be this problem when trying to build ircd:

:info:build /usr/bin/clang  -o ircd blalloc.o bsd.o channel.o clientlist.o clones.o confparse.o fdlist.o fds.o hash.o hide.o inet_addr.o ircd.o klines.o list.o m_nick.o m_rwho.o m_server.o m_services.o m_stats.o m_who.o match.o memcount.o modules.o packet.o parse.o pcre.o probability.o res.o s_auth.o s_bsd.o s_conf.o s_debug.o s_err.o s_misc.o s_numeric.o s_serv.o s_user.o sbuf.o scache.o send.o struct.o support.o throttle.o userban.o whowas.o zlink.o ssl.o socketengine_poll.o rc4.o dh.o version.o -lz  -L/opt/local/lib -lcrypto -lssl
:info:build Undefined symbols for architecture x86_64:
:info:build   "_first_visible_channel", referenced from:
:info:build       _m_who in m_who.o
:info:build ld: symbol(s) not found for architecture x86_64
:info:build clang: error: linker command failed with exit code 1 (use -v to see invocation)

The build system then doesn't notice this error and proceeds to the destroot phase as if nothing was wrong; the destroot then of course fails when it tries to install ircd because it isn't there since it wasn't built.

comment:2 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)

Keywords: clang added
Owner: changed from macports-tickets@… to ryandesign@…
Status: newassigned
Summary: bahamut: build fails; build system doesn't notice; proceeds to destroot, which failsbahamut: build fails with clang; build system doesn't notice; proceeds to destroot, which fails

Updating to the just released 2.0.4 version still has this problem.

Using llvm-gcc-4.2 instead works. We can use that workaround for now, but we should report this problem to the developers for a real fix.

comment:3 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: fixed
Status: assignedclosed

Updated port in r100096.

comment:4 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: jeremyhu@… added

Jeremy, in a prior offline discussion about similar errors in lmms, you referred me to this page about the "inline" keyword and told me that it needed to be changed to "static inline". So I wrote the attached patch, and bahamut does now compile with clang. Do you agree this is the right fix? I don't understand the implications of the change so I'd like to have another pair of eyes on it.

Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)

Attachment: patch-src-m_who.c.diff added

comment:5 Changed 11 years ago by jmroot (Joshua Root)

Clang just happens to default to C99 mode. Building with gcc -std=c99 would fail in the same way. You could equally validly tell clang that the code requires gnu89 semantics with -std=gnu89, rather than patching the code to work as C99. (The latter would be the better approach for upstream to adopt in the long run, of course.)

comment:6 Changed 11 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Yeah, that'll do the trick.

comment:7 Changed 11 years ago by robotoad (Preston Sumner)

Thank you for this fix. It's appreciated.

comment:8 in reply to:  6 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)

Thanks; committed my patch in r100103.

Note: See TracTickets for help on using tickets.