how to fix this error..??
Errormessage:
Program type already present: com.android.volley.Cache$Entry
Message{kind=ERROR, text=Program type already present: com.android.volley.Cache$Entry, sources=[Unknown source file], tool name=Optional.of(D8)}
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'com.android.support:appcompat-v7:26.1.0'
implementation 'com.android.support.constraint:constraint-layout:1.0.2'
implementation 'com.android.support:design:26.1.0'
implementation 'com.android.support:support-v4:26.1.0'
implementation 'com.squareup.retrofit2:retrofit:2.1.0'
implementation 'com.squareup.retrofit2:converter-gson:2.1.0'
implementation 'com.jakewharton:butterknife:8.4.0'
testImplementation 'junit:junit:4.12'
androidTestImplementation 'com.android.support.test:runner:1.0.1'
androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.1'
implementation 'com.github.bumptech.glide:volley-integration:1.4.0'
implementation 'com.android.volley:volley:1.0.0'
implementation 'com.android.support:cardview-v7:26.1.0'
implementation 'com.android.support:recyclerview-v7:26.1.0'
}
You just removeimplementation 'com.android.volley:volley:1.0.0'and addimplementation 'com.mcxiaoke.volley:library-aar:1.0.0'in your code and build it gives correct :)
Related
I'm in the process of migrating a C++ graphics application from header files to modules. A problem with circular dependencies (C++ modules and circular class reference) has been resolved initially. But now I'm stuck in a slightly more complicated situation.
I have a module with three partitions: Part1, PartBase and PartDerived. Two of the participants (PartBase and Part1) have a mutual dependency, which is resolved by means of a forward declaration. In addition, PartBase and PartDerived have an inheritance relationship. The real situation is of course more complex, but this is a stripped down configuration, where I can reproduce the issue.
export module Module:Part1;
// :import PartBase would create circular dependency
class PartBase; // forward declaration is ok
export class Part1
{
PartBase * pBase;
};
export module Module:PartBase;
import :Part1;
export class PartBase
{
Part1 * pPart1;
};
export module Module:PartDerived;
import :PartBase;
export class PartDerived : public PartBase {};
export module Module;
export import :Part1;
export import :PartBase;
export import :PartDerived;
The module compiles without any problems.
However, when a refer to classes defined in the module from an outside client module
import Module;
export class Client
{
PartDerived* pDerived;
PartBase* pPartBase;
};
the compiler reports an error in the line, where PartBase is used:
"unrecoverable error importing module 'Module': symbol 'PartBase' has already been defined"
I use Microsoft Visual Studio Community 2022 (64-bit) - Version 17.3.3.
I can't explain this message and suspect it's a compiler error. But I've learned that it's better to look for your own mistakes before blaming the tools. Does anyone have an idea?
Seems like a compiler bug, but it's really hard to validate since all compilers have bugs with modules.
With the current compilers, it worked for me to export the forward declaration in :Part1:
export class PartBase; // forward declaration is ok
export class Part1
{
PartBase * pBase;
};
Live example
I try to increase C++ version in XCode MacOS BigSure(11.0.4).
And optional header is found good but when I try to use std::optional I get an error No template named optional in std. In optional header I find implementation but part with
namespace std {
template <class T> optional;
...
}
is under the /**/.
I increase version in settings to C++17 and standard library to libc++(LLVM with C++11 support). clang version is 12.0.5.
How can i fix this trouble?
I have a library which can do GPU computation using the OpenCL framework. Sadly, OpenCL is not available on all platforms. However I would still like to be able to compile my code on those platforms, just excluding OpenCL functionality.
I think this question applies to all situations where you want to conditionally compile some external resource which may not always be available, and it messes with your library API.
Currently I have it set up like this:
CMake:
if(ENABLE_OPENCL)
add_definitions(-DENABLE_OPEN_CL)
find_package(OpenCL REQUIRED)
include_directories(${OpenCL_INCLUDE_DIR})
target_link_libraries(mylibrary ${OpenCL_LIBRARY})
endif()
C++
// settings.hpp, exposed to public API
class settings
{
int general_setting_1;
bool general_setting_2;
// ... Other general settings
#ifdef ENABLE_OPEN_CL
int open_cl_platform_id;
// ... Other settings available only when OpenCL is available
#endif
// More settings, possibly also conditionally compiled on other external libraries
};
// computation.cpp, internal to the library
#ifdef ENABLE_OPEN_CL
#include <CL/cl.hpp>
#endif
void do_things()
{
// ...
#ifdef ENABLE_OPEN_CL
if(settings.open_cl_platform_id != -1)
{
// Call OpenCL code
}
#endif
// ...
}
So when I compile the library, if I want to enable OpenCL I do cmake .. -DENABLE_OPEN_CL.
This works, but if the client is consuming the library compiled with ENABLE_OPEN_CL, it forces the client to define the same ENABLE_OPEN_CL, otherwise the included library's header file don't match the one used in the client, and very bad things happen.
This opens a whole can of worms, for example what if the client forgets to do it? What if it uses the same identifier name for something else?
Can I avoid this? If not, is there some way I could verify that the header files match on the client and the library, and cause a compilation error? Or at least throw a run-time exception? What is the correct approach to this scenario?
The obvious way to do it, is to leave open_cl_platform_id as a member of settings even if OpenCL is not supported. The user then gets a run-time error if they try to use OpenCL functionality when the library hasn't been compiled for it.
Alternatively, have two header files settings_no_open_cl.hpp and settings_open_cl.hpp, and require the user to include the right one.
I'm trying to use Cryptopp 5.6.2 on XPSP3 using VS 2010. New to this...
I need to use the mult-threading DLLs as that is what my application uses, so I changed all references in the Crypto++ project properties from /MT[d] to /MD[d]. All Crypto++ seems to build OK.
However, all is not happy with my C++ console app - I have the standard GetNewAndDeleteForCryptoPP and that seems to be called OK (remove it and cryptopp gives an error, include it and cryptopp doesn't print warnings).
All seems fine until I add in the line PKCS5_PBKDF2_HMAC<SHA256>. It compiles fine but causes two LNK2001 errors for unresolved symbols for CryptoPP::ThreadUserTimer::GetCurrentTimerValue(void) and
CryptoPP::ThreadUserTimer::TicksPerSecond(void).
Running out of ideas here - I can't paste the code due to arcane rules at the place I work, however I have included dll.h, cryptlib.h, osrng.h, aes.h, sha.h, hex.h, integer.h, modes.h and pwdbased.h.
Am I missing something blindingly obvious?
I was having this issue too, it doesn't look like that class is being exported. Adding CRYPTOPP_DLL to the declaration of ThreadUserTimer in hrtimer.h will fix it.
user1520427 provided you the answer. You need to add CRYPTOPP_DLL for a few classes and functions.
PKCS5_PBKDF2_HMAC<SHA256> is a header only implementation, so it does not need CRYPTOPP_DLL. See pwdbased.h.
However, ThreadUserTimer is not header only, so you need to modify hrtimer.h:
OLD:
00042 class ThreadUserTimer : public TimerBase
00043 {
00044 ...
00048 };
NEW:
00042 class CRYPTOPP_DLL ThreadUserTimer : public TimerBase
00043 {
00044 ...
00048 };
This is more of an answer than a question, because I've figured it out, at least as far as cleanly compiling the library. The main issue for me was to get shared_ptr working.
Ingredients:
Boost v. 1.45.0
The version of STLport at http://www.anddev.org/viewtopic.php?p=29939.
Version r4b of the NDK.
Directions:
In your Android.mk file add:
LOCAL_CFLAGS += -DBOOST_EXCEPTION_DISABLE -D_STLP_NO_EXCEPTIONS -DOS_ANDROID -D_STLP_USE_SIMPLE_NODE_ALLOC
Remove the call to __stl_throw_length_error at line 613 of stlport/stl/_string.h. You can use _STLP_NO_EXCEPTIONS if you like.
Edit boost/boost/smart_ptr/shared_ptr.hpp after line 261 to get rid of the call to boost::throw_exception in the shared_ptr constructor. I used #ifndef BOOST_EXCEPTION_DISABLE around the entire body of the method. (But see the answer below.)
Next you need to supply some missing pieces. Create a header file with the following:
#ifdef OS_ANDROID
#include <exception>
namespace std
{
struct bad_alloc : public exception { bad_alloc operator()(){}};
}
#endif
and a source file with a stripped-down exception class to support bad_alloc:
#ifdef OS_ANDROID
#include <exception>
namespace std
{
exception::exception() {}
exception::~exception() {}
const char* exception::what() const {}
}
#endif
Include the header wherever you're including boost/shared_ptr.hpp. Compile the source and add it to your library.
It turned out that this approach does not entirely work when compiling a debuggable library. The release library is compiled with -O2 which optimizes out some infelicities, but the debug library is done with -O0 which reveals some additional problems. Furthermore, I wasn't too happy about having to edit the boost files. So with some additional study, I've come up with the following solution.
First, don't edit any of the boost files. Instead add the following to the header within the std namespace:
struct bad_cast : public exception {bad_cast operator()(){}};
Next add the following to the source file:
namespace boost
{
void throw_exception(std::exception const&) {}
}
This now compiles and links into the application even with android:debuggable="true" in AndroidManifest.xml. It doesn't run in the emulator, but then it wasn't doing that before I included this library either.
Notably, NDK r5 comes with STLport, and the GNU STL, and so the hacks here are no longer going to be necessary now that there is a) STL support b) exception support in the NDK C++ compiler.
Another workaround for shared_ptr in particular is to use boost::intrusive_ptr instead. This is not always possible, but worked for my situation.
The current version of Android NDK (r9) now supports exceptions.
The capabilities of the various runtimes vary. See this table:
C++ C++ Standard
Exceptions RTTI Library
system no no no
gabi++ yes yes no
stlport yes yes yes
gnustl yes yes yes
stlport can get used in non-GPL binarys. It's still flagged as experimantal, but you can use it with clang and gcc.
See http://developer.android.com/tools/sdk/ndk/