Home/ Questions/Q 8150399
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-06T15:03:13+00:00

I’m having all manner of trouble attempting to compile Adobe Source Libraries (ASL) on

  • 0

I’m having all manner of trouble attempting to compile Adobe Source Libraries (ASL) on a Mac running Lion. I’m using MacPorts GCC-4.7 (I like C++11).

I downloaded and edited the asl_1.0.43_net_setup.sh by changing the url to point to downloads.sourceforge.net.

I told bjam to use my gcc and pass it the -std=c++11 flags by editing ~/user-config.jam:

import toolset : using ; using darwin ;
using gcc
    : 47 
    : g++-mp-4.7 
    : <cxxflags>"-std=c++11"
    ;

I build with flags telling bjam to make a 64 bit version:
bjam toolset=gcc-47 -j 4 address-model=64 architecture=x86

I keep getting the error message (multiple times):
documentation/examples/namespace.cpp:1:0: error: CPU you selected does not support x86-64 instruction set

Even though I told it to use 64 bit, bjam (stupidly) appears to be setting -march=i486 and causing the above problem. Ideally, ASL could compile using my existing installed boost, and TBB without building custom versions.

I’ve already spent a few hours so far and am about ready to chuck it. It seems to have so much promise, but the build system is inflexible (which is why I don’t use jam or bjam).

Does anyone have any hints on building this thing on a modern Mac using either clang or GCC?
(GCC: not the version that comes with XCode).

[edit] I found the i486 bit and removed that. Now I’m having trouble with what appears to be problems compiling with a C++11 compiler:

./adobe/closed_hash.hpp:691:88: error: 'insert' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
./adobe/closed_hash.hpp:691:88: note: declarations in dependent base    'adobe::version_1::closed_hash_set<adobe::pair<adobe::version_1::name_t, adobe::version_1::any_regular_t>, adobe::get_element<0, adobe::pair<adobe::version_1::name_t, adobe::version_1::any_regular_t> >, boost::hash<adobe::version_1::name_t>, std::equal_to<adobe::version_1::name_t>, adobe::version_1::capture_allocator<adobe::pair<adobe::version_1::name_t, adobe::version_1::any_regular_t> > >' are not found by unqualified lookup
./adobe/closed_hash.hpp:691:88: note: use 'this->insert' instead

[edit] Hmm, that actually looks like a bug in the adobe code that g++ used to be permissive about, but no longer is. Sigh, now it just looks like that the ASL hasn’t been compiled against any modern, (mostly) compliant C++11 compiler.

Now I see compilation problems in the version of boost that the adobe script downloaded (signals library apparently has a bug in some move constructor and GCC is complaining it):

../boost_libraries/boost/smart_ptr/shared_ptr.hpp:168:25: note: 'boost::shared_ptr<boost::signals::detail::basic_connection>::shared_ptr(const boost::shared_ptr<boost::signals::detail::basic_connection>&)' is implicitly declared as deleted because 'boost::shared_ptr<boost::signals::detail::basic_connection>' declares a move constructor or move assignment operator
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I’ve given up trying to figure out all the complexities introduced by bjam.

    Instead, I’ve started a fork on github of ASL that I’m building with cmake, gcc-47 and clang-3.2. I’ve made a couple of minor fixes in the code and have one of the directories compiling without warning.

    https://github.com/tfiner/adobe_asl

    [edit] After several hours of sweat, I finally have two shiny libraries built by clang 3.2 using boost 1.49, TBB 4.0 and OS X 10.6. Feel free to clone it from github and if you manage to make it work, please let me know.

    • 0