Re: Boost-users Digest, Vol 5327, Issue 1

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: Boost-users Digest, Vol 5327, Issue 1

Boost - Users mailing list
Okay, I have almost completely fixed my problems. 

I just spent the past hour:

- creating test case headers for each test translation unit (don't worry, I sped this up using a macro hehe)

- inserting static test case method declarations privately in said headers

- eliminating method redefinitions by toying with test translation unit #includes

I am ALMOST there. Going to start a new issue, as my current problem is now vastly different from what is stated in the subject line. Consider the original problem for this issue SOLVED.

Cheers!


On Fri, Feb 28, 2020 at 9:04 PM <[hidden email]> wrote:
Send Boost-users mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.boost.org/mailman/listinfo.cgi/boost-users
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Boost-users digest..."


Today's Topics:

   1. [Boost.Test] linking with shared lib (cannot find main)
      (Andrew McFarlane)
   2. Re: [Boost.Test] linking with shared lib (cannot find main)
      (Andrew McFarlane)


----------------------------------------------------------------------

Message: 1
Date: Fri, 28 Feb 2020 18:50:38 -0800
From: Andrew McFarlane <[hidden email]>
To: Boost users list <[hidden email]>
Subject: [Boost-users] [Boost.Test] linking with shared lib (cannot
        find main)
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset="utf-8"

Hi all,

I have been using Boost.Test for about a month now. Big fan so far, except
for the atrocious compilation times, hence why I am moving toward using the
shared library.

using b2 to build and install Boost.Test's libs was simple enough, though
after making the noted changes here:
https://www.boost.org/doc/libs/1_72_0/libs/test/doc/html/boost_test/adv_scenarios/shared_lib_customizations/entry_point.html

to customize the module's entry point, g++ cannot find the main executable:

Undefined symbols for architecture x86_64:

  "_main", referenced from:

     implicit entry/start for main executable

ld: symbol(s) not found for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see
invocation)

make: *** [Guest_T] Error 1

I tried digging through the docs for more information, but I came up short.

For more context, I have written unit tests for each of my classes. For
example, if my classes were A, B, and C, I would have A_T.cpp, B_T.cpp, and
C_T.cpp for unit tests.

- Should each of the unit tests have their own main() function? (I would
think not..)

- If not, how do I instruct g++ to first compile main.cpp before attempting
to compile anything else?

If you are curious, here are the contents of my Makefile:

PROG := main

CC := g++

SDIR := ../src

PKG_DIRS := $(shell ls $(SDIR))

CXXFLAGS = -v -Wall -std=c++11 -I$(SDIR_TEST) \

$(addprefix -I$(SDIR)/,$(PKG_DIRS)) -I$(BOOST_ROOT) \

-L$(BOOST_LIBS) -Wl,-rpath,$(BOOST_LIBS) -lboost_unit_test_framework

ODIR_TEST = ./bin

SDIR_TEST = ./src

OUTDIR = ./execs

ODIR = ../sim/bin


