Lothar,I'll test your code on my systems when I get a chance and report. Meanwhile, you can easily test the architecture of any file using the "file" command in the shell. Note that, on my system (shown below), some of the boost filesystem libraries are dual-architecture and some are not. This is consistent with how some projects build--they build individual binaries for a single architecture and then use "lipo" to stick them together. So you need to be sure you are linking in a dual-architecture version of the library and not a single architecture version. Perhaps that is you problem? $sudo find /usr/local/lib -regex ".*libboost_filesystem.*" -exec file {} \; Password: /usr/local/lib/libboost_filesystem-1_34_1.a: current ar archive /usr/local/lib/libboost_filesystem-1_34_1.dylib: Mach-O dynamically linked shared library i386 /usr/local/lib/libboost_filesystem-d-1_34_1.a: current ar archive /usr/local/lib/libboost_filesystem-d-1_34_1.dylib: Mach-O dynamically linked shared library i386 /usr/local/lib/libboost_filesystem-d.a: current ar archive /usr/local/lib/libboost_filesystem-gcc40-1_34.1.34.0.dylib: Mach-O universal binary with 2 architectures /usr/local/lib/libboost_filesystem-gcc40-1_34.1.34.0.dylib (for architecture ppc7400): Mach-O dynamically linked shared library ppc /usr/local/lib/libboost_filesystem-gcc40-1_34.1.34.0.dylib (for architecture i386): Mach-O dynamically linked shared library i386 /usr/local/lib/libboost_filesystem-gcc40-1_34.a: Mach-O universal binary with 2 architectures /usr/local/lib/libboost_filesystem-gcc40-1_34.a (for architecture ppc): current ar archive /usr/local/lib/libboost_filesystem-gcc40-1_34.a (for architecture i386): current ar archive /usr/local/lib/libboost_filesystem-gcc40-1_34.dylib: Mach-O universal binary with 2 architectures /usr/local/lib/libboost_filesystem-gcc40-1_34.dylib (for architecture ppc7400): Mach-O dynamically linked shared library ppc /usr/local/lib/libboost_filesystem-gcc40-1_34.dylib (for architecture i386): Mach-O dynamically linked shared library i386 /usr/local/lib/libboost_filesystem-gcc40-d-1_34.1.34.0.dylib: Mach-O universal binary with 2 architectures /usr/local/lib/libboost_filesystem-gcc40-d-1_34.1.34.0.dylib (for architecture ppc7400): Mach-O dynamically linked shared library ppc /usr/local/lib/libboost_filesystem-gcc40-d-1_34.1.34.0.dylib (for architecture i386): Mach-O dynamically linked shared library i386 /usr/local/lib/libboost_filesystem-gcc40-d-1_34.a: Mach-O universal binary with 2 architectures /usr/local/lib/libboost_filesystem-gcc40-d-1_34.a (for architecture ppc): current ar archive /usr/local/lib/libboost_filesystem-gcc40-d-1_34.a (for architecture i386): current ar archive /usr/local/lib/libboost_filesystem-gcc40-d-1_34.dylib: Mach-O universal binary with 2 architectures /usr/local/lib/libboost_filesystem-gcc40-d-1_34.dylib (for architecture ppc7400): Mach-O dynamically linked shared library ppc /usr/local/lib/libboost_filesystem-gcc40-d-1_34.dylib (for architecture i386): Mach-O dynamically linked shared library i386 /usr/local/lib/libboost_filesystem-gcc40-mt-1_34.1.34.0.dylib: Mach-O universal binary with 2 architectures /usr/local/lib/libboost_filesystem-gcc40-mt-1_34.1.34.0.dylib (for architecture ppc7400): Mach-O dynamically linked shared library ppc /usr/local/lib/libboost_filesystem-gcc40-mt-1_34.1.34.0.dylib (for architecture i386): Mach-O dynamically linked shared library i386 /usr/local/lib/libboost_filesystem-gcc40-mt-1_34.a: Mach-O universal binary with 2 architectures /usr/local/lib/libboost_filesystem-gcc40-mt-1_34.a (for architecture ppc): current ar archive /usr/local/lib/libboost_filesystem-gcc40-mt-1_34.a (for architecture i386): current ar archive /usr/local/lib/libboost_filesystem-gcc40-mt-1_34.dylib: Mach-O universal binary with 2 architectures /usr/local/lib/libboost_filesystem-gcc40-mt-1_34.dylib (for architecture ppc7400): Mach-O dynamically linked shared library ppc /usr/local/lib/libboost_filesystem-gcc40-mt-1_34.dylib (for architecture i386): Mach-O dynamically linked shared library i386 /usr/local/lib/libboost_filesystem-gcc40-mt-d-1_34.1.34.0.dylib: Mach-O universal binary with 2 architectures /usr/local/lib/libboost_filesystem-gcc40-mt-d-1_34.1.34.0.dylib (for architecture ppc7400): Mach-O dynamically linked shared library ppc /usr/local/lib/libboost_filesystem-gcc40-mt-d-1_34.1.34.0.dylib (for architecture i386): Mach-O dynamically linked shared library i386 /usr/local/lib/libboost_filesystem-gcc40-mt-d-1_34.a: Mach-O universal binary with 2 architectures /usr/local/lib/libboost_filesystem-gcc40-mt-d-1_34.a (for architecture ppc): current ar archive /usr/local/lib/libboost_filesystem-gcc40-mt-d-1_34.a (for architecture i386): current ar archive /usr/local/lib/libboost_filesystem-gcc40-mt-d-1_34.dylib: Mach-O universal binary with 2 architectures /usr/local/lib/libboost_filesystem-gcc40-mt-d-1_34.dylib (for architecture ppc7400): Mach-O dynamically linked shared library ppc /usr/local/lib/libboost_filesystem-gcc40-mt-d-1_34.dylib (for architecture i386): Mach-O dynamically linked shared library i386 /usr/local/lib/libboost_filesystem-mt-1_34_1.a: current ar archive /usr/local/lib/libboost_filesystem-mt-1_34_1.dylib: Mach-O dynamically linked shared library i386 /usr/local/lib/libboost_filesystem-mt-d-1_34_1.a: current ar archive /usr/local/lib/libboost_filesystem-mt-d-1_34_1.dylib: Mach-O dynamically linked shared library i386 /usr/local/lib/libboost_filesystem-mt-d.a: current ar archive /usr/local/lib/libboost_filesystem-mt.a: current ar archive /usr/local/lib/libboost_filesystem.a: current ar archive Some time ago, I created a make file that builds a simple fat32, fat64, and quad-arch program loading a static and dynamic lib as an exercise to figure out how to do so with make and lipo. The results show what the multi-architecture libraries should report using "file" on them: hello: Mach-O universal binary with 4 architectures hello (for architecture i386): Mach-O executable i386 hello (for architecture ppc7400): Mach-O executable ppc hello (for architecture ppc64): Mach-O 64-bit executable ppc64 hello (for architecture x86_64): Mach-O 64-bit executable x86_64 hello.fat32.o: Mach-O universal binary with 2 architectures hello.fat32.o (for architecture i386): Mach-O object i386 hello.fat32.o (for architecture ppc7400): Mach-O object ppc hello.fat64.o: Mach-O universal binary with 2 architectures hello.fat64.o (for architecture ppc64): Mach-O 64-bit object ppc64 hello.fat64.o (for architecture x86_64): Mach-O 64-bit object x86_64 hello_fat32: Mach-O universal binary with 2 architectures hello_fat32 (for architecture i386): Mach-O executable i386 hello_fat32 (for architecture ppc7400): Mach-O executable ppc hello_fat64: Mach-O universal binary with 2 architectures hello_fat64 (for architecture ppc64): Mach-O 64-bit executable ppc64 hello_fat64 (for architecture x86_64): Mach-O 64-bit executable x86_64 libuniversal.fat32.dylib: Mach-O universal binary with 2 architectures libuniversal.fat32.dylib (for architecture i386): Mach-O object i386 libuniversal.fat32.dylib (for architecture ppc7400): Mach-O object ppc libuniversal.fat64.dylib: Mach-O universal binary with 2 architectures libuniversal.fat64.dylib (for architecture ppc64): Mach-O 64-bit object ppc64 libuniversal.fat64.dylib (for architecture x86_64): Mach-O 64-bit object x86_64 libuniversal.i386.dylib: Mach-O object i386 libuniversal.ppc64.dylib: Mach-O 64-bit object ppc64 libuniversal.ppc7400.dylib: Mach-O object ppc libuniversal.x86_64.dylib: Mach-O 64-bit object x86_64 libworld.fat32.a: Mach-O universal binary with 2 architectures libworld.fat32.a (for architecture i386): Mach-O object i386 libworld.fat32.a (for architecture ppc7400): Mach-O object ppc libworld.fat64.a: Mach-O universal binary with 2 architectures libworld.fat64.a (for architecture ppc64): Mach-O 64-bit object ppc64 libworld.fat64.a (for architecture x86_64): Mach-O 64-bit object x86_64 libworld.i386.a: Mach-O object i386 libworld.ppc64.a: Mach-O 64-bit object ppc64 libworld.ppc7400.a: Mach-O object ppc libworld.x86_64.a: Mach-O 64-bit object x86_64 On 2/26/08, Lothar May <boost@lotharmay.de> wrote:

