Loading ...
Sorry, an error occurred while loading the content.

Re: [Boost-Users] [Signals-1.30.0] Linking problems

Expand Messages
  • Michael Kettner
    ... Hash: SHA1 Hi Doug, ... I tried the testcases and erverything ran properly. ... That was the point: the boost-signals library used the namespace std (and
    Message 1 of 6 , Apr 1, 2003
    • 0 Attachment
      -----BEGIN PGP SIGNED MESSAGE-----
      Hash: SHA1

      Hi Doug,

      > Do the testcases run properly? e.g., use the same bjam command line in
      > libs/signals/test and check if there are any failures.

      I tried the testcases and erverything ran properly.

      > If the Signals testcases are running properly, I would guess that the
      > gcc-stlport toolset is using different STLport options than you are using
      > in your own program, and its affecting the name of the STLport namespace.
      > One way you can check this would be to use "nm libboost_signals.a|c++filt"
      > to see what STLport namespace the Boost.Signals classes refer to.

      That was the point: the boost-signals library used the namespace "std" (and
      not "_STL" as my program), because STLPORT_ROOT was not set. Instead I set
      STLPORT_PATH, as required under Windows. Changing STLPORT_PATH to
      STLPORT_ROOT and re-builduing boost-signals fixed all undefined references.

      Thanks for your help!

      This brings me to another point: I think it is extremely inconvenient to set
      STLPORT_ROOT under Linux and STLPORT_PATH under Windows as it is a source for
      errors like my one. Why couldn't you change boost-signals, so that
      STLPORT_ROOT is used on all platforms (like BOOST_ROOT, for example)?

      Michael


      - --
      Dipl.-Ing. Michael Kettner, Wissenschaftlicher Mitarbeiter
      Institut für Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover
      Appelstr. 9A # Tel: ++49/(0)511/762-4273
      D-30167 Hannover # Fax: ++49/(0)511/762-3001
      http://www.ive.uni-hannover.de # kettner@...-hannover.de
      -----BEGIN PGP SIGNATURE-----
      Version: GnuPG v1.0.6 (GNU/Linux)
      Comment: For info see http://www.gnupg.org

      iD8DBQE+iaC/kCdGnb0kVFMRAlN9AJ9SSxgYmbxXL5YvI96x7BBF+xz7zQCfQFlp
      zY7osPa3DGFaxXhf1i5aS84=
      =Jb9S
      -----END PGP SIGNATURE-----
    • Douglas Gregor
      ... I see (from stlport.jam) that both STLPORT_PATH and STLPORT_ROOT are supported on the GCC side, but STLPORT_ROOT is marked deprecated. Looks like you can
      Message 2 of 6 , Apr 1, 2003
      • 0 Attachment
        On Tuesday 01 April 2003 09:22 am, Michael Kettner wrote:
        > This brings me to another point: I think it is extremely inconvenient to
        > set STLPORT ROOT under Linux and STLPORT PATH under Windows as it is a
        > source for errors like my one. Why couldn't you change boost-signals, so
        > that STLPORT ROOT is used on all platforms (like BOOST ROOT, for example)?
        >
        > Michael

        I see (from stlport.jam) that both STLPORT_PATH and STLPORT_ROOT are supported
        on the GCC side, but STLPORT_ROOT is marked deprecated. Looks like you can
        use STLPORT_PATH in the same way on Linux and Windows:

        path ?= $(STLPORT_$(version)_PATH) ;
        path ?= $(STLPORT_PATH)$(SLASH)STLport-$(version) ;
        path ?= $(STLPORT_ROOT) ; #<< For backward compatability.

        This is more of a Boost.Jam/Boost.Build question, because the Signals library
        itself doesn't know the difference between STLport on Windows or on Linux per
        se. They generally prefer that Jam-related questions go to
        jamboost@yahoogroups.com but usually answer questions here as well.

        Doug
      Your message has been successfully submitted and would be delivered to recipients shortly.