Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#56366 closed defect (fixed)

protobuf3-cpp fails to compile on OSX 10.8

Reported by: letaage Owned by: blair@…
Priority: Normal Milestone:
Component: ports Version: 2.4.2
Keywords: mountainlion legacy-os Cc: pmetzger (Perry E. Metzger)
Port: protobuf3-cpp

Description

Fails with error:

--->  Computing dependencies for protobuf3-cpp
--->  Fetching distfiles for protobuf3-cpp
--->  Verifying checksums for protobuf3-cpp
--->  Extracting protobuf3-cpp
--->  Configuring protobuf3-cpp
--->  Building protobuf3-cpp

Error: Failed to build protobuf3-cpp: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_protobuf3-cpp/protobuf3-cpp/main.log for details.
Error: Problem while installing protobuf3-cpp
Error: Follow https://guide.macports.org/#project.tickets to report a bug.

Attachments (7)

main.log (359.9 KB) - added by letaage 6 years ago.
Protobuf3-cpp compilation log file
macports.conf (8.2 KB) - added by letaage 6 years ago.
My macports.conf file
main_2.log (576.5 KB) - added by letaage 6 years ago.
Log file compiling with clang-5.0 installed
main_3.log (403.2 KB) - added by letaage 6 years ago.
Log file compiling with clang-5.0 installed, port clean --all protobuf3-cpp run first
main_4.log (361.9 KB) - added by letaage 6 years ago.
Log file compiling with clang-5.0 installed, modified portfile
Portfile (2.6 KB) - added by letaage 6 years ago.
Portfile with ldflag option set
Portfile2 (2.7 KB) - added by letaage 6 years ago.
Compiles successfully using this port file

Download all attachments as: .zip

Change History (30)

Changed 6 years ago by letaage

Attachment: main.log added

Protobuf3-cpp compilation log file

comment:1 Changed 6 years ago by letaage

Error in log file is multiple occurrences of;

info:build ld: symbol(s) not found for architecture x86_64

comment:2 Changed 6 years ago by raimue (Rainer Müller)

Keywords: yosemite legacy-os added; protobuf3-cpp removed
Owner: set to blair@…
Port: protobuf3-cpp added
Status: newassigned

comment:3 Changed 6 years ago by kencu (Ken)

it looks like it is trying to build and link against libc++, and those errors look like the ones you see when you try to link against the wrong stdlib. Have you set your default stdlib to libc++ yourself in macports.conf?

By default it should be building against gcc's libstdc++ courtesy of the cxx11 1.1 PG.

If you haven't changed it, then the build script could be setting it by itself, which would be the wrong stdlib for 10.8.

comment:4 Changed 6 years ago by kencu (Ken)

Keywords: mountainlion added; yosemite removed

comment:5 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)

We can see from the log that it is MacPorts that is telling the build to use libc++:

:debug:configure CXXFLAGS='-pipe -Os -stdlib=libc++ -arch x86_64'

The only reason why it should be doing that on ≤10.8 is if the user has used LibcxxOnOlderSystems.

comment:6 Changed 6 years ago by kencu (Ken)

Right. I have my 10.6.8 system set up with LibcxxOnOlderSystems as well, and it builds protobuf3-cpp without a blink against libc++...

Perhaps we might have the OP try a newer clang? Please make sure you have clang-5.0 installed, and then

sudo port -v install protobuf3-cpp configure.compiler=macports-clang-5.0

should do it.

comment:7 Changed 6 years ago by pmetzger (Perry E. Metzger)

Cc: pmetzger added

comment:8 Changed 6 years ago by letaage

Thanks for looking into this issue.

I tried the suggestions.

I checked that my macports.conf is file set per the instructions at the LibcxxOnOlderSystems link and it appears to be set correctly to me, conf file attached.

I installed clang-5.0 then as suggested ran:

slim:~ tom$ sudo port -v install protobuf3-cpp configure.compiler=macports-clang-5.0

But it failed with the same error. New log file attached.

Last edited 6 years ago by letaage (previous) (diff)

Changed 6 years ago by letaage

Attachment: macports.conf added

My macports.conf file

Changed 6 years ago by letaage

Attachment: main_2.log added

Log file compiling with clang-5.0 installed

comment:9 Changed 6 years ago by kencu (Ken)

OK. Well, first of all it's not building with clang-5.0 even though you asked it to do so. So that's one thing (I assume you cleaned in between attempts, right? Otherwise nothing would have been different in the configuration). So if that is true, we'll need to fix that. I suspect maybe the clean between attempts was missed, though, because it accepts the compiler forcing for me when I build it.

But here's the issue:

it's building like this: (notice the -stdlib=libc++ on the build line)

build libtool: compile:  /usr/bin/clang++ -std=c++11 -DHAVE_CONFIG_H -I. -I.. -I/opt/local/include -g -D_THREAD_SAFE -DHAVE_PTHREAD=1 -DHAVE_ZLIB=1 -Wall -Wno-sign-compare -pipe -Os -stdlib=libc++ -arch x86_64 -MT google/protobuf/compiler/js/well_known_types_embed.lo -MD -MP -MF google/protobuf/compiler/js/.deps/well_known_types_embed.Tpo -c google/protobuf/compiler/js/well_known_types_embed.cc -o google/protobuf/compiler/js/well_known_types_embed.o >/dev/null 2>&1

but it's linking like this: (notice no -stdlib is specified):

:info:build libtool: link: /usr/bin/clang++ -dynamiclib  -o .libs/libprotobuf.15.dylib  google/protobuf/stubs/.libs/atomicops_internals_x86_gcc.o google/protobuf/stubs/.libs/atomicops_internals_x86_msvc.o google/protobuf/stubs/.libs/bytestream.o google/protobuf/stubs/.libs/common.o google/protobuf/stubs/.libs/int128.o google/protobuf/stubs/.libs/io_win32.o google/protobuf/stubs/.libs/once.o google/protobuf/stubs/.libs/status.o google/protobuf/stubs/.libs/statusor.o google/protobuf/stubs/.libs/stringpiece.o google/protobuf/stubs/.libs/stringprintf.o google/protobuf/stubs/.libs/structurally_valid.o google/protobuf/stubs/.libs/strutil.o google/protobuf/stubs/.libs/time.o google/protobuf/.libs/arena.o google/protobuf/.libs/arenastring.o google/protobuf/.libs/extension_set.o google/protobuf/.libs/generated_message_util.o google/protobuf/.libs/generated_message_table_driven_lite.o google/protobuf/.libs/message_lite.o google/protobuf/.libs/repeated_field.o google/protobuf/.libs/wire_format_lite.o google/protobuf/io/.libs/coded_stream.o google/protobuf/io/.libs/zero_copy_stream.o google/protobuf/io/.libs/zero_copy_stream_impl_lite.o google/protobuf/.libs/any.pb.o google/protobuf/.libs/api.pb.o google/protobuf/stubs/.libs/mathlimits.o google/protobuf/.libs/any.o google/protobuf/.libs/descriptor.o google/protobuf/.libs/descriptor_database.o google/protobuf/.libs/descriptor.pb.o google/protobuf/.libs/duration.pb.o google/protobuf/.libs/dynamic_message.o google/protobuf/.libs/empty.pb.o google/protobuf/.libs/extension_set_heavy.o google/protobuf/.libs/field_mask.pb.o google/protobuf/.libs/generated_message_reflection.o google/protobuf/.libs/generated_message_table_driven.o google/protobuf/.libs/map_field.o google/protobuf/.libs/message.o google/protobuf/.libs/reflection_ops.o google/protobuf/.libs/service.o google/protobuf/.libs/source_context.pb.o google/protobuf/.libs/struct.pb.o google/protobuf/stubs/.libs/substitute.o google/protobuf/.libs/text_format.o google/protobuf/.libs/timestamp.pb.o google/protobuf/.libs/type.pb.o google/protobuf/.libs/unknown_field_set.o google/protobuf/.libs/wire_format.o google/protobuf/.libs/wrappers.pb.o google/protobuf/io/.libs/gzip_stream.o google/protobuf/io/.libs/printer.o google/protobuf/io/.libs/strtod.o google/protobuf/io/.libs/tokenizer.o google/protobuf/io/.libs/zero_copy_stream_impl.o google/protobuf/compiler/.libs/importer.o google/protobuf/compiler/.libs/parser.o google/protobuf/util/.libs/delimited_message_util.o google/protobuf/util/.libs/field_comparator.o google/protobuf/util/.libs/field_mask_util.o google/protobuf/util/internal/.libs/datapiece.o google/protobuf/util/internal/.libs/default_value_objectwriter.o google/protobuf/util/internal/.libs/error_listener.o google/protobuf/util/internal/.libs/field_mask_utility.o google/protobuf/util/internal/.libs/json_escaping.o google/protobuf/util/internal/.libs/json_objectwriter.o google/protobuf/util/internal/.libs/json_stream_parser.o google/protobuf/util/internal/.libs/object_writer.o google/protobuf/util/internal/.libs/protostream_objectsource.o google/protobuf/util/internal/.libs/protostream_objectwriter.o google/protobuf/util/internal/.libs/proto_writer.o google/protobuf/util/internal/.libs/type_info.o google/protobuf/util/internal/.libs/type_info_test_helper.o google/protobuf/util/internal/.libs/utility.o google/protobuf/util/.libs/json_util.o google/protobuf/util/.libs/message_differencer.o google/protobuf/util/.libs/time_util.o google/protobuf/util/.libs/type_resolver_util.o   -L/opt/local/lib -lz  -Os -arch x86_64 -Wl,-headerpad_max_install_names -arch x86_64   -install_name  /opt/local/lib/libprotobuf.15.dylib -compatibility_version 16 -current_version 16.1 -Wl,-single_module

so therefore, because no stdlib is specified on the link line, clang on 10.8 inserts -stdlib=libstdc++, and that's the wrong one for you.

Looks like this port needs some surgery, but to get you moving along, do something like this:

sudo port clean protobuf3-cpp

sudo vi `port file protobuf3-cpp`

add a line like this:

configure.ldflags-append -stdlib=libc++

save the file, and then rebuild it:

sudo port -v install protobuf3-cpp

and you _should_ be in business after that.

comment:10 Changed 6 years ago by letaage

I tried compiling again making sure thst I ran a clean first, but it still did not build:

slim:~ tom$  sudo port clean --all protobuf3-cpp
--->  Cleaning protobuf3-cpp
slim:~ tom$ sudo port install protobuf3-cpp configure.compiler=macports-clang-5.0
--->  Computing dependencies for protobuf3-cpp
--->  Fetching distfiles for protobuf3-cpp
--->  Attempting to fetch protobuf-cpp-3.5.1.tar.gz from http://aarnet.au.distfiles.macports.org/pub/macports/distfiles/protobuf3-cpp
--->  Verifying checksums for protobuf3-cpp
--->  Extracting protobuf3-cpp
--->  Configuring protobuf3-cpp
--->  Building protobuf3-cpp
Error: Failed to build protobuf3-cpp: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_protobuf3-cpp/protobuf3-cpp/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port protobuf3-cpp failed

It looks like the same error message to me in the log file, attached for reference.


Changed 6 years ago by letaage

Attachment: main_3.log added

Log file compiling with clang-5.0 installed, port clean --all protobuf3-cpp run first

comment:11 Changed 6 years ago by kencu (Ken)

yes, that time it used clang-5.0 indeed.

do you feel you could add the ldflag I mentioned? If that works we can generate a comprehensive fix for this situation.

comment:12 Changed 6 years ago by letaage

Ok, I followed your instructions to clean the port then edit the portfile to add the ldflags-append line, but it still did not build. I added the extra line to the portfile after the other configure.xyz lines, is that correct?

Log file and modified portfile attached.

Changed 6 years ago by letaage

Attachment: main_4.log added

Log file compiling with clang-5.0 installed, modified portfile

Changed 6 years ago by letaage

Attachment: Portfile added

Portfile with ldflag option set

comment:13 Changed 6 years ago by kencu (Ken)

Yeah - that should have put the -stdlib=libc++ on the link line, but it didn't. This port uses some things like "LDFLAGS_FOR_BUILD" that may need to be looked into a bit. Sorry it wasn't dead easy.

The other somewhat hacky way to do it is to add it onto the CXX compiler spec. Let me try a few things.

comment:14 Changed 6 years ago by kencu (Ken)

The following in the portfile seemed to do the right thing for me here -- can you give this a try and add this instead of the previous?

