Please Clarify CC Library Lookup Behavior

Help
Jason
2004-04-23
2004-04-24
  • Jason

    Jason - 2004-04-23

    I'm about done writing a tool which reads in a list of Visual Studio .NET solutions and outputs an ant build script which builds all the projects and toggles the settings for the CC task based on those in the project. In addition, it supports each project having debug and release configurations.

    However, I'm having a major problem with getting static dependencies during link to be looked up properly. For instance, say project MyProject has a dependency to myLib.lib. I know what directories it *could* be in, due to the VS.NET LibraryDirs settings, but I don't know which one it's in.

    My current understanding of the CC task is that nested filesets auction files to the compiler and if none takes it, to the linker. So if I was to include a library file, the linker should get it. My impression was also that if the lib file is in one of the (sys)includepath directories, a relative filename would be found. Unfortunately, this behavior doesn't seem to be working. By using libset I am able to include an entire known directory of libraries, but I don't necessarily want them all to link.

    So, my question is, knowing a library file and the directories it could be in, how do I specifiy this for CC so that it will properly find the library file and give it to the linker?

    FYI, I'm using the Intel C++ 8.0 Toolset for Windows (name="icl").

    Thanks a bunch!

    P.S. If there is interest, I could release the source to my tool once it's done. It's written in C++ and relies on boost::regex.

     
    • saber850

      saber850 - 2004-04-23

      The problem you're having when specifying a particular libset dir and getting all files in that dir is a bug that has been fixed.
      Here's the submission:
      https://sourceforge.net/tracker/index.php?func=detail&aid=936098&group_id=36177&atid=416920

      I'm not sure how much control you're looking for over the build options, but you could simply call the Visual Studio project/solution file and it will build automatically (due to MS's file associations).  I haven't performed this w/ Ant, but I know the NAnt (http://nant.sourceforge.net) project supports this.

       
    • Curt Arnold

      Curt Arnold - 2004-04-23

      libset and syslibset try to be aware of the library searching behavior of the underlying compiler.  So for example, if you do not specify a dir attribute on a libset and link with the Microsoft or ICL tools, all the directories in the LIB environment variable will be searched.  So if you are including a platform lib, then you should have a line like:

      <syslibset libs="advapi32,ole32"/>

      For msvc-like compilers , this will translate to adding advapi32.lib and ole32.lib to the file list, but will result in -ladvapi32 -lole32 on gcc type linkers.  Specifying a dir would be undesirable since it would make the script dependent upon your choice of installation directories.

      The dir attribute on libset are for use primarily when you know that the library is not on the library search path.

       
    • Jason

      Jason - 2004-04-24

      Thanks for the suggestions, but unfortunately I wasn't able to make any progress based on them.

      Let me reclarify my problem:
      I have a library, libMine.lib which is needed to build Project A. In the CC task, if I specify the library with <fileset file="C:\libFolder\libMine.lib" /> then Project A builds fine. The problem with this, however, is that I don't want to require all the developers working on Project A to have all the libraries in C:\libFolder.

      So, I added c:\libFolder\ to my LIB environment variables, and then specified the library with <fileset file="libMine.lib" /> and the CC task silently does nothing, and the linker fails.

      I also tried, instead of adding the path to my LIB environment variable, to use the CC task includepath and sysincludepath. Both failed to aid the CC task in finding my file for the linker.

      Finally, I tried using libset and syslibset tags like <libset libs="libMine.lib" />. The CC task echo'd a message saying the library was suspicious cause of the prefix and file extensions, so I removed them and then tried <libset libs="Mine" />. The library still wasn't found.

      So, my question is still, is it possible to have the linker receive a library file if I know only *the file* and a *set* of directories, of which one contains the correct library file? If so, how?

      Thanks so much,
      Jason

       
      • Curt Arnold

        Curt Arnold - 2004-04-24

        Option 1:
        <libset libs="libMine"/> and ignore the warning.

        or better rename it so it doesn't start with lib.

        The reason the error is there is that the same library name is expanded differently on Linux and Windows.  When you like with a -l option in gcc, for example, -lstdc++ you actually link with a file named libstdc++.so.5.  Cygwin and MinGW gcc's provide equivalents to the standard KERNEL32.lib, ADVAPI32.lib, but they are named libkernel32.a, libadvapi32.a, etc.  To allow one build file to handle both the platform specific library name mangling was embedded into cc's libset, so you could do <libset libs="advapi32"/> which would result in a -ladvapi32 on the gcc command and use the timestamp of libadvapi32.a in the dependencies or would add advapi.lib to the link when using a MSVC linker.

        The warning was placed there since using "libadvapi32" or similar would suggest a misunderstanding of the usage.  Unfortunately, your naming conflicts with that pattern.  If it is called "libMine.lib" on windows, it would need to be called "liblibMine.a" to following Unix conventions.

        Option 2:
        Parameterize the location

        <project..>
          <property name="add.libs.dir" value="/libfolder"/>

          <cc>
              <fileset dir="${add.libs.dir}" includes="libMine.lib"/>
          </cc>

        And users who don't use that path can specify:

        ant -Dadd.libs.dir=\myfolders\libfolder

         

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks