Once again a mystery from Project A and Project B. I can compile Project A without problems. Both projects have their source .PAS files in the same directory but they are separate projects.
I use a partition called Drive-O and a subdirectory within Drive-O to host the projects. However, when I load project B most, but not all of the .PAS files are shown with little red Xs. So it appears they were not found by the compiler in Project B, but no problems with project A.
Curiously I examined the [closed files] in the .DSK files and found that for Project A all files showed uniform paths "O:\SubDirectory\xxx.pas" but in B.dsk there was a mixture of valid paths and an old location for the project in Users\Martel\Subdirectory\xxx.pas.
So this appears to be problem. Is there way to correct this discrepancy? Where does the .DSK file get its data, and what is its role in loading a project? Might I delete the file and have it rebuilt?
All explained above.
Related
This may be a bit of a XY problem in that it involves symlinking files into the source tree. I sometimes do this in development with libraries that are common to a number of application projects. More conventionally they would (and later will) be just .aar imports. Not doing that simplifies API tweaks on the library in the context of the application code -- an option would be to automate packing and importing the aar, but that is still more of a PITA and means I either run two projects in the IDE at the same time (untried) or else switch between them.
Generally the symlinks are just directories, but currently I am doing it with individual files, and a strange problem has blossomed trying to build the app involving "Redeclaration" errors. This occasionally happens with the directories, but it is usually resolved by a gradle re-sync or an invalidate-and-restart.
To be clear, the problem is one that should not exist and smells very much like a bug: The "redeclaration" refers to the symlinked locations which are not in the build tree or project folder -- ie., the redeclaration involves processing the same file twice with different paths.1
Frustratingly, invalidate-and-restart did not work with the individual files, so I removed the symlinks and just copied the files in. No more symlinks, but bizarrely the same problem happens:
./gradlew assemble
> Task :app:compileDebugKotlin FAILED
e: /home/devel/Android/lib/droidutil/src/cogware/droidutil/Plexus.kt: (5, 8): Redeclaration: Plexus
e: /home/devel/Android/template/FooDemo/app/src/main/java/cogware/droidutil/Plexus.kt: (5, 8): Redeclaration: Plexus
(Same thing using the IDE.) The project folder here is /home/devel/Android/template/FooDemo. /home/devel/Android/lib/droidutil/src/cogware/droidutil/ is not part of it -- although to be fair there are still other symlinks into it, all gradle needs to do is follow the explicit path set for it. What seems to be happening now is:
It resolves symlinked paths and uses them not instead of the symlink paths, but as well as.
It even searches around in the resolved paths for files that match names in the proper tree! To explain: After I removed the symlinked files, symlinked directories (which are working fine) remain, but not into the droidutil directory above. There is, eg. a /home/devel/Android/lib/listfilterstack linked in, and it still manages to find a "Redeclaration error" in /home/devel/Android/lib/droidutil/src/....
The only thing that would make less sense would be if it were searching around the whole filesystem at random.
Why does it retain this path and how do I get rid of it?
Invalidate-and-restart does not make any difference. I've tried adding this to app/build.gradle:
android {
...
sourceSets {
main {
java {
exclude '/home/devel/Android/lib/**'
srcDirs = [ 'app/src/main/java' ]
}
}
}
Which exclude apparently has no semantic value there -- same error. Invalidate-and-restart again -- same error.
Short of wiping my hard drive and starting the project again from scratch on another computer in a different time zone, the only thing that has worked is for me to literally move /home/devel/Android/lib to somewhere completely else so that the path no longer exists. I should not have to do this. I should be able to explicitly set where the build tool searches for sources, and not have it unravelling symlinks and prowling around hither-and-thither.
I miss include guards.
Seems like it is a bug, but unfortunately the kind that will probably never be completely fixed:
https://github.com/gradle/gradle/issues/3982
Not exactly the same context or symptoms, but the takeaway for me is that gradle was not implemented to deal with symlinks in an intelligent way, hence:
Don't use symlinks with gradle.
I realise this is a newb question but I've been racking my brains for hours.
So I want to use the STK (Synthesis Toolkit) to generate sine waves etc. I've downloaded the source files from https://ccrma.stanford.edu/software/stk/download.html
I unzipped the tar.gz using 7zip.
I opened up the demo.cpp project file (under /projects/demo/demo.cpp) and whenever I try to compile it, I receive lots of errors, all starting with "undefined reference to"
I have set the compiler search directory to include the root folder of the stk kit (unzipped as "stk-4.5.0"). My understanding is that I also have to find file for the linker, that is of the type .lib? Is that correct? I haven't been able to find a .lib file to link to.
I feel like this is a simple fix - what am I missing?
You've downloaded a source , not the compiled library which might be used by linker (.lib file) There are three solutions:
1. Compile whole src folder of your download ( see instructions on their website). Frankly, I've tried to do that recently but failed, especially under Windows although I don't have any experience in this so you can try yourself.
2. Use precompiled library available in some Linux repositories. I had success with Slacko Puppy linux. Package simply adds libstk.a (linux static library) to /usr/lib and stk headers to /usr/include/stk (notice you have to add exactly that path to compiler, since /usr/lib is not enough). This gave me best results.
3. If you use only several classes, you can copy their .cpp files directly to your project source folder. Remember to add parent classes, too (see STK site -> Classes). Again I recommend that you give the compiler path to include folder you've unzipped, but copying only selected headers should also work.
I've found this article helpful (see also A1): http://www.learncpp.com/cpp-tutorial/a3-using-libraries-with-codeblocks/
Hope I've helped
I got this error using Visual Studio 2008 and I found a solution on the web here and here. But I can't find out how to configure link.exe.
How can I set the /expectedoutputsize:600000000 option for linker.exe in VS2008? I searched in the project properties in the Linker section, but I can't find the place...I searched in the solution and in Visual Studio options. I found the linker.exe.config but I don't know the schema.
My problem is not the disk space, I have plenty of disk space. Any help?
The option must be added in the Project Settings->Librarian->Command Line->Additional options: text box.
Sorry to resurrect this old thread, but I had a similar problem yesterday, and my solution had nothing to do with anything I found online. This is the first SO post that comes up, so I figured I would contribute in case anyone as the same problem.
Here is how I ran into the problem:
I originally had a project that created an exe:
MyProject.vcxproj -> MyProject.exe
I then turned the original project in to a .lib project by splitting main.cpp out to a separate .exe project. I set the target name for the exe project to be the same as the lib, so that we wouldn't change our executable name. I also added a different .exe project that uses the library but has a slightly different main.cpp
MyProject.vcxproj -> MyProject.lib
MyProjectVariant1.vcxproj -> MyProject.exe
MyProjectVariant2.vcxproj -> MyProjectVariant2.exe
The way our solution is currently laid out, all of the projects dump their targets into the same output directory.
The problem was that both the .lib and first .exe share the same target name, so any secondary files (pdb files, iobj, ipdb, etc.) would get overwritten. MyProject.exe would literally overwrite these ancillary files before it could link in the MyProject.lib.
Conclusion:
I "fixed" the problem by using a unique target name for the first variant. We will also review our build strategy to see if we should be using different output directories for each project instead of slamming them all together in the same location. Seems more logical to give them different target directories.
I am pretty experienced writing my own code, but not in C++. I am used to adding .NET assembly references, and I want to get into using C++.
I downloaded a VC++ 6 project presenting a graph algorithm, opened it in Visual Studio 2010 Ultimate and downloaded the required libraries (LEDA .NET assemblies) however, they came with both DLLs and LIB so I thought I would have no problems with the .NET and C++ connection. Also, the LEDA project comes with C++ style .header files, and static libraries, yet frustration persists.
I put my LEDA header files in a directory visible to the project, since I can "Go to definition" of all the custom LEDA data types and see where they are defined in the LEDA include files.
But, I can not compile/link these data types in. The VS finds their very existence repulsive, and refuses to acknowledge they could possibly be found in leda.lib.
Steps I have already taken:
Added additional /LIBPATH path under Properties ->Linker->General
Added explicit lib references under Properties->Linker->Input
Added all the paths containing LEDA header files and libraries to every path location I can find, like include path, reference path, library path.
Copied the DLLs and LIBs to the release folder as well as the base folder of the project.
Added a #pragma comment( lib, "leda" )
Still no joy.
It's quite bad since none of the custom typedefs are recognised the errors balloon to 646 errors.
If anyone is kind enough to offer assistance, thank you.
I can't guarantee this will work but try the following steps (therefore using it's default predefined paths instead of setting your own ones) :
1) Copy *.dll into Windows/System32 or / and (there is some confusion about x64 and x32 default checking in my head :)) Windows/SysWOW64.
2) Copy *.h files into x:\PathToVC2010\include\
3) Copy *.lib files into x:\PathToVC2010\lib\
All was right in the world until I upgraded to Xcode 4 a few days ago. Since then I've had endless problems getting things to work as they should. And I have a crucial update I need to release. I've tried every permutation of settings I can think of, restarted, reinstalled Xcode, reverted to old versions of my files, everything.
My project links to three static libraries, contained in three other projects. I have used the standard processes to link libraries (drag the project files into mine, add their products as target dependencies, add the lib---.a files to the Link Binary With Libraries phase). And actually, I have no problem compiling with the Debug Build Configuration, either for the simulator or my test device.
Where everything goes sideways is when I compile with the Release Build Configuration, or when I try to Archive. I've gotten many different errors depending on my settings, but most are variations on this:
ld: warning: ignoring file
[...]/Build/Products/Debug-iphonesimulator/libGDataTouchStaticLib.a,
file was built for archive which is
not the architecture being linked
(armv6) Undefined symbols for
architecture armv6:
"_OBJC_CLASS_$_GDataSpreadsheetData",
referenced from:
objc-class-ref in ExportViewController.o
I can't understand why it's even looking at Products in the Debug-iphonesimulator directory (I swear, everything I'm linking to reveals itself in the Finder to be in the proper Release-iphoneos directory).
I have put a ridiculous number of hours into fixing this, really need help! Thank you!
Please check this question and answer. I encountered same problem and fixed it.
Xcode4 Linking Problem. File was built for archive which is not the architecture being linked (arm6)
I solved this problem by copying the .a lib files from the Release-iphoneos directory to the Debug-iphonesimulator directory so that the correct files would be found even though Xcode was looking in the wrong directory.
However, then I encountered the problem raised here of a multi-application bundle -- and the solution given didn't work for me. Finally gave up and reinstalled Xcode 3. Compiled, archived, and uploaded to the App Store in 20 minutes. Will be some time, and several dot-releases, before I give Xcode 4 another shot.
You may have -DGDATA_REQUIRE_SERVICE_INCLUDES=1 enabled in your other C flags for the GDataTouchStaticLib target. If so, add the service you need, in this case, spreadsheets, by adding -DGDATA_INCLUDE_SPREADSHEET_SERVICE=1 to your Other C Flags. Or if you don't want GData to require service includes (which will build everything into the static lib, not just what you need), just remove the DGDATA_REQUIRE_SERVICE_INCLUDES flag.