Hi Daniel,

compiling boost is successful on my system, too. Are boost exceptions caught using your build? Is your build universal?

...

I missed the thread on this, but I'll help you out if I can--just bring me up to speed.

Sample test code is this:

--cut here--

#include <iostream> #include <boost/filesystem.hpp>

using namespace std; using namespace boost::filesystem;

int main() { try { directory_iterator i("does_not_exist"); } catch(...) { cout << "This is never printed on MacOS 10.5." << endl; } return 0; }

--cut here--

Best regards,

Lothar

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Hello, I've started using boost::proto "prototype" to leverage the kernel code of my expression templates based library and I wanted to know how the followign can be done. Let's say such a statement is made : matrix<float> a,b,c,r; r = (a/b)+a+mul(b,c); using Proto i was able to turn this into a SIMD aware code that use SSE2 or Altivec (dependign on the platform) to operate. However, in Altivec, the sub-expression a+mul(b,c) can be mapped to a single, 3-ary vec_madd function that efficiently performs the mul-add operations. This replacement leads to a 80-90% incrase of performacnes compared to chaining mul and add. My question is : how can I use proto to detect such pattern (madd is an example, there is a lot of such pattern in SIMD code) and build a new expression in which the a+mul(b,c) expression is replaced by the madd(a,b,c) expression ? Thanks in advance. PS : if this proto related question doesn't fit here, can someone redirect me to the correct list or people ?

