Internal libboost dependency failure at reference time.

[trog24 (Frank J. R. Hanstick)]

The following error occurs when trying to link openvrml to libboost:

g++ -D_THREAD_SAFE -g -O2 -o .libs/browser browser.o -Wl,-bind_at_load  -L/opt/local/lib ./.libs/libtest-openvrml.a /Users/frank/FirefoxDownloads/openvrml-0.17.12/src/libopenvrml/.libs/libopenvrml.dylib -L/opt/local/lib/firefox-2.0.0.20 /opt/local/lib/libjpeg.dylib /opt/local/lib/libpng12.dylib /opt/local/lib/libfontconfig.dylib /opt/local/lib/libiconv.dylib /opt/local/lib/libexpat.dylib /opt/local/lib/libfreetype.dylib -lz -lmozjs -lplds4 -lplc4 -lnspr4 -lboost_thread-mt -lboost_unit_test_framework-mt -lboost_filesystem-mt
/usr/bin/ld: Undefined symbols:
boost::system::get_system_category()
boost::system::get_generic_category()
collect2: ld returned 1 exit status
make[2]: *** [browser] Error 1
make[2]: Leaving directory `/Users/frank/FirefoxDownloads/openvrml-0.17.12/tests'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/Users/frank/FirefoxDownloads/openvrml-0.17.12/tests'

The undefined symbol references get_system_category() and get_generic_category() are in libboost_filesystem-mt and the symbols are defined in libboost_system-mt and not in some unrelated library; yet, libboost_filesystem-mt cannot find libboost_system-mt to resolve the undefines, a library libboost_filesystem-mt is dependent on even though the libboost_system-mt is part of the same set without a supplied reference, ie:

make check LDFLAGS='-lboost_system-mt'

This particular dependency should have been resolved during the Boost build process. The above command is the work around until the problem is resolved.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Change description to use WikiFormatting.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Cc Me!

[braden@…]

Cc Me!

[braden@…]

The problem noted in the description is actually occurring when linking one of OpenVRML 0.17.12's test programs. The tests use some parts of Boost that the rest of OpenVRML doesn't.

I'm seeing a similar problem when compiling trunk libopenvrml (which uses boost::filesystem):

libtool: link: g++ -dynamiclib  -o libopenvrml/.libs/libopenvrml.8.dylib  libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-bad_url.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-vrml97_grammar.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-x3d_vrml_grammar.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-read_write_mutex.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-basetypes.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-field_value.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-event.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-exposedfield.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-scope.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-node.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-script.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-bounding_volume.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-scene.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-browser.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-viewer.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-rendering_context.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-frustum.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-node_impl_util.o libopenvrml/openvrml/local/.libs/libopenvrml_libopenvrml_la-dl.o libopenvrml/openvrml/local/.libs/libopenvrml_libopenvrml_la-uri.o libopenvrml/openvrml/local/.libs/libopenvrml_libopenvrml_la-xml_reader.o libopenvrml/openvrml/local/.libs/libopenvrml_libopenvrml_la-parse_vrml.o libopenvrml/openvrml/local/.libs/libopenvrml_libopenvrml_la-component.o libopenvrml/openvrml/local/.libs/libopenvrml_libopenvrml_la-proto.o libopenvrml/openvrml/local/.libs/libopenvrml_libopenvrml_la-externproto.o libopenvrml/openvrml/local/.libs/libopenvrml_libopenvrml_la-node_metatype_registry_impl.o   -L/opt/local/lib /opt/local/lib/libxml2.dylib -lpthread -lz /opt/local/lib/libiconv.dylib -lm -lboost_thread-mt -lboost_filesystem-mt /opt/local/lib/libltdl.dylib    -install_name  /usr/local/lib/libopenvrml.8.dylib -compatibility_version 9 -current_version 9.8 -Wl,-single_module
Undefined symbols:
  "boost::system::get_generic_category()", referenced from:
      __static_initialization_and_destruction_0(int, int)in libopenvrml_libopenvrml_la-scene.o
      __static_initialization_and_destruction_0(int, int)in libopenvrml_libopenvrml_la-scene.o
      __static_initialization_and_destruction_0(int, int)in libopenvrml_libopenvrml_la-scene.o
      __static_initialization_and_destruction_0(int, int)in libopenvrml_libopenvrml_la-browser.o
      __static_initialization_and_destruction_0(int, int)in libopenvrml_libopenvrml_la-browser.o
      __static_initialization_and_destruction_0(int, int)in libopenvrml_libopenvrml_la-browser.o
      __static_initialization_and_destruction_0(int, int)in libopenvrml_libopenvrml_la-dl.o
      __static_initialization_and_destruction_0(int, int)in libopenvrml_libopenvrml_la-dl.o
      __static_initialization_and_destruction_0(int, int)in libopenvrml_libopenvrml_la-dl.o
      __static_initialization_and_destruction_0(int, int)in libopenvrml_libopenvrml_la-parse_vrml.o
      __static_initialization_and_destruction_0(int, int)in libopenvrml_libopenvrml_la-parse_vrml.o
      __static_initialization_and_destruction_0(int, int)in libopenvrml_libopenvrml_la-parse_vrml.o
      __static_initialization_and_destruction_0(int, int)in libopenvrml_libopenvrml_la-component.o
      __static_initialization_and_destruction_0(int, int)in libopenvrml_libopenvrml_la-component.o
      __static_initialization_and_destruction_0(int, int)in libopenvrml_libopenvrml_la-component.o
  "boost::system::get_system_category()", referenced from:
      __static_initialization_and_destruction_0(int, int)in libopenvrml_libopenvrml_la-scene.o
      __static_initialization_and_destruction_0(int, int)in libopenvrml_libopenvrml_la-scene.o
      __static_initialization_and_destruction_0(int, int)in libopenvrml_libopenvrml_la-browser.o
      __static_initialization_and_destruction_0(int, int)in libopenvrml_libopenvrml_la-browser.o
      __static_initialization_and_destruction_0(int, int)in libopenvrml_libopenvrml_la-dl.o
      __static_initialization_and_destruction_0(int, int)in libopenvrml_libopenvrml_la-dl.o
      __static_initialization_and_destruction_0(int, int)in libopenvrml_libopenvrml_la-parse_vrml.o
      __static_initialization_and_destruction_0(int, int)in libopenvrml_libopenvrml_la-parse_vrml.o
      boost::filesystem::basic_directory_iterator<boost::filesystem::basic_path<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::filesystem::path_traits> >::increment()in libopenvrml_libopenvrml_la-component.o
      boost::filesystem::basic_directory_iterator<boost::filesystem::basic_path<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::filesystem::path_traits> >::m_init(boost::filesystem::basic_path<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::filesystem::path_traits> const&)in libopenvrml_libopenvrml_la-component.o
      boost::enable_if<boost::filesystem::is_basic_path<boost::filesystem::basic_path<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::filesystem::path_traits> >, bool>::type boost::filesystem::is_directory<boost::filesystem::basic_path<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::filesystem::path_traits> >(boost::filesystem::basic_path<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::filesystem::path_traits> const&)in libopenvrml_libopenvrml_la-component.o
      __static_initialization_and_destruction_0(int, int)in libopenvrml_libopenvrml_la-component.o
      __static_initialization_and_destruction_0(int, int)in libopenvrml_libopenvrml_la-component.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

I think I have some idea of what's going on here. OpenVRML headers include boost::filesystem headers which in turn include boost::system headers. But I don't understand why it's necessary to include -lboost_system-mt on the command link when linking libopenvrml. libboost_filesystem does appear to know about the libboost_system dependency:

$ otool -L /opt/local/lib/libboost_filesystem-mt.dylib 
/opt/local/lib/libboost_filesystem-mt.dylib:
	/opt/local/lib/libboost_filesystem-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
	/opt/local/lib/libboost_system-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)

Is what we're observing Just The Way It Is with the Darwin linker? Or is there something that can be done with the way Boost is built so that the libbboost_system dependency is picked up automatically in this case?

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

It seems that boost::system::get_system_category() is being included in an openvrml source file, in which case it needs to link in the correct library (libboost_system-mt.dylib).
I do not think there is anything that can be done to boost to make this go away.
Nor do I think it is Darwin specific.

This seems just the kind of situation ​pkg-config was designed to help with.

[braden@…]

On Linux, the linker will resolve the symbols against libboost_system because it sees that libboost_filesystem depends on it. I'm of the mind that Darwin's linker ought to be doing the same thing; whether it can be coaxed into doing that, I don't know.

Would pkg-config help with this? Well, it would if the pkg-config metadata were written to accommodate a linker that behaves like Darwin's; it wouldn't necessarily help if the metadata were written with the expectation that the linker would behave like Linux's.

OpenVRML leverages pkg-config extensively. Unfortunately, Boost does not.

[raphael@…]

Cc Me!

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

I think the following (from the ld man page) seems relevant:

   Two-level namespace
     By default all references resolved to a dynamic library record the
     library to which they were resolved. At runtime, dyld uses that informa-
     tion to directly resolve symobls.  The alternative is to use the
     -flat_namespace option.  With flat namespace, the library is not
     recorded.  At runtime, dyld will search each dynamic library in load
     order when resolving symbols. This is slower, but more like how other
     operating systems resolve symbols.

   Indirect dynamic libraries
     If the command line specifies to link against dylib A, and when dylib A
     was built it linked against dylib B, then B is considered an indirect
     dylib.  When linking for two-level namespace, ld does not look at indi-
     rect dylibs, except when re-exported by a direct dylibs.  On the other
     hand when linking for flat namespace, ld does load all indirect dylibs
     and uses them to resolve references.  Even though indirect dylibs are
     specified via a full path, ld first uses the specified search paths to
     locate each indirect dylib.  If one cannot be found using the search
     paths, the full path is used.

So it seems that -flat_namespace makes the linker behave more like Linux,
although the man page says it is slower.

[trog24 (Frank J. R. Hanstick)]

There are three different behaviors to the linkage failure as I noted in the discussion list before filing the bug report. Failure 1 when linking to the /usr/local/lib Boost using the suffix -xgcc40-mt libraries is:

g++ -D_THREAD_SAFE -g -O2 -o .libs/browser browser.o -Wl,-bind_at_load  -L/usr/local/spidermonkey/lib/ ./.libs/libtest-openvrml.a /Users/frank/FirefoxDownloads/openvrml-0.17.11/src/libopenvrml/.libs/libopenvrml.dylib -L/opt/local/lib -L/sw/lib/firefox2 /opt/local/lib/libjpeg.dylib /opt/local/lib/libpng12.dylib /opt/local/lib/libfontconfig.dylib /opt/local/lib/libiconv.dylib /opt/local/lib/libexpat.dylib /opt/local/lib/libfreetype.dylib -lz -lmozjs -lplds4 -lplc4 -lnspr4 -ldl -lboost_thread-xgcc40-mt -lboost_unit_test_framework-xgcc40-mt -lboost_filesystem-xgcc40-mt 
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: warning can't open dynamic library: libboost_system-xgcc40-mt-1_37.dylib referenced from: /usr/local/lib/libboost_filesystem-xgcc40-mt.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2)
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: Undefined symbols:
boost::system::get_system_category()
boost::system::get_generic_category()
boost::system::get_system_category()     referenced from libboost expected to be defined in libboost_system-xgcc40-mt-1_37.dylib
boost::system::get_generic_category()     referenced from libboost expected to be defined in libboost_system-xgcc40-mt-1_37.dylib
collect2: ld returned 1 exit status
make[2]: *** [browser] Error 1
make[2]: Leaving directory `/Users/frank/FirefoxDownloads/openvrml-0.17.11/tests'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/Users/frank/FirefoxDownloads/openvrml-0.17.11/tests'
make: *** [check-recursive] Error 1

