Re: Argument list too long build error

[David Turner]

You could try adding

  LOCAL_SHORT_COMMANDS := true

to your module's Android.mk, this was added to solve exactly this sort of problem. See $NDK/docs/ANDROID-MK.html for details.

On Fri, Jan 11, 2013 at 9:09 PM, kumar <gampa....@gmail.com> wrote:

Hi,

I am  creating a static library from many source files, I am getting "Argument list too long error" before generating a static library.
I am using android-ndk-r8c, I saw some posts related to the similar error but they provide some work around for building shared library not for static library.

Can any one give suggestions please.

Thanks in advance.

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/android-ndk/-/pU_ApG-f2KwJ.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[foo64]

From ANDROID-MK.html:

    NOTE: We do not recommend enabling this feature by default, since it
          makes the build slower.

I would instead recommend adding an "all.cpp" file which contains the following:

    #include "file1.cpp"
    #include "file2.cpp"
    #include "file3.cpp"
    ...

Your Android.mk file would then do this:

    LOCAL_SRC_FILES := all.cpp

As a bonus, it's actually quite a bit faster to compile all.cpp than all the separate files (due to not reparsing the same headers). However, be aware you may get new compile errors. A common one is variable/function naming conflicts between previously separate source files, for example:

    file1.cpp:
    static void func() {}

    file2.cpp:
    static void func() {}

Another common error is conditional includes such as:

    file1.cpp:
    #define WIN32_LEAN_AND_MEAN
    #include <windows.h>

    file2.cpp:
    #include <windows.h>
    CallWin32Function( ); // may not exist anymore due to WIN32_LEAN_AND_MEAN from file1.cpp

[dtx0]

Where're the conditional preprocessor macros?

  file1.cpp:
    #define WIN32_LEAN_AND_MEAN
    #include <windows.h>

Shouldn't that be more like:

  file1.cpp:
    #ifdef WIN32_LEAN_AND_MEAN
    #include <windows.h>
    #endif
Or,
  file1.cpp:
    #if defined(WIN32_LEAN_AND_MEAN)
    #include <windows.h>
    #endif

---------------------------------------------------------------

On another and more important note, it's a simple run-of-the-mill cpp file using "standard" precompiled libraries as shown here (e.g., <iostream>, not <iostream.h>). Don't use "#include <*.cpp>, that's bad practice -- that's precisely what makefiles are for.

[Ray Donnelly]

...the whole point of this discussion thread just went whizzing over your head.

...including the meaning of WIN32_LEAN_AND_MEAN.

Epic.

> --
> You received this message because you are subscribed to the Google Groups
> "android-ndk" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/android-ndk/-/YnfI3sK0rNgJ.

[dtx0]

Another common error is conditional includes such as:

"#define WIN32_LEAN_AND_MEAN" resolves to essentially being defined as whitespace. That's not conditional, that's still a definition. Have you ever seen "#define __P /**/" ? Please read carefully next time mingw, thanks.

[Ray Donnelly]

I wish I'd not started this now. I'm tempted to post a lmgtfy link,
but instead please search for WIN32_LEAN_AND_MEAN in this wikipedia
article:

http://en.wikipedia.org/wiki/Windows.h

the point that you're missing about CPP macros is that you can test
for their definition in using "#ifdef" or "#if defined" and use this
to exclude or include code.

I feel like I am being beaten with experience here.

On Wed, Jan 16, 2013 at 9:01 AM, dtx0 <bbad...@gmail.com> wrote:
> WIN32_LEAN_AND_MEAN

[dtx0]

Once again, you have failed to carefully read. The original points I had been trying to convey are form, style, and properness. 

I am fairly sure I understand something as simple as conditional preprocessor directives as evidenced most recently here. Ironically enough, it was foo64 to whom I replied in both instances (i.e., the prior post linked and this one). Conditional includes is exactly what I had touched upon; and, with it, the common understanding that these conditional directives are used to include or not include code, be it a header file, some function, a struct or union, or whatever (e.g., include guards).

Mingw, what you fail to understand is that I was pointing out that there was no conditional macro there in the code originally supplied above in foo64's post; there isn't even an "if" substring in that code. Simple. 

Not to be pedantic, but I once again find it necessary to touch upon the point I earlier in this thread about style and form. Have you ever seen "#include <somefile.cpp>" in a cpp file? No. Why? Because we know that modular projects -- be they a library or whatever -- with multiple cpp files and headers are created with the exact purpose of having each file containing what it must. For example, headers would have the functions prototypes and the cpp files have the function definitions. Everyone knows this.

Now it is I who feel I have been beaten by experience and dragged down to your level. As a kind and gentle reminder, please read carefully in the future.

[David Turner]

On Wed, Jan 16, 2013 at 9:37 AM, dtx0 <bbad...@gmail.com> wrote:

Where're the conditional preprocessor macros?

They are inside <windows.h>. Header typically provide "guard macros" to ensure that a single header is only parsed only once, even if it is included multiple times, as in:

foo.h:

  #ifndef FOO_H

  #define FOO_H

  ...

  #endif  /* FOO_H */

<windows.h> is also special because it will declare different things if WIN32_LEAN_AND_MEAN is defined or not before its inclusion.

foo64 is describing a case where two source files, which were written as independent, as concatenated into a single one, so a sequence like:

// from foo1.c

#define WIN32_LEAN_AND_MEAN

#include <windows.h>

// from foo2.c

#include <windows.h> 

...

CallWin32Function( )

...

Will result in the <windows.h> header being parsed only once, with WIN32_LEAN_AND_MEAN defined. This will explicitely disable the declaration of a ton of functions / types (in order to speed up the build). Actually, even if the header was parsed twice, WIN32_LEAN_AND_MEAN would still be defined anyway.

And the problem is that if the code in foo2.c tries to call a function that has been disabled by WIN32_LEAN_AND_MEAN, this will result in a compilation error of the concatenated source.

  file1.cpp:

    #define WIN32_LEAN_AND_MEAN
    #include <windows.h>

Shouldn't that be more like:

  file1.cpp:

    #ifdef WIN32_LEAN_AND_MEAN
    #include <windows.h>
    #endif
Or,
  file1.cpp:

    #if defined(WIN32_LEAN_AND_MEAN)
    #include <windows.h>
    #endif

Nope, as Ray pointed you, WIN32_LEAN_AND_MEAN has a special meaning when including <windows.h>, please read the documentation.

file1.cpp and file2.cpp are both correct, because they each include <windows.h> differently. The problem only appears when trying to concatenate them (either manually or by including them in succession as described by foo64).

 

---------------------------------------------------------------

On another and more important note, it's a simple run-of-the-mill cpp file using "standard" precompiled libraries as shown here (e.g., <iostream>, not <iostream.h>). Don't use "#include <*.cpp>, that's bad practice -- that's precisely what makefiles are for.

I think you didn't understand foo64's point at all. Some people do include C/C++ source files this way to generate more compact builds. This requires extra care in the way each source file is written, but this can result is smaller / more optimized code in the end. E.g. FreeType uses this technique quite extensively (it also uses special macros to toggle function definitions to 'static' in this case automatically).

While it's generally not a good idea, but there are cases where this is useful.

 

In the end, I would discourage programmers to use foo64's technique unless they control 100% of the sources they concatenate in this way, which should be pretty rare in practice.

On Friday, January 11, 2013 12:09:09 PM UTC-8, kumar wrote:

Hi,

I am  creating a static library from many source files, I am getting "Argument list too long error" before generating a static library.
I am using android-ndk-r8c, I saw some posts related to the similar error but they provide some work around for building shared library not for static library.

Can any one give suggestions please.

Thanks in advance.