This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: compatibility Clarification

Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:

| Gabriel Dos Reis writes:
| > | Ok, I'll try again.  Unfortunately, there are serious problems with the
| > | current dejagnu based testsuite which links all tests with -static (PR
| > | libstdc++/2841).
| > 
| > If I recall correctly, Benjamin indicates that because of libtool
| > being gone there are some serious issues trying to link with 
| > shared libs.  I don't have a clear picture of the whole issue.
| > Please, anyone who undertands the issue, please feel free to educate
| > me.
| I think I've explained most of the issues in the above PR.  In short, you
| have to teach the testsuite where to find the uninstalled shared libs
| (namely in the respective .libs subdirectories) and augment dejagnu's
| ld_library_path appropriately.  Much of this could probably be lifted from
| the current g++ and objc testsuites, but I think much better than
| duplicating this in several places, this knowledge should be consolidated
| in one place, or better yet, libtool used directly to both link (as mkcheck
| did before) and run (to set LD_LIBRARY_PATH appropriately, or whatever is
| necessary so the platform's runtime linker correctly finds the uninstalled
| shared library; mkcheck didn't do this) test programs under test.

Thanks for taking the time to reiterate the explanation.  That was
helpful for me.

For the record, let me point out that the "old" dejagnu framework
(which went away two weeks ago or so) used the same logic as mkcheck
and used libtool to link programs as follows:

    # By default, we want to use libtool to compile and run tests.
    set lt $lib_env(LIBTOOL)
    set lt_args "--tag=CXX"

        "run" -
        "link" {
            # If we're asked to run a testcase, then just do a `link'.
            # Later, the framework will load the program image through
            # libstdc++_load callback.
            if { $which_library == "static" } {
                append output_file ".st-exe"
            } else {
                append output_file ".sh-exe"
            append lt_args " --mode=link $lib_env(FLAGS) \
                    $lib_env($which_library) $testfile \
                    -o $output_file $lib_env(LDFLAGS)"

I think the problem is our returning back to libgloss (which is not
libtool-aware) to find the necessary bits to include and link things
and letting the jobs to the framework.  To make it work properly we

  1) hack libgloss to be libtool-aware
  2) return back to libtool and use libgloss only to find some link

I'm leaning towards 2) but I want to hear from Benjamin who had some
cross problems.

-- Gaby

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]