[LLVMbugs] [Bug 19526] New: Refine the grouping of the linker-related flags

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=19526

            Bug ID: 19526
           Summary: Refine the grouping of the linker-related flags
           Product: Build scripts
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: cmake
          Assignee: unassignedbugs at nondot.org
          Reporter: emanuelecestari at yahoo.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

When building with llvm, clang, clang-tools-extra, compiler-rt, libcxx and lldb
I noticed that the linking phase is weird, it doesn't take into account the
linker-related cache entries that I'm giving to cmake, basically anything in
the form CMAKE_*_LINKER_FLAGS, and it doesn't even use the specific cache
entries ( specific to the library ) to form the correct set of flags that you
have to pass to ld or gcc, even when cmake gets something like
LIBXML2_LIBRARIES set to the correct value, it doesn't make any good use of it.
Another example concerns passing the correct values for the -L and -l flags to
the aformentioned CMAKE_*_LINKER_FLAGS cache entries because this serves no
purpose and the building fails to find the library to link to the final
executable.  Why not simplifying everything and just set 1 cache entry for the
<root> dir of the library that needs to be found ? You can easily find the
headers under <root>/include or the libs under <root>/lib .
To be fair this isn't always the case, for example with libxml2 the headers are
under <root>/include/libxml2 and not <root>/include, but my idea is that you
shouldn't set so many variables for just 1 library, it's redundant and leads to
confusion most of the time, and I invite you to try for yourself.

A minor fix will also be to force the use of some "gcc signed" cache entries
since I don't know how many still link with ld under linux when linking with
gcc it's probably a more modern approach, so something like "GCC_LINKER_FLAGS"
will probably fit better, but I think that the linking phase as it is now it's
not predictable and consistent in its own behaviour as it should be . And in
the end it doesn't even work.
-----
this is about the r206684 from the svn trunk, I also posted my configuration
and softwares used in a dedicated discussion on llvm-dev here
http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-April/072312.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140423/8fc2bbe6/attachment.html>