Lothar, My terse reply was not meant to be disrespectful ( in case you took it that way--text conversations can be misunderstood). I only posted the output in case you already figured it out thus avoiding spamming the list with a huge post given there don't seem many OS X developers on it so very few give a fig about this issue. But our numbers are growing and these painful learning experiences are becoming more common. The regime below is a quick-and-dirty sub-optimal brute force way of achieving a universal fat32 C++ build on OS X with Xcode 3. Once working, you can refine from there. I am no expert nor journeyman with Xcode though I hope to be one day. This works for me so I can focus on my application work. HTH. ARCHITECTURE ISSUES ---- Both my systems run Leopard 10.5.2 and are i386 ( a Core Duo Macbook Pro and a first-gen Quad core 8-way SMP Mac Pro). My Boost build seem to produce fat32 binaries "out of the box" with no special configuration. as the out of 'file' on the boost_filesystem libs shows: ./static/debug/mt/libboost_filesystem-mt-d-1_34_1.a: current ar archive ./static/debug/mt/libboost_filesystem-mt-d.a: current ar archive ./static/debug/st/libboost_filesystem-d-1_34_1.a: current ar archive ./static/debug/st/libboost_filesystem-d.a: current ar archive ./static/debug/st/libboost_filesystem-gcc40-d-1_34.a: Mach-O universal binary with 2 architectures ./static/debug/st/libboost_filesystem-gcc40-d-1_34.a (for architecture ppc): current ar archive ./static/debug/st/libboost_filesystem-gcc40-d-1_34.a (for architecture i386): current ar archive ./static/release/mt/libboost_filesystem-gcc40-mt-1_34.a: Mach-O universal binary with 2 architectures ./static/release/mt/libboost_filesystem-gcc40-mt-1_34.a (for architecture ppc): current ar archive ./static/release/mt/libboost_filesystem-gcc40-mt-1_34.a (for architecture i386): current ar archive IMPORTANT: notice not all the libraries are fat32 architecture--make sure you link in fat32 binaries (the one that the 'file' commands states are "universal binary with 2 architectures) if you want a universal (n this case fat32) build. You will also need to adjust your target build settings to include the architectures you want to build for. read teh Xocde docs to learn how to do this. I have tried tweaking Boost to give me a fat quad build (i386, ppc, ppc64, x86_64) yet because of the use of bjam. If you are not having this occur, it might be that you have CFLAGS< CXXFLAGS, and LDFLAGS set to "-arch i386" rather than "-arch i386 -arch ppc" somewhere in your environment. It might help to set them explicitly in the shell and export them before running Boost though Boost might override them. Bjam is too arcane for me to try and figure out how Boost build works--I just don't have the time avaialbe with all the other things I need to learn more about and projects I need to work on. PATHS ----- At first I tried using the default install location for the Boost libraries (/usr/local) but that was problematic with Xcode since it seemed to grab the first libboost_filesystem binary is found and it would be of the wrong architecture. Longer term, I am hoping that delving into the Xcode documentation will produce a more elegant solution to this, but for now I jsut use brute force and copy the files I need to the project folder. If you use source control this has the advantage of freezing the dependent library versions for SCM archiving--few things more vexing than having a library change versions and break your code. Specifically, I copy the relevant files to the project root directory, the path in the Xcode environment variable $(SRCROOT): 1)I copy all the boost includes into my project root folder. Copy the 'boost' folder inside boost_1_34_1, once you get it working you can pull out the ones you dont need. Also you could probably put the m in a silgne diretory hierarchy rooted somewhere below your home to avoid the copying, but you can work that out later--I want to keep things simple now to get it working first. 2) I copy the particular libraries I need in a folder named "lib" in $(SRCROOT). See above in ARCHITECURES to make sure you copy the right files. Check them iwth the 'file' command to be sure they are universal binaries of the desired type. 3) Modify your build settings for the target (right-click on the target in the Xcode project view and select the build tab). lot of settings there to tweak, but you jsut need to setHEader Search Paths and Library Search Paths to $(SRCROOT). IMPORTNT: do not check recursive or it whacks your name sapce and you'll get error on building like " 'snprintf' is nto a memeber of 'std'". this dorve me nearly insane when it first happened until I figured it out. I should have RTFM'd and could have avoided the pain and anguish. 4) open the target tree to expose the build phases (click on the trainagle next to the target) and you'll see three standard phases: Compile Sources, Link Binary With Libraries, and Copy Files. right-click on Link Binary With Libraries and selet add existing file and select you libraries from the file choose dialog. If this is a all done correctly you should get a fat32 copile fo your application that works. At least it works for me. As I have said repeatedly, this is a quick and dirty regime that works but is sub-optimal. Over time I'll refine it to ake it more efficient and maintainable. But to goal here is to get you moving with Boost and Xcode universal builds. I am no expert but this worked for me. HTH Daniel Lord 1 March 2008 --- Some people building C++/Obj-C code on OS X with Xcode and have a problem think:"I know, I'll use the Boost Libraries". Now they have two problems--three if they needed regular expressions. ;-) On 3/1/08, Lothar May <boost@lotharmay.de> wrote:

Hi Daniel,

thank you very much for testing it. It's great that it works for you. Could you please tell me how you built boost? It seems you are using the i386 architecture. Is your boost build a universal build, i.e. will the programs run on PowerPC as well?

The problem for me is that I do not have a PowerPC based system, so I cannot build boost on a PowerPC and on an i386 system and copy them to a universal build - instead I need to compile both on the i386 system. The way I tried to do this, although as documented, seems to break the exception support. Maybe we can find a way to merge the way you are building boost with the additional options needed for a universal build.

Thanks again,

Lothar

Daniel Lord wrote:

...

It worked fine for me:

[09:46:50] daniello@Mercury ~/Documents/Development/Study/Xcode-Boost/BoostExceptionTest $uname -a Darwin dhcp-2op9-2op10-east-130-35-99-215.usdhcp.oraclecorp.com <http://dhcp-2op9-2op10-east-130-35-99-215.usdhcp.oraclecorp.com> 9.2.0 Darwin Kernel Version 9.2.0: Tue Feb 5 16:13:22 PST 2008; root:xnu-1228.3.13~1/RELEASE_I386 i386 [09:46:57] daniello@Mercury ~/Documents/Development/Study/Xcode-Boost/BoostExceptionTest $./BoostExceptionTest /fake This is never printed on MacOS 10.5.

On 2/26/08, *Lothar May* <boost@lotharmay.de <mailto:boost@lotharmay.de>> wrote:

Hi Daniel,

compiling boost is successful on my system, too. Are boost exceptions caught using your build? Is your build universal?

> I missed the thread on this, but I'll help you out if I can--just > bring me up to speed.

Sample test code is this:

--cut here--

#include <iostream> #include <boost/filesystem.hpp>

using namespace std; using namespace boost::filesystem;

int main() { try { directory_iterator i("does_not_exist"); } catch(...) { cout << "This is never printed on MacOS 10.5." << endl; } return 0; }

--cut here--

Best regards,

Lothar

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org <mailto:Boost-users@lists.boost.org> http://lists.boost.org/mailman/listinfo.cgi/boost-users

...

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

--

Hi Daniel, BOOST_NO_EXCEPTIONS will disable all boost exceptions, but my problem is not that exceptions are not thrown, the problem is that they cannot be caught. And if I would disable them, I'd have no error handling. How did you build boost? In case you used the default instructions from boost.org, for me they do not work for two reasons: 1) No universal binaries are created But even if I compile & link everything (including the application) as non-universal: 2) I get loads of linker errors in boost::filesystem, it seems to use non-MacOS-native-libs, which is bad (I need a native boost). The only two ways I made it work were i) cmake + boost 1.34.0 and ii) asl (adobe source library) But with the result that exceptions cannot be caught... Regards, Lothar Daniel Lord wrote:

UPDATE: Just came across this in the Boost documentation for filesystem which might be an explanation:

"All exceptions thrown by the Filesystem Library are implemented by calling boost::throw_exception()

<file:///Users/daniello/Documents/Development/Lib/Boost/boost_1_34_1/libs/utility/throw_exception.html>.

Thus exact behavior may differ depending on BOOST_NO_EXCEPTIONS at the time the filesystem source files are compiled."

Daniel --- Some people building C++/Obj-C code on OS X with Xcode and have a problem think: "I know, I'll use the Boost Libraries". Now they have two problems--three if they used Boost for regular expressions. ;-)

Hi Daniel, Daniel Lord wrote:

1.34.0?

Yes, this was the only 1.34 version that I could find a cmake variant for. asl (adobe source library) uses boost 1.34.1, however.

.configure; make; sudo make install;

I tried this, too (with 1.34.1). Can't use boost::filesystem properly with this (I get lots of linking errors with my application). I'll try again. Thanks Lothar

Mat Marcus wrote:

It sounds like you may be experiencing issues with gcc visibility. Try making symbols visible, or at minimum add -fvisibility-ms-compat to your build settings. See, for example, http://gcc.gnu.org/wiki/Visibility under "Problems with C++ exceptions (please read!)".

- Mat

Hi Mat, I've already tried this, the point is that I'm using the static boost libs. See http://lists.boost.org/boost-users/2007/12/32590.php I'll try again. Thanks for the hint. Anyway, I tend to find any kind of "feature" a compiler might have which breaks something as basic as exceptions without spitting out some error is altogether evil... But this is just my humble opinion. Regards, Lothar