Failure 1 when linking to the /usr/local/lib Boost using the suffix -xgcc40-mt-1_37 libraries is:

g++ -D_THREAD_SAFE -g -O2 -o .libs/browser browser.o -Wl,-bind_at_load  -lboost_system-xgcc40-mt-1_37.dylib ./.libs/libtest-openvrml.a -L/usr/local/lib -L/opt/local/lib /Users/frank/FirefoxDownloads/openvrml-0.17.12/src/libopenvrml/.libs/libopenvrml.dylib -L/opt/local/lib/firefox-2.0.0.20 /opt/local/lib/libjpeg.dylib /opt/local/lib/libpng12.dylib /opt/local/lib/libfontconfig.dylib /opt/local/lib/libiconv.dylib /opt/local/lib/libexpat.dylib /opt/local/lib/libfreetype.dylib -lz -lmozjs -lplds4 -lplc4 -lnspr4 -lboost_thread-xgcc40-mt-1_37 -lboost_unit_test_framework-xgcc40-mt-1_37 -lboost_filesystem-xgcc40-mt-1_37 
/usr/bin/ld: can't locate file for: -lboost_system-xgcc40-mt-1_37.dylib
collect2: ld returned 1 exit status
make[2]: *** [browser] Error 1
make[2]: Leaving directory `/Users/frank/FirefoxDownloads/openvrml-0.17.12/tests'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/Users/frank/FirefoxDownloads/openvrml-0.17.12/tests'
make: *** [check-recursive] Error 1

and failure 3 when linking to the /opt/local/lib Boost libraries (MacPorts) is:

g++ -D_THREAD_SAFE -g -O2 -o .libs/browser browser.o -Wl,-bind_at_load  -L/usr/local/spidermonkey/lib/ -L/opt/local/lib ./.libs/libtest-openvrml.a /Users/frank/FirefoxDownloads/openvrml-0.17.11/src/libopenvrml/.libs/libopenvrml.dylib -L/sw/lib/firefox2 /opt/local/lib/libjpeg.dylib /opt/local/lib/libpng12.dylib /opt/local/lib/libfontconfig.dylib /opt/local/lib/libiconv.dylib /opt/local/lib/libexpat.dylib /opt/local/lib/libfreetype.dylib -lz -lmozjs -lplds4 -lplc4 -lnspr4 -ldl -lboost_thread-mt -lboost_unit_test_framework-mt -lboost_filesystem-mt 
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: Undefined symbols:
boost::system::get_system_category()
boost::system::get_generic_category()
collect2: ld returned 1 exit status
make[2]: *** [browser] Error 1
make[2]: Leaving directory `/Users/frank/FirefoxDownloads/openvrml-0.17.11/tests'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/Users/frank/FirefoxDownloads/openvrml-0.17.11/tests'
make: *** [check-recursive] Error 1

with the differences between the three being:

Failure 1 includes:

/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: warning can't open dynamic library: libboost_system-xgcc40-mt-1_37.dylib referenced from: /usr/local/lib/libboost_filesystem-xgcc40-mt.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2)

Failure 2 includes:

/usr/bin/ld: can't locate file for: -lboost_system-xgcc40-mt-1_37.dylib

in their respective error message sequence when when trying to link. In these two case, ld cannot cannot find the designated dependent library even though the library exists within their respective directories as indicated by all being resolved using:

make check LIBPATH="-llibboost_system-xgcc40-mt", make check LIBPATH="-llibboost_system-xgcc40-mt-1_37", or make check LIBPATH="-llibboost_system-mt" respectively.

---

[braden@…]

FWIW... Adding -flat_namespace to LDFLAGS doesn't appear to have any effect.

Oh, and pkg-config fans will probably find ​this peripherally related blog posting interesting. I'm not entirely sure what it means for the sort of scenario articulated in this ticket. But I've asked.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to braden@…:

FWIW... Adding -flat_namespace to LDFLAGS doesn't appear to have any effect.

Perhaps the boost library has to be created with -flat_namespace.

It seems to me that changing the way boost is built to be more Linux like is not such a good idea.
If openvrml chooses to work this way, then setting LDFLAGS does not seem too bad.

