[CMake] Creating a static lib from other static libs, HOW?

Juan Sanchez Juan.Sanchez at amd.com
Sun Sep 23 17:08:36 EDT 2007


Addendum to my previous email:

I find it absolutely entertaining that the command line length
limitation for command lines and environment variables on windows xp and
later is 8192.

http://support.microsoft.com/kb/830473

So while this doesn't affect AR.  It positively affect any solution on
windows requiring an explicit list of all files going into a library.

Regards,

Juan



Juan Sanchez wrote:
> On my Linux laptop, I used getconf to see that the maximum argument
> length is 131072.  This is not the maximum number of arguments.  I ran a
> test CMakeLists.txt, and the maximum length to the echo command from
> EXEC_PROGRAM was 128788 characters.
> 
> Fortunately, exec'ing a program will fail (non zero error code) if the
> argument list is too long.
> 
> This is linux only, and other architectures and csh, both have a
> reputation for having a much shorter command line length capability.
> 
> FWIW, it is well documented in the gnu ar documentation that your
> archives will get corrupted if you manage to call ar twice on the same
> archive at the same time.  Filename collisions are undesirable.  The
> posix specification says that the .o filename, and not its path, are
> used in the archiving process.  Therefore you need to be careful that
> you don't add the same .o filename twice to your archive.
> 
> Regards,
> 
> Juan
> 
> Brandon Van Every wrote:
>> On 9/22/07, Goswin von Brederlow <brederlo at informatik.uni-tuebingen.de> wrote:
>>> "Brandon Van Every" <bvanevery at gmail.com> writes:
>>>> If CMake considered it.  All I do is find the objects that CMake
>>>> already generated, then dump them directly into a library target.
>>>> CMake can swallow all kinds of stuff, *.c files, *.h files, *.o files,
>>>> whatever.
>>>>
>>>> This is part of why I think you guys should stop messing around with
>>>> non-CMake ways of doing things.  It either works and hey presto!
>>> Or it just goes horribly wrong in some hidden corner with totaly
>>> unpredictable effect and race conditions. That is why before
>>> introducing a concept like yours you have to think out what it all
>>> means.
>>>
>>>> you've got wonderful automagical cross-platform build stuff for no
>>>> work... or it doesn't work, and you're helping CMake improve by
>>>> submitting bug reports or feature requests.
>> Like I said the 1st time.  Help us improve CMake instead of working on
>> AR-specific stuff or wringing hands about theoretical bugs that
>> haven't been demonstrated yet.
>>
>>> CMake will have to use AR to create the archive and it has to limit
>>> the command line. If it does multiple ar calls to add more and more
>>> objects it can easily overwrite exitsing entries if the wrong options
>>> are used. Also commandline overflow is much more likely with long
>>> pathnames. Maybe just nobody cared about it yet since it never happens
>>> for normal dirs. Also with a single dir name collisions won't happen
>>> while with multiple dirs they might.
>> So go look in the CMake sources and see if there are automated test
>> cases that address these issues to your satisfaction.  If there
>> aren't, write some and contribute them.  This is open source.
>>
>> My method worked for my build.  I didn't make it public because I
>> didn't want to deal with the full support burden of proving that it
>> works everywhere for everything.  When pressured with competing, bad
>> solutions, I made it public.  But you still have to go to the bug
>> tracker and look up feature request #5155, so that's a barrier to
>> people making casual, uninformed use of it.  I'm not currently getting
>> paid to write test cases for it, so YMMV.
>>
>>
>> Cheers,
>> Brandon Van Every
>> _______________________________________________
>> CMake mailing list
>> CMake at cmake.org
>> http://www.cmake.org/mailman/listinfo/cmake
>>
>>
> 
> 
> 
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
> 
> 






More information about the CMake mailing list