Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#51309 closed defect (fixed)

libproxy @0.4.13 fails to build against libstdc++ (requires C++11)

Reported by: udbraumann Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 2.3.4
Keywords: Cc: dbevans (David B. Evans)
Port: libproxy

Description

While upgrading libproxy from 0.4.12 to 0.4.13 I receive this error message:

...
:info:build cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_net_libproxy/libproxy/work/build/libproxy && /Developer/usr/bin/g++-4.2 -D_POSIX_C_SOURCE=200112L -Dconfig_kde_EXPORTS -DLIBEXECDIR=\"/opt/local/libexec\" -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_net_libproxy/libproxy/work/libproxy-0.4.13 -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include  -fvisibility=hidden -pipe -Os  -DNDEBUG -arch ppc -mmacosx-version-min=10.5 -fPIC   -o CMakeFiles/config_kde.dir/modules/config_kde.cpp.o -c /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_net_libproxy/libproxy/work/libproxy-0.4.13/libproxy/modules/config_kde.cpp
:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_net_libproxy/libproxy/work/libproxy-0.4.13/libproxy/modules/config_kde.cpp: In member function ‘std::string kde_config_extension::kde_config_val(const std::string&, const std::string&)’:
:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_net_libproxy/libproxy/work/libproxy-0.4.13/libproxy/modules/config_kde.cpp:165: error: ‘class std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >’ has no member named ‘at’
:info:build make[2]: *** [libproxy/CMakeFiles/config_kde.dir/modules/config_kde.cpp.o] Error 1
...

Some ideas?

Attachments (1)

main.log.gz (6.0 KB) - added by udbraumann 8 years ago.

Download all attachments as: .zip

Change History (12)

Changed 8 years ago by udbraumann

Attachment: main.log.gz added

comment:1 Changed 8 years ago by dbevans (David B. Evans)

Looking at this now. As usual, I don't have any way of reproducing the error or testing but will let you know if I come up with something to try.

comment:2 in reply to:  1 Changed 8 years ago by arboz@…

Replying to devans@…:

Looking at this now. As usual, I don't have any way of reproducing the error or testing but will let you know if I come up with something to try.

devans,

This problem also exists in 10.58 intel i386. The issue, sure enough

as stated in the above error report:

In member function ‘std::string kde_config_extension::kde_config_val(const std::string&, const std::string&)’:
:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_net_libproxy/libproxy/work/

libproxy-0.4.13/libproxy/modules/config_kde.cpp:165: 
error: ‘class std::map<std::basic_string<char, std::char_traits<char>, 
std::allocator<char> >, 
std::basic_string<char, std::char_traits<char>, std::allocator<char> >, 
std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, 
std::allocator<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, 
std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >’ 

has no member named ‘at’

Which is a really long way to say that the member function "at" does not exist in the version of the standard c++ library in the leopard 10.5sdk. I looked for it in there, and surely not there. I did find in the std lib installed by macports for gcc5 at /opt/local/include/gcc5/c++/map

on line 165 of the offending file there is return cache.at(key) and this would be an excellent way to find out if a key/value exists before allocating memory.. so I see the validity of the change except the older machines won't be able to do it that way.

So Naturally, I would like to compile using another compiler/std-library or just find the way to avoid having this kde-config resource compile.

There are several issues that I have no direct information about, like changing the compiler for the cmake system temporarily or blacklisting the apple-gcc-4.2.1.

In the meantime, several other ports seems to require libproxy before they will update.

Thanks for your input.

comment:3 Changed 8 years ago by dbevans (David B. Evans)

Three possible fixes that I see.

  • Use a newer clang compiler to build if you can install it on your platform. Just blacklisting the current compiler will cause the port to build with clang-3.4 which, as I understand it, is problematic for ppc platforms. You need clang-3.6 or better for ppc support. See Building libcxx on older systems for issues on Leopard ppc. This will use libcxx @3.7.1_0. The following works for me but I'm testing on Yellowstone.
    sudo port install clang-3.7
    sudo port install libproxy configure.compiler=macports-clang-3.7
    
  • Disable building of the kde-config module on 10.5 and earlier if this is acceptable to you
  • As a last resort you can roll back your port to the previous version (locally)

Please test and let me know what works. I can then modify the port accordingly. I'm guessing that disabling kde-config may be the most practical choice.

comment:4 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Summary: libproxy @0.4.13 fails building in 10.5.8. PPClibproxy @0.4.13 fails to build against libstdc++

The issue has to do with libstdc++ on Leopard. Using newer clang doesn't help because libstdc++ is still missing the support. eg:

/opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_net_libproxy/libproxy/work/libproxy-0.4.13/libproxy/modules/config_kde.cpp:165:30: error: 
      no member named 'at' in 'std::map<std::basic_string<char>, std::basic_string<char>, std::less<std::basic_string<char> >,
      std::allocator<std::pair<const std::basic_string<char>, std::basic_string<char> > > >'
                return cache.at(key);
                       ~~~~~ ^
1 error generated.

comment:5 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Summary: libproxy @0.4.13 fails to build against libstdc++libproxy @0.4.13 fails to build against libstdc++ (requires C++11)

That method was added in C++11.

http://www.cplusplus.com/reference/map/map/at/

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

Caused by https://github.com/libproxy/libproxy/commit/28620c7aeb3d1b54c83caf84778df8e095490820

commit 28620c7aeb3d1b54c83caf84778df8e095490820
Author: Fabian Vogt <fabian@ritter-vogt.de>
Date:   Tue Feb 16 21:33:40 2016 +0100

    config_kde: Add a basic cache and invalidation
    
    After finding out whether to use kreadconfig5 or kreadconfig,
    it uses either qtpaths or kde4-config to determine the locations
    of the kioslaverc config file, to be able to notice modifications
    that require a cache flush.

comment:7 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)

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

Resolution: fixed
Status: newclosed

comment:9 Changed 8 years ago by arboz@…

Thanks for the work and explanations and links to the upstream work. The problem not limited to PPC also in Leopard i386, though it is still unclear whether it could be resolved by using the different libstdc++. Eventually, I will get over this machine and on to modern OS and architecture.

comment:10 in reply to:  8 Changed 8 years ago by udbraumann

Replying to jeremyhu@…:

r148469

Though I do not understand what you did to fix this problem, I am really grateful for your fast help!

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

You just need to update like normal, and you'll get the change.

Note: See TracTickets for help on using tickets.