[trog24 (Frank J. R. Hanstick)]

From what I have seen when searching this problem on the internet, the problem is not limited to openvrml. That was just where I had encountered it.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to trog24@…:

From what I have seen when searching this problem on the internet, the problem is not limited to openvrml. That was just where I had encountered it.

Based on your research, do you happen to know if the workaround is along the lines of adding a -l to the linker?

[braden@…]

Closing this as "wontfix" based on some speculation about what -flat_namespace does seems premature. There are some significant unanswered questions here that may have an impact on how, for instance, MacPorts needs to treat [Requires|Libs].private in pkg-config. Concretely:

• If boost_filesystem provided pkg-config metadata, would, from the perspective of the pkg-config maintainer, the dependency on boost_system go in Libs or Libs.private?
• If the latter, should MacPorts be patching pkg-config to treat Libs.private the same as Libs? (I think probably so.)

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to braden@…:

Closing this as "wontfix" based on some speculation about what -flat_namespace does seems premature. There are some significant unanswered questions here that may have an impact on how, for instance, MacPorts needs to treat [Requires|Libs].private in pkg-config. Concretely:

• If boost_filesystem provided pkg-config metadata, would, from the perspective of the pkg-config maintainer, the dependency on boost_system go in Libs or Libs.private?
• If the latter, should MacPorts be patching pkg-config to treat Libs.private the same as Libs? (I think probably so.)

When I first brought up pkg-confg, I did not mean to imply that it should be used here.
boost would have to be modified to write .pc files.
openvrml would have to be patched to recognize that boost now uses pkg-confg files.

I am not sure anybody would be up for maintaining those types of changes.

Please correct me if I am wrong, but, as I understand the situation, everything is working just as intended.
It is just that Macs behave a little differently than Linux, and openvrml expects Linux behavior.
The workarounds seems reasonably easy, which is why I thought wontfix was a reasonable way to go.

[braden@…]

Maybe it is; maybe it isn't. I'm not suggesting that Boost should be patched to use pkg-config. I'm pointing out that the situation in Boost points to a general problem and I'm asking the question, "What would MacPorts do if Boost did use pkg-config?"

So, as I've said, there are bigger questions being raised here that deserve answers. If answering those questions is being tracked somewhere else, that's fine (but a link seems appropriate).