depends_build-append port:libtool
post-configure {
    # when linking, libtool does not respect -stdlib
    delete ${worksrcpath}/libtool
    xinstall -m 0755 ${prefix}/bin/glibtool ${worksrcpath}/libtool
}

comment:15 Changed 6 years ago by letaage

Happy to report that after a port clean I added the last suggested lines to the portfile and ran a port install and this time it compiled properly.

sudo port install protobuf3-cpp
--->  Computing dependencies for protobuf3-cpp
--->  Fetching distfiles for protobuf3-cpp
--->  Verifying checksums for protobuf3-cpp
--->  Extracting protobuf3-cpp
--->  Configuring protobuf3-cpp
--->  Building protobuf3-cpp
--->  Staging protobuf3-cpp into destroot
--->  Installing protobuf3-cpp @3.5.1_0
--->  Activating protobuf3-cpp @3.5.1_0
--->  Cleaning protobuf3-cpp
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  Found 2 broken files, matching files to ports
--->  Found 1 broken port, determining rebuild order
You can always run 'port rev-upgrade' again to fix errors.
The following ports will be rebuilt: mosh @1.3.2+perl5_24
Continue? [Y/n]: y
--->  Computing dependencies for mosh
--->  Fetching distfiles for mosh
--->  Attempting to fetch mosh-1.3.2.tar.gz from http://aarnet.au.distfiles.macports.org/pub/macports/distfiles/mosh
--->  Verifying checksums for mosh
--->  Extracting mosh
--->  Configuring mosh
--->  Building mosh
--->  Staging mosh into destroot
--->  Installing mosh @1.3.2_1+perl5_26
--->  Cleaning mosh                                                                                   --->  Computing dependencies for mosh
--->  Deactivating mosh @1.3.2_0+perl5_24
--->  Cleaning mosh
--->  Activating mosh @1.3.2_1+perl5_26
--->  Cleaning mosh
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  No broken files found.

The error about the broken port is because I had to force uninstall protobuf-cpp (required by mosh @1.3.2_0) in order to install protobuf3-cpp, but that's the subject of another ticket...

Changed 6 years ago by letaage

Attachment: Portfile2 added

Compiles successfully using this port file

comment:16 Changed 6 years ago by kencu (Ken)

great! that looks like a proper fix to me. We'll get that into yhe repo and should move it upsream as well

comment:17 Changed 6 years ago by pmetzger (Perry E. Metzger)

ken, if you can take care of closing this after updating the repo, I would appreciate it.

I note that blair doesn't seem to have come in to this or any other protobufs discussions, has the port been abandoned?

comment:18 Changed 6 years ago by blair (Blair Zajac)

If somebody wants to move the project to openmainter, that's fine by me.

comment:19 Changed 6 years ago by kencu (Ken)

Resolution: fixed
Status: assignedclosed

In 14219e973a20c05f33c5d6c6887e0cc6aaf683b9/macports-ports (master):

protobuf3-cpp: use updated libtool

closes: #56366

comment:20 Changed 6 years ago by kencu (Ken)

Mmmm. Not perfect, unfortunately. On a couple of systems, the port builds through all the way with macports-clang-5.0, but at the very end, links with /usr/bin/clang which of course does not understand -stdlib=macports-libstdc++ and so fails. So now that will have to be looked into...

comment:21 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)

Well, it's because you're copying the glibtool program from the libtool port. That glibtool program uses whatever compiler the libtool port was built with, which is not necessarily the compiler you want to use now for protobuf.

Why are you copying glibtool from the libtool port? Why can't you use the one protobuf shipped with? If it's that it doesn't use a -stdlib flag, would autoreconfing help? (There are other ports where we do that for that reason.)

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

Replying to ryandesign:

If it's that it doesn't use a -stdlib flag, would autoreconfing help? (There are other ports where we do that for that reason.)

See for example:

comment:23 Changed 6 years ago by kencu (Ken)

Why are you copying glibtool from the libtool port?

I noted it was done in other ports to fix a similar issue, and it worked when I tried it, and seemed to fix the issue for the OP as well.

But no doubt there is a better idea that will work for all systems, as in the end, this solution clearly does not.

Note: See TracTickets for help on using tickets.