Hello,

in my build system I want to have the glibc in a different path, and I pass
"-B/myglibcpath/lib" in CFLAGS_FOR_TARGET and LDFLAGS_FOR_TARGET in the make
process.

This flag was respected in the target libmudflap linking step of gcc 4.3.4, and
therefore the usual "crti.o" and other startfiles needed for the shared library
linking were found at the proper -B/myglibcpath/lib directory.

In gcc 4.4.2, the libtool script no more passes the -Bxxx flags in
LDFLAGS_FOR_TARGET or CFLAGS_FOR_TARGET to the linking process of libmudflap,
and in my build, the startfiles are not found and so the build breaks.

I think that this should be solved in the way the target libstdc++ is built,
which works in gcc 4.3.4 and also in 4.4.2. I notice the relevant difference in
the archive_cmd generated in the libtool script, that in libstdc++ it includes
some predep_objs and some others, and therefore the linking command includes
the absolute path to the crti.o and other startfiles files as linking objects.
In libmudflap, no startfiles are passed, and they are expected to be in the gcc
built-in and usual -B paths.

I imagine that the difference between libstdc++ and libmudflap libtools is
triggered by some m4 scripts included in the libstdc++ build, that are not
included in the libmudflap build. Maybe lib-ld.m4, lib-link.m4, lib-prefix.m4 ?
I don't know autoconf enough to understand this difference.

I don't see in gcc 4.4.2 any other way of having the target glibc in a separate
directory other than patching the configure scripts; I hope this can be solved
and the mainline build system supports this again.


-- 
           Summary: The newer libtool scripts break the build of libmudflap
                    regarding the start files
           Product: gcc
           Version: 4.4.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libmudflap
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: viriketo at gmail dot com
 GCC build triplet: x86_64-linux
  GCC host triplet: x86_64-linux
GCC target triplet: armv5tel-unknown-linux-gnueabi


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42318

Reply via email to