TEST_EXEC_NAMES = $(notdir $(basename $(wildcard $(SDIR_TEST)/*.cpp)))


$(OUTDIR)/$(PROG) : $(SDIR_TEST)/main.cpp

        $(CC) $(CXXFLAGS) -o $@ $<


$(OUTDIR)/$(PROG) : $(TEST_EXEC_NAMES)

        $(CC) $(CXXFLAGS) -o $@ $^


% : $(SDIR_TEST)/%.cpp

        $(CC) $(CXXFLAGS) -o $(OUTDIR)/$@ $^

>From what I can tell, g++ is failing to find the main the executable
because it is attempting to compile one of my unit test files first. This
may or may not be the case; either way, I would appreciate some help or
direction as to what I should read to learn more about this.

Let me know if you need more info.

Thanks in advance.

- AJ
-------------- next part --------------
HTML attachment scrubbed and removed

------------------------------

Message: 2
Date: Fri, 28 Feb 2020 20:55:44 -0800
From: Andrew McFarlane <[hidden email]>
To: Boost users list <[hidden email]>
Subject: Re: [Boost-users] [Boost.Test] linking with shared lib
        (cannot find main)
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset="utf-8"

Okay, so I've actually made considerable progress.

g++ can now find the main entry point and all my object files are being
compiled and placed where I want them. I'm even noticing the compilation
speedup from using the shared library, which is super cool.

I have (for the most part) transitioned my unit test translation units from
"automatic" to "manual". My current approach for manual test registration
is as follows:

- have an init_test_suite() function in each translation unit that: 1)
creates a test suite 2) adds all test cases from that translation unit to
the test suite 3) adds the test suite to the master test suite

- include test translation units in main.cpp

- have a register_test_suites() function in main.cpp that calls the
init_test_suite() function for each translation unit being tested

As one would expect from including a bunch of test translation units in
main.cpp (where several of them include files that are included by other
test translation units), I am running into redefinition errors. This does
not surprise me.

I am wondering: what would be a good modularized approach to calling the
init_test_suite() function defined in each of my test translation units
from main.cpp? Should I have test class header files with include guards,
and then include those files in main.cpp?

Sort of wondering what others have done in the past with manual test
registration to avoid redefinitions and maximize encapsulation.

Thanks in advance.

-AJ


On Fri, Feb 28, 2020 at 6:50 PM Andrew McFarlane <
[hidden email]> wrote:

> Hi all,
>
> I have been using Boost.Test for about a month now. Big fan so far, except
> for the atrocious compilation times, hence why I am moving toward using the
> shared library.
>
> using b2 to build and install Boost.Test's libs was simple enough, though
> after making the noted changes here:
>
> https://www.boost.org/doc/libs/1_72_0/libs/test/doc/html/boost_test/adv_scenarios/shared_lib_customizations/entry_point.html
>
> to customize the module's entry point, g++ cannot find the main executable:
>
> Undefined symbols for architecture x86_64:
>
>   "_main", referenced from:
>
>      implicit entry/start for main executable
>
> ld: symbol(s) not found for architecture x86_64
>
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
> make: *** [Guest_T] Error 1
>
> I tried digging through the docs for more information, but I came up short.
>
> For more context, I have written unit tests for each of my classes. For
> example, if my classes were A, B, and C, I would have A_T.cpp, B_T.cpp, and
> C_T.cpp for unit tests.
>
> - Should each of the unit tests have their own main() function? (I would
> think not..)
>
> - If not, how do I instruct g++ to first compile main.cpp before
> attempting to compile anything else?
>
> If you are curious, here are the contents of my Makefile:
>
> PROG := main
>
> CC := g++
>
> SDIR := ../src
>
> PKG_DIRS := $(shell ls $(SDIR))
>
> CXXFLAGS = -v -Wall -std=c++11 -I$(SDIR_TEST) \
>
> $(addprefix -I$(SDIR)/,$(PKG_DIRS)) -I$(BOOST_ROOT) \
>
> -L$(BOOST_LIBS) -Wl,-rpath,$(BOOST_LIBS) -lboost_unit_test_framework
>
> ODIR_TEST = ./bin
>
> SDIR_TEST = ./src
>
> OUTDIR = ./execs
>
> ODIR = ../sim/bin
>
>
> TEST_EXEC_NAMES = $(notdir $(basename $(wildcard $(SDIR_TEST)/*.cpp)))
>
>
> $(OUTDIR)/$(PROG) : $(SDIR_TEST)/main.cpp
>
>         $(CC) $(CXXFLAGS) -o $@ $<
>
>
> $(OUTDIR)/$(PROG) : $(TEST_EXEC_NAMES)
>
>         $(CC) $(CXXFLAGS) -o $@ $^
>
>
> % : $(SDIR_TEST)/%.cpp
>
>         $(CC) $(CXXFLAGS) -o $(OUTDIR)/$@ $^
>
> From what I can tell, g++ is failing to find the main the executable
> because it is attempting to compile one of my unit test files first. This
> may or may not be the case; either way, I would appreciate some help or
> direction as to what I should read to learn more about this.
>
> Let me know if you need more info.
>
> Thanks in advance.
>
> - AJ
>
-------------- next part --------------
HTML attachment scrubbed and removed

------------------------------

Subject: Digest Footer

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users


------------------------------

End of Boost-users Digest, Vol 5327, Issue 1
********************************************

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users