[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