Broadly, "How, in general, should MacPorts approach this difference between the GNU and Darwin linkers?" If building Boost (or any other library that exhibits such a pattern) with -flat_namespace would allow greater consistency, I don't think that should be so quickly dismissed--especially in light of the guidance pkg-config users are getting regarding Requires.private. This isn't just a Boost problem. What's happening there could easily happen elsewhere. That it hasn't been noticed (much) could very well be due to the limited deployment of Requires.private; but you should expect that to change.

It's also worth noting that adding a library to LIBS when building openvrml (or many other packages with multiple linker outputs) will result in a lot of bogus dependencies. That is, doing this will make everything depend on the added library; when in fact only one of the linker outputs (in openvrml's case) actually needs it.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to braden@…:

Maybe it is; maybe it isn't. I'm not suggesting that Boost should be patched to use pkg-config.

Sorry, I misunderstood.

I'm pointing out that the situation in Boost points to a general problem and I'm asking the question, "What would MacPorts do if Boost did use pkg-config?"

So, as I've said, there are bigger questions being raised here that deserve answers.
If answering those questions is being tracked somewhere else, that's fine (but a link seems appropriate).

I am unaware of this issue being tracked anywhere else, but this particular ticket is abut one particular problem.
As you say, it might be just the first indication of more problems, but I do not think we need to keep this ticket open
for that.

Broadly, "How, in general, should MacPorts approach this difference between the GNU and Darwin linkers?"

No to seem glib, but we should patch when needed and report upstream when appropriate.

If building Boost (or any other library that exhibits such a pattern) with -flat_namespace would allow greater consistency,
I don't think that should be so quickly dismissed--especially in light of the guidance pkg-config users are getting regarding
Requires.private. This isn't just a Boost problem.
What's happening there could easily happen elsewhere.
That it hasn't been noticed (much) could very well be due to the limited deployment of Requires.private; but you should expect that to change.

It seems to me that we don't have enough examples of things going wrong to form a good general strategy.

It's also worth noting that adding a library to LIBS when building openvrml (or many other packages with multiple linker outputs) will result in a lot of bogus dependencies.
That is, doing this will make everything depend on the added library; when in fact only one of the linker outputs (in openvrml's case) actually needs it.

I assume that Apple had good reasons for Two-level namespaces.
I am not knowledgeable enough to advocate for them, but
I would be wary of overriding this default linker behavior.

[braden@…]

Replying to mcalhoun@…:

No to seem glib, but we should patch when needed and report upstream when appropriate.

That wouldn't be glib if you had a compelling case for fixing this upstream. However...

I assume that Apple had good reasons for Two-level namespaces.
I am not knowledgeable enough to advocate for them, but
I would be wary of overriding this default linker behavior.

"I assume that Apple had good reasons" is a profoundly unconvincing argument.

[trog24 (Frank J. R. Hanstick)]

http://www.nabble.com/Problem-linking-to-Boost-Filesystem-Library-td19846002.html https://svn.boost.org/trac/boost/ticket/2579 http://groups.google.com/group/boost-list/browse_thread/thread/29d446279e543ebb These have nothing to do with openvrml.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to braden@…:

"I assume that Apple had good reasons" is a profoundly unconvincing argument.

I entirely agree.
As I see the it, however, the solution to the problem reported in this ticket is:

• Make a small change to the openvrml build process.
• Override the default linking mechanism when building boost.

We do not seem to have enough information on the ramifications of changing the link mechanism.
At least to me, this makes a small change to openvrml the better option.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to trog24@…:

​http://www.nabble.com/Problem-linking-to-Boost-Filesystem-Library-td19846002.html
​https://svn.boost.org/trac/boost/ticket/2579
​http://groups.google.com/group/boost-list/browse_thread/thread/29d446279e543ebb
These have nothing to do with openvrml.

Please forgive me, but could you explain the last two links a little more?
The ​second and ​third deal with files and libraries not being found.
This seems like a different kind of error than the one we have with openvrml.

With us, the library is found as long as we tell the linker to look for it.

[trog24 (Frank J. R. Hanstick)]

Both links are libboost_system not being found by libboost_filesystem which is what this ticket is about. We are not suppose to have to tell libboost_filesystem where libboost_system is located because they both are in the same library package. This is a case where a library dependent on another library within its own library system cannot find the library it is dependent on; not a library dependent on a library outside its own library system. A outside party linking to the libraries should not have to tell a library dependent on a library within its own library system where that library is. Such dependencies should be taken care of during the building of the library system. It is an intra (within its own system), not inter (between systems) library problem.

[(none)]

Milestone Port Bugs deleted

[braden@…]

I intend to fix this upstream in OpenVRML. See: ​https://sourceforge.net/apps/trac/openvrml/ticket/119