Hi Mat, I just found out that the problem exists only when linking with the release lib. You were linking with the debug lib of boost_filesystem, which works fine on my system, too. Can you reproduce the error with the release lib on your system? See below for details. Mat Marcus wrote:

$bjam -d+2

---

darwin.compile.c++ ../sandbox/boost_libraries/bin.v2/libs/filesystem/build/darwin/debug/link-static/macosx-version-10.4/threading-multi/exception.o

"g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 -Wno-long-double -no-cpp-precomp -gdwarf-2 -DBOOST_ALL_NO_LIB=1 -I"../sandbox/boost_libraries" -c -o "../sandbox/boost_libraries/bin.v2/libs/filesystem/build/darwin/debug/link-static/macosx-version-10.4/threading-multi/exception.o" "../sandbox/boost_libraries/libs/filesystem/src/exception.cpp"

---

On my system it looks like this: darwin.compile.c++ bin.v2/libs/filesystem/build/darwin/release/link-static/macosx-version-10.4/threading-multi/exception.o "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 -Wno-long-double -no-cpp-precomp -gdwarf-2 -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c -o "bin.v2/libs/filesystem/build/darwin/release/link-static/macosx-version-10.4/threading-multi/exception.o" "libs/filesystem/src/exception.cpp" Please note that I use the release version, which explains the "-O3 -finline-functions" difference. Also, I did not modify any options, nor did I modify the g++ environment in any way. $ sudo mv projects/adobe_root/boost_libraries/bin.v2/libs/filesystem/build/darwin/release/link-static/macosx-version-10.4/threading-multi/libboost_filesystem-mt-1_34_1.a /usr/local/lib $ ls /usr/local/lib/libboost* /usr/local/lib/libboost_filesystem-mt-1_34_1.a Now the simple way first: $ g++ -c test.cpp -I./projects/adobe_root/boost_libraries -o test.o $ g++ -o test test.o /usr/local/lib/libboost_filesystem-mt-1_34_1.a $ ./test terminate called after throwing an instance of 'boost::filesystem::basic_filesystem_error<boost::filesystem::basic_path<std::string, boost::filesystem::path_traits> >' what(): boost::filesystem::basic_directory_iterator constructor Abort trap Adding all your options: $ rm ./test ./test.o $ g++ -c test.cpp -I./projects/adobe_root/boost_libraries -ftemplate-depth-128 -O0 -fno-inline -Wall -g -isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 -Wno-long-double -no-cpp-precomp -gdwarf-2 -Werror -Wall -Wno-trigraphs -Wreturn-type -Wnon-virtual-dtor -Woverloaded-virtual -Wformat -Wmissing-braces -Wparentheses -Wswitch -Wunused-function -Wunused-label -Wunused-parameter -Wunused-variable -Wunused-value -Wunknown-pragmas -Wsign-compare -DADOBE_SERIALIZATION -DADOBE_STD_SERIALIZATION -DBOOST_ALL_NO_LIB -DBOOST_SIGNALS_STATIC_LINK -DBOOST_THREAD_BUILD_LIB=1 -DBOOST_THREAD_USE_LIB -DNOMINMAX -o test.o $ g++ -o test test.o /usr/local/lib/libboost_filesystem-mt-1_34_1.a -g -isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 -Xlinker -Y -Xlinker 5 -lSystemStubs $ ./test terminate called after throwing an instance of 'boost::filesystem::basic_filesystem_error<boost::filesystem::basic_path<std::string, boost::filesystem::path_traits> >' what(): boost::filesystem::basic_directory_iterator constructor Abort trap Using the debug lib works like a charme: sudo mv projects/adobe_root/boost_libraries/bin.v2/libs/filesystem/build/darwin/debug/link-static/macosx-version-10.4/threading-multi/libboost_filesystem-mt-d-1_34_1.a /usr/local/lib $ g++ -c test.cpp -I./projects/adobe_root/boost_libraries -o test.o $ g++ -o test test.o /usr/local/lib/libboost_filesystem-mt-d-1_34_1.a $ ./test This is never printed on MacOS 10.5. I'm using the latest release of asl (1.0.35).

darwin.compile.c++ /Users/mmarcus/pcshare/asl/staff/mmarcus/sandbox/built_artifacts/darwin/debug/asl-dev/link-static/macosx-version-10.4/threading-multi/lothar.o

"g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 -Wno-long-double -no-cpp-precomp -gdwarf-2 -Werror -Wall -Wno-trigraphs -Wreturn-type -Wnon-virtual-dtor -Woverloaded-virtual -Wformat -Wmissing-braces -Wparentheses -Wswitch -Wunused-function -Wunused-label -Wunused-parameter -Wunused-variable -Wunused-value -Wunknown-pragmas -Wsign-compare -DADOBE_SERIALIZATION -DADOBE_STD_SERIALIZATION -DBOOST_ALL_NO_LIB -DBOOST_SIGNALS_STATIC_LINK -DBOOST_THREAD_BUILD_LIB=1 -DBOOST_THREAD_USE_LIB -DNOMINMAX -I"../sandbox/adobe_source_libraries" -I"../sandbox/boost_libraries" -I"/adobe" -I"/boost" -c -o "/Users/mmarcus/pcshare/asl/staff/mmarcus/sandbox/built_artifacts/darwin/debug/asl-dev/link-static/macosx-version-10.4/threading-multi/lothar.o" "lothar.cpp"

---

darwin.link /Users/mmarcus/pcshare/asl/staff/mmarcus/sandbox/built_artifacts/darwin/debug/asl-dev/link-static/macosx-version-10.4/threading-multi/lothar

g++ -o "/Users/mmarcus/pcshare/asl/staff/mmarcus/sandbox/built_artifacts/darwin/debug/asl-dev/link-static/macosx-version-10.4/threading-multi/lothar" "/Users/mmarcus/pcshare/asl/staff/mmarcus/sandbox/built_artifacts/darwin/debug/asl-dev/link-static/macosx-version-10.4/threading-multi/lothar.o" "/Users/mmarcus/pcshare/asl/staff/mmarcus/sandbox/built_artifacts/darwin/debug/asl-dev/link-static/macosx-version-10.4/threading-multi/libasl_dev.a" "../sandbox/boost_libraries/bin.v2/libs/thread/build/darwin/debug/link-static/macosx-version-10.4/threading-multi/libboost_thread-mt-d-1_34_1.a" "../sandbox/boost_libraries/bin.v2/libs/signals/build/darwin/debug/link-static/macosx-version-10.4/threading-multi/libboost_signals-mt-d-1_34_1.a" "../sandbox/boost_libraries/bin.v2/libs/filesystem/build/darwin/debug/link-static/macosx-version-10.4/threading-multi/libboost_filesystem-mt-d-1_34_1.a" -g -isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 -Xlinker -Y -Xlinker 5 -lSystemStubs

testing.unit-test /Users/mmarcus/pcshare/asl/staff/mmarcus/sandbox/built_artifacts/darwin/debug/asl-dev/link-static/macosx-version-10.4/threading-multi/lothar.passed

/Users/mmarcus/pcshare/asl/staff/mmarcus/sandbox/built_artifacts/darwin/debug/asl-dev/link-static/macosx-version-10.4/threading-multi/lothar && touch /Users/mmarcus/pcshare/asl/staff/mmarcus/sandbox/built_artifacts/darwin/debug/asl-dev/link-static/macosx-version-10.4/threading-multi/lothar.passed

This is never printed on MacOS 10.5.

Thanks, Lothar

Hi Mat, Mat Marcus wrote: [...]

Looks like you need to add -no_dead_strip_inits_and_terms to your release build settings. Does it work if you do?

It works!!! Yiiiiha! Thank you very much!

One might wish that the compiler/linker would avoid such error-prone "optimizations" as dead-stripping static constructors, or at least make -no_dead_strip_inits_and_terms the default. This thread would make a good bug report, IMO.

I'm not sure where to report this. This might be a MacOS-g++-specific problem, but still it might not. This problem occured in an open source project, and we've gotten a report from a Linux user where this error also occured. However, that user did not provide much information and I could not reproduce it on any Linux system. Best regards, Lothar