I have a project that was compiling ok within g++(I can't see the version right now) and now on xCode it is not.
I think that I got the problem now... I have a String.h file in my project and it seems tha the xCode compiler(that is gcc) is trying to add my own string file from the < cstring >... I am not sure of it, but take a look at this picture
http://www.jode.com.br/Joe/xCode1.png
from what it looks like, it is including my own instead of the system file, I was wondering... shouldn't #include < file > be a system include? because of the < > ? and shouldn't the system include a file within its own path and not the original path of my application?
As I said, I am not sure if this is what happening because I am just migrating to osx these past 2 days...
I was going to change my class and file name to not conflict, so it would work, if this is really the problem, but I was wondering, there should be another way to do this, because now my project isn't that big so I can do this in some time, but what if the project was bigger? it would be dificult to change all includes and class names...
Any help is appreciated
Thanks,
Jonathan
i had the same problem and it was hard to solve. took my hours to fix/find out.
the problem is the headermap of xcode. and the solution - besides avoiding those kind of reserved names, which is a good idea in general, but not always possible with third-party libs - is to add
USE_HEADERMAP = NO
to your user defined settings.
kudos to these guys:
http://meidell.dk/archives/2010/05/08/xcode-header-map-files/
http://www.cocoabuilder.com/archive/xcode/262586-header-file-problem-sorry-to-bug-this-list.html
Naming your headers with the same name as standard headers like string.h and including them simply with #include <String.h> is asking for trouble (the difference in casing makes no difference on some platforms).
As you said, however, it would be difficult to try to figure out what those are in advance when naming your headers. Thus, the easiest way to do this is to set to set your include path one directory level outside of a sub-directory in which your headers reside, ex:
#include <Jonathan/String.h>
Now you don't have to worry about whether the String.h file name conflicts with something in one the libraries you are using unless they happen to also be including <Jonathan/String.h> which is unlikely. All decent third-party libraries do this as well. We don't include <function.hpp> in boost, for instance, but instead include <boost/function.hpp>. Same with GL/GL.h instead of simply GL.h. This practice avoids conflicts for the most part and you don't have to work around problems by renaming String.h to something like Text.h.
Yes, if you use
#include "file"
the local directory is looked first and
#include <file>
only the system include folders are looked.
Notice the word first only in the first case. This means that every time is included your local version should never be reached (unless you have included your source path within the INCLUDE directive).
Said that, my dummy suggestion is to rename your local file with an unambiguous name...
On OSX the filesystem is case insensitive - so String.h you can wind up with conflicts like that. String.h == string.h
it worked by changing the name from String.h to Text.h
but that makes no sense, since the std library is including it's own string.h and not mine.
I mean, makes no sense for a developer to create his files thinking of what names he can't use, for an instance, lets say I change my String.h to Text.h(I already did, I need to work and this is not letting me) ad somehow I had to include another templated library that has a include called Text.h, would I have to change my text.h again or not use this new library? there should be an alternative.
Or shouldn't it?
thanks for the help so far,
Jonathan
Two things you're running into:
As noted above, the filesystem on Mac OS is case-insensitive unless you specifically set up your filesystem to be case-sensitive.
gcc does not distinguish all that much between local and system header include paths. When you specify a directory to be added to the path via -I, that directory will be used to locate both local and system includes. Only when you use -iquote or -I- does a directory get skipped for locating system includes. Further, the builtin "system include" directories on the compiler's search path are always searched for local includes.
Note that the current directory is used for local but not system includes. In this case, I believe it's picking up String.h because the project settings explicitly add the top-level project directory to the include path.
The workaround I would suggest, rather than renaming your includes, is to put your utilities into a directory whose name is unique for your project, and specify that directory in your include directive. For example:
#include "Josk/String.h"
and make sure Josk/ itself isn't in your include search path. This way you aren't stuck with an awkward rename, though you may have to shuffle some files around in your project. You may also need to edit your project settings to make sure the parent directory of that utility directory is in your include path.
Another possibility to try is, if you see the top-level project directory added to your project's include path, remove it. This ought to keep items in your top-level project directory from being searched for system includes.
Finally, you may also be able to avoid this problem in this specific case by changing the case sensitivity of your file system. This can break some Mac applications, though, so research the issue before you embark on this – or pick a volume that nothing else is using.
This question already has some very good answers, yet none of them summarizes in all detail how the compiler will search for header files in general; or more precisely, how Xcode will make the compiler search for them.
When you include a user header, those are header files between quotes ("..."), the following search order applies:
The directory of the file performing the include.
All header search paths in the order provided.
First match inside a header map file, if headers maps are enabled.
Note that the full include path is used. So if your include is in the file foo/bar/file.c and you do a #include "subdir/header.h", then the first lookup will be foo/bar/subdir/header.h.
If that file doesn't exist, the compiler iterates the user header search paths. Those are provided by the build setting User Header Search Path (within config files or on command line it's named USER_HEADER_SEARCH_PATHS). Multiple such path can exist and again, the full include path is attached to each of them until there's a match.
If provides no match either and the build setting Use Header Maps (USE_HEADERMAP) is enabled, Xcode generates a map file of all your header files in the project and searches this map file for an entry that matches the name of the included file. In that case the path is irrelevant, as it would also match just the name of the file.
For system headers, those between spiky braces (<...>), only the search paths from the build setting System Header Search Paths (SYSTEM_HEADER_SEARCH_PATHS) are searched.
However if the build setting Always Search User Paths (ALWAYS_SEARCH_USER_PATHS) is enabled, the user search paths are also searched for system header includes. This allows you to override a system header with your own user header of the same name. Note however, that this is deprecated by Xcode and shouldn't be done anymore.
If your file system is case-insensitive, default on macOS, then case will play no role during all searches.
If you want maximum control over which file is being included, disable header maps and always include with a path relative to the file performing the include (you may use ".." as well). This avoids any ambiguity.
Related
I want to make a library that depends on other libraries.
I have been able to make the static .a files of the dependencies and have them along with the header files readily available in a directory. Running them through file confirms that I have successfully compiled these for all architectures.
When I try to make the final library, it tells me
ld: warning: ignoring file /usr/local....dylib, building for architecture-A but attempting to link with file built for architecture-B
It is correct that the library under the mentioned path is only compiled for the host architecture A (installed via package manager). However, in the LDFLAGS I have -L${libdir}/libs (the folder where the libs are) but make only seems to care about the ones in my usr/local/..folder.
Are there other ways to specifically point make to check the {libdir}/libs folder or even make make ignore the paths from pkg-config in case it searches there first, finds the unfit files and never gets to try the ones I passed in my LDFLAGS?
You write ...
I have been able to make the static .a files of the dependencies and have them along with the header files readily available in a directory.
... but this is probably irrelevant because you seem to be trying to build a shared (i.e. dynamic) library. Static libraries and shared ones don't mix very well.
Are there other ways to specifically point make to check the {libdir}/libs folder or even make make ignore the paths from pkg-config in case it searches there first, finds the unfit files and never gets to try the ones I passed in my LDFLAGS?
You are focusing on make, but make doesn't have much to do with it. It is the linker, not make, that performs the search and the actual link. make just executes the link command you told it to execute.
But yes, you can control the linker's library search order by controlling the order of its command-line options. Library directories specified via -L options are searched in the order they appear on the command line, and all of them before the linker's default library directories.* If ensuring a proper order of arguments does not get you the link you want then it is very likely because the linker is ignoring your static libraries because it is trying to build a dynamic one.
However you should be able to bypass the search altogether by specifying a full path and filename of the library you want to link instead of using -L or -l options. For example, instead of -L/path/to -lfoo, you might use /path/to/libfoo.dylib (or /path/to/libfoo.a). You don't normally want to hardcode paths like that, but in this case it might serve a diagnostic purpose to do so.
Note also that it is rarely a good idea to link against dynamic libraries that are not installed in their intended location, especially if the libraries are not part of the same project. It may seem at first to work ok, but it contributes to problems with finding the libraries at runtime (and dynamic libraries do need to be found at runtime, too). The same does not apply to static libraries, but that comes with its own set of advantages and disadvantages.
* There's more to it than that, but this answer is already long. Read the linker docs if you want more detail.
So, I understand that CLion currently only fully supports CMake projects. I don't care if I can't compile or run anything with CLion, as I don't currently do that with Eclipse anyway. I am just looking for editor support, with nice click-to-follow, autocomplete, etc.
What I am wondering is whether or not indexing can still work for non-CMake projects. I can create my project just fine, and indexing completes just fine, but after that is done it can't find my include files. It creates a default CMakeLists.txt file, in which the appropriate sources and include_directories have been added. It doesn't seem to make a difference though, as after indexing completes I still can't click-to-follow #include lines, and any references to things in other files don't work correctly.
Is there something else I can do to make indexing work so I can use CLion as an editor, or is this a pipe dream until Makefile support is someday added?
After some research, I found out your best chances are:
Once it's created, edit CMakeLists.txt (for example, see How to
find libraries). One example:
set(Library "../Library")
include_directories(${Library})
set(SOURCES main.cpp)
add_executable(project_name ${SOURCES})
Note ../ goes to the up folder and in the main.cpp you can use #include "header_to_add.h" (header_to_add.h must be in ../Library folder.
Edit the source code of you .cpp, .h or whatever to add the full path of the library you want to #include taking into account the scope starts in the directory where the file is.
For example: #include "../Library/header_to_add.h" (note the "../" goes one level up from the current folder".
(Maybe not possible or hard) Modify the makefile to prepare CMake to get the necessary inputs (for example, see this).
I recommend the first one mainly because it maintains the structure outside the source files.
Edit: Also it's possible to prepare CMake to use makefile (Source).
I have a situation where I am using two libraries which have duplicate header file names. For example timer.h exists in both libraries. I think the normal solution to this would be to explicitly specify the directory in the include like #include <dir1/timer.h> or #include <dir2/timer.h> so that the compiler has a clue as to which I am specifying. However, my problem is that one of the libraries I am using is not in a sub directory of my project. It exists somewhere else at a higher level. That is...
Root
Library1
Projects
ProjectFolder
Library2
This was done so that multiple projects could reference Library1. It seemed like a good idea at the time. However, now that I have the name conflict of Library2 it creates issues. One other important detail is that I often use two different workstations. The absolute location of Library1 on these workstations is not the same, nor is the relative location (with respect to the project folder) the same between the two. What I have been doing to this point is adding both absolute locations to the search path of the preprocessor.
Anyway, I'd appreciate any guidance you might offer.
You are on the right track with "dir1/timer.h" and "dir2/timer.h". But rather than think of it as dir think of it as "project1/timer.h". Now in your makefile you will need to have the location of project1 added to your include search path if it's not in a common location.
You shouldn't have relative paths in either your code (no ../file.h). They should be relative to the base directory of their project (e.g. #include <sys/socket.h> or #include <linux/sched.h>). Then it's up to your makefile to find them (those two examples are in the standard search path so they will work). For your case you can -I<path to project directory> and then #include "other_project/library.h".
I'd prefer including a copy of a specific version of the external library with my project and updating to a newer version as needed (but not actually changing the external library from the project). If you just refer to the current (changing) version that everybody uses, then your project may change behavior without even having its code changed. A release of your project would also have to refer to whatever version of the library you were using at that point in time to be complete.
If you did it that way, the relative paths are always the same (say, "../ExternalLib") if you want to use that approach. Or you can do as dave suggests.
I'm trying to use standard system header files in my C++ XCode project:
#include <openssl/bio.h>
#include <openssl/ssl.h>
#include <openssl/err.h>
The build fails and it complains:
"Openssl/bio.h: No such file or directory"
I added /usr/include to the "Header Search Paths" in Project settings, but that doesn't fix it.
I can fix it by adding the whole path like:
#include </usr/include/openssl/bio.h>
-- but the project is full of similar includes and I don't want to change all of them this way. Also, I feel I shouldn't have to do this.
Another way to fix it would be as another thread mentioned, which is to add /usr/include to User Header Search Paths. But if I do that, then I'd have to change all the angle brackets <> to quotes "", which again seems like a hack. I mean, these are standard system header files so I feel it should be something simple, not requiring these kinds of hacks.
Any ideas?
Thanks!
Xcode uses the currently selected SDK as a base path, which it prefixes on to system includes. So if your SDK is /Developer/SDKs/MacOSX10.6.sdk then it will look under /Developer/SDKs/MacOSX10.6.sdk/usr/include by default for system includes.
There are various possible workarounds - I would probably just put a symbolic link in /Developer/SDKs/MacOSX10.6.sdk/usr/include pointing at /usr/include/openssl but you can probably think of others now that you know the underlying problem.
It might depend on the fact that HFS(+) is case insensitive. The error message talks about "Openssl/bio.h" with capital "O", but you're specifying "openssl/bio.h" in the include and the path with /usr/include works.
I suspect that there's some "Openssl" (capital "O") directory in your include path, that gets used when looking for "openssl/bio.h". This wouldn't happen if HFS(+) were case sensitive from the very beginning (I know it's possible to have is case sensitive, but it's actually a PITA to use...)
I've been able to avoid having to specify paths on includes by simply making sure to select Create groups for any added folders for the Folders option in the Add Files to Project dialog which pops up when you're adding the files.
With the other option, Create folder reference for any added folders, I have to manually point it to the file via the full path (and the folder icons show up blue instead of the normal beige). Interestingly, even in this case, AutoComplete sees the file, but Xcode complains it can't find it.
I have a program that I need to run under *nix and windows. because the program takes file paths from files the issue is what to do about the \ vs / issue.
My current thought is to put in a regex that converts the wrong one to the right one depending on what system I'm on. This will have the effect of letting either type work on either system. Aside from the fact that now I have two problems, does anyone see any other problems?
(Other better solutions are more than welcome)
Edit: the primary issue is getting windows paths to work on unix rather than the other way around.
The / is fully supported in win32 too.
Also see this related question
Windows will generally accept either \ or /,so standardizing on / may make your problem simpler as long as you have complete control over the filenames.
Have you considered creating a "file manager" class that will handle all of the file pathing issues for you? That way in your mail application, when you're loading a data file, you can call something like this.
LoadApplicationData(FileManager.GetDataFilePath)
Then your file manager will detect the environment that it is in and return the proper file path option. That way you can also accomodate for Win32 vs. Unix locatio standards (like Program Files vs /usr or whatever) as well.
Note that Win32 paths are complex when you consider drive letters (no analog on Unix) and the special 'forks' (MacOS pre-X term - likewise no analog on Unix in general, though MacOS X has them - surprise, surprise) that can be provided. Be careful.
Create a parser for your input to create a tree structure of nodes representing directories. Then you can 'save' by walking the tree and writing whatever delimiters you want or optionally doing different things, like checking if the directory exists or writing meta files. This is actually something that I am just now thinking would be useful for my own application :-)
You didn't say what language you are using, so I'm going to selfishly assume c/c++. boost, if you are willing to use it, has a filesystem library. Of course, if you are using a dynamic language, FS abstraction libraries probably already exist there too (e.g. in perl, File::Spec is quite standard).
You haven't told us what sort of files you are reading paths in from. I am going to assume that they are config files. In which case, there are many ways, IMHO the correct answer is to design your program to avoid manipulating paths, if possible. I posted an answer here: https://stackoverflow.com/a/40980510/2345997 which is relevant.
ways:
Add a command line option which allows a user to specify the path in question instead of reading it from a config file.
Add a command line option so that the user can specify a base path. Paths in the config file will be interpreted as located under this base path.
Split your config file into three. One file will have cross platform configuration, another file will have windows only configuration and a final file will have Linux only configuration. Then the user can specify the correct path for both Windows and Linux. On windows your program will read the cross-platform config file and the windows only config file. On Linux it will read the cross-platform file and the Linux only config file.
Add preprocessing to your config file parsing. This will allow you to have one config file where the user can make your program ignore some of the lines in the file depending on which OS the program is running on. Therefore, the user will be able to specify the path to the file twice. Once for Linux, and once for Windows.
Change the design so that the files are always located in the same directory as your executable - then the user only specifies file names in the config file rather than paths to files.
Use a simple function that switches "/" to "\". Then document to the user that they must specify paths as Linux paths and this transformation will be applied for windows.
Create your own path mini-language for this and document it to the user. E.g: "/" - specifies a directory separator, {root} - expands to the root of the filesystem, {cwd} - expands to the current directory, {app} - expands to the path to your application etc... Then the user can specify file paths like: {root}/myfiles/bob.txt on both platforms.
Some paths will work on both platforms. E.g: relative paths like ../my files/bill.txt. Restrict your application to only work with these paths. Document this limitation and how your application handles paths to the user.