I'm on Ubuntu 12.
I'm trying to compile an Objective-C hello_world app using clang. This is the source:
#import <Foundation/Foundation.h>
int main (int argc, const char * argv[])
{
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
NSLog (#"hello world");
[pool drain];
return 0;
}
I use this commandline:
. /usr/share/GNUstep/Makefiles/GNUstep.sh
clang h.m `gnustep-config --objc-flags` -lgnustep-base -o hello
I get the following error:
clang: warning: argument unused during compilation: '--param ssp-buffer-size=4'
In file included from h.m:1:
In file included from /usr/include/GNUstep/Foundation/Foundation.h:30:
In file included from /usr/include/GNUstep/GNUstepBase/GSVersionMacros.h:193:
In file included from /usr/include/GNUstep/GNUstepBase/GSConfig.h:229:
/usr/include/GNUstep/GNUstepBase/preface.h:112:11: fatal error: 'objc/objc.h'
file not found
#include <objc/objc.h>
^
1 error generated.
The same commandline using gcc works fine.
Any ideas how to fix this missing objc.h error?
obj-c.h is part of the Objective-C runtime, have you got that installed? From my own experience GNUstep seems to be a world of hurt on most platforms, so it may simply be GNUstep's configure scripts refusing to pick it up even if it is installed, try their mailing list if you can't get a better answer here.
That header comes as part of the ObjC-Runtime. While GCC provides a runitme (although one only without the modern features like ARC), Clang/LLVM doesn't sport such a runtime. If you want to use Clang, you need to install GNUstep's ObjC runtime , which you can find here:
https://github.com/gnustep/libobjc2
For Ubuntu, there are bash scripts available at the GNUstep-wiki, which help you in the somewhat complicated GNUstep installation process:
http://wiki.gnustep.org/index.php/GNUstep_under_Ubuntu_Linux
and one more tip: you should not try to reinvent GNUstep-make by trying to use the compiler manually, like you did. Better use GNUstep-make:
http://www.gnustep.org/resources/documentation/Developer/Make/Manual/gnustep-make_1.html
I am newbie on MacOs. Today I had to build pyobjc Cocoa python wrapper in nix and have to deal with clang. I had similar error. As any C developer first I extended CFLAGS with I/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/usr/include, but it didn't change anything. After scratching my head for quite awhile I tried to call clang manually just with -I and it was working! So -isysroot disables -I and doesn't do anything on its own. I found -iwithprefix and put it with path I used with -I and it works with -isysroot, which I cannot easily remove - it is injected somewhere inside nix derivations into CLFAGS.
Related
I have a Qt4.8.4 desktop application that builds and runs fine on my Macbook Pro, running Mountain Lion with Xcode 5.0.2, using Qt Creator 2.7.0 with Qt 4.8.4 and GCC (x86 64bit). I am trying to port my application to Qt 5.2.1. My code is C++ with some Objective-C.
I built Qt5.2.1 on my same Macbook pro with this configuration:
./configure -prefix $PWD/qtbase -debug-and-release -developer-build -no-c++11 -opensource -plugin-sql-sqlite -nomake tests -confirm-license
and it configured and built fine.
When I try to build my application in Qt Creator 2.7.0 using Qt 5.2.1 and either GCC (x86 64bit) or Clang (x86 64bit), I get lots of errors that seem to me to indicate that the Objective-C parts of my application can't find the libraries they need. For example:
/Users/david/dev/svn/map_creator3/src/widgets/mac_toolbar_button_proxy.mm:15: warning: instance method '-selectedSegment' not found (return type defaults to 'id') [-Wobjc-method-access]
target_->TriggerAction([sender selectedSegment]);
^~~~~~~~~~~~~~~
/Users/david/dev/svn/map_creator3/src/common/locations_mac.mm:34: error: use of undeclared identifier 'NSWorkspace'
[[NSWorkspace sharedWorkspace]
^
/Users/david/dev/svn/map_creator3/src/widgets/mac_toolbar_button_control.mm:30: error: unknown type name 'NSAutoreleasePool'
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
^
and lots more like that. Is there some magic setting somewhere that I need to add, to use Object-C in a C++ Qt5 desktop application?
Merlin069 got me on the right track in the comments on my question (thanks!), and I found an example here. These build errors (and a number of others) disappeared when I added
LIBS += -framework Cocoa
and in my .mm files that were complaining,
#include <Cocoa/Cocoa.h>
Hi I'm learing Lex and yacc. I created the following lex program.
%{
#include <stdio.h>
%}
%%
[0123456789]+ printf("NUMBER\n");
[a-zA-Z][a-zA-Z0-9]* printf("WORD\n");
%%
I'm trying to run it using the following commands:
lex example1.l
cc lex.yy.c -o example1 -ll
also tried cc lex.yy.c -o example1 -lfl
When I enter the second command form above, I get error:
D:\workdir\flexyacc\Test3>gcc lex.yy.c -o Test -lfl
C:\Dev-Cpp\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe: cannot find -lfl
collect2: ld returned 1 exit status
I tried googling this error but no luck so far. Since I'm new in Lex programming, I'm not understanding how to fix this. Any help will be greatly appreciated. Thank so much in advance.
If you are using lex + yacc you can remove -lfl if you define yywrap function or, even better, if you use noyywrap option:
%option noyywrap
%%
...
%%
To compile the lex code, firstly you should have installed flex in your machine.
If so , there will a file libfl.a. In my machine I've installed flex in 'C:\GnuWin32\lib'
gcc lex.yy.c -L"C:\GnuWin32\lib" -lfl
I encountered the same problem and so i checked it out in the Internet and found a solution by workingcaptchabypass posted June 3, 2011 6:44 PM here
he said:
You could add this function instead and compile normally
yywrap()
{
}
And so i supplied the code in the .lex file before the main function. After doing that, it worked out the way it should :)
I have run into this issue when porting TXR to Windows using MinGW.
MinGW has a flex library for itself, but does not export it to the environment.
See here: http://lists.nongnu.org/archive/html/txr-users/2011-10/msg00001.html
The workaround is to use -L/usr/lib before -lfl. But think about this: it is a hack. Why? Because the path /usr/lib/ belongs to MinGW, the compilation environment's run-time.
/usr/lib is not where the toolchain is supposed to find libs for the Windows program being built (which is it's not in the library search path!)
That is to say, we are effectively stealing the build machine's native library in a cross-compile job.
This is like if you were cross-compiling, say, a Fedora program on Ubuntu, and helping yourself to Ubuntu's static library in /usr/lib that happens to be missing in the Fedora cross toolchain (taking advantage of the fact that the architecture and object file format happens to be the same).
It's definitely a bug in the way Flex is "packaged" in MingW.
After having a hard time trying to fix the same problem as yours, I installed flex-old:
sudo apt install flex-old
Try using -ll instead of -lfl in gcc
If you are on macOSX then replace -lfl with -ll
For error:
cannot find -lflx
In your Makefile change:
LEXLIB = -lfl to LEXLIB =.
Otherwise remove the -lfl argument wherever present.
I have a question relating to this question Unable to Compile Objective C using Gnustep on windows
I am trying to compile my first objective c app on Windows.
The file is hello.m (all files below created in Visual Studio)
#import <../Program Files/GNUstep/System/Library/Headers/Foundation/Foundation.h>
int main(int argc, const char* argv[])
{
NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
NSLog(#"Hello from Hello.m!");
[pool release];
return 0;
}
In order to compile it I have a GNUmakefile in the same directory:
include $(GNUSTEP_MAKEFILES)/common.make
TOOL_NAME = hello
YourProg_OBJC_FILES = hello.m
include $(GNUSTEP_MAKEFILES)/tool.make
As I understand it, when I run make the command "make" the GNUmakefile will execute.
When I do this in the GNUStep shell I get an error
GNUmakefile:1 *** missing separator. Stop.
I tried adding a tab to the first line. This did nothing. Yes, I am sure it was a tab, not a space.
I Had the same problem. I used Notepad++ to make the GNUmakefile. My default encoding with Notepad++ is UTF8. But make.exe from MINGW32 seems to wait a file with ANSI encoding.
So, verify if your file is encoded with ANSI.
make is complaining about your makefile, so you probably have a syntax error somewhere.
See: http://www.gnu.org/software/automake/manual/make/Error-Messages.html:
This means that make could not understand much of anything about the makefile line it just read. GNU make looks for various separators (:, =, recipe prefix characters, etc.) to indicate what kind of line it's parsing. This message means it couldn't find a valid one.
Try you might try compiling directly:
gcc -o hello hello.m -I/c/GNUstep/GNUstep/System/Library/Headers \
-L /c/GNUstep/GNUstep/System/Library/Libraries -lobjc -lgnustep-base \
-fconstant-string-class=NSConstantString
you should never have to provide the full path for the Foundation.h header file.
It should always be #import <Foundation/Foundation.h>.
This together with your makefile problem indicate that something is not setup correctly on your machine.
Did you run the make command from an msys shell or from the Windows commandline?
If you chose to go with the Windows command line you will face some problems because the environment is not setup correctly there in contrary to the msys shell provided with the GNUstep installer.
If you want to run gcc manually on the other hand you can have a look at this SO answer.
In your GNUmakefile, YourProg_OBJC_FILES should be modified to be hello_OBJC_FILES, just like below
include $(GNUSTEP_MAKEFILES)/common.make
TOOL_NAME = hello
hello_OBJC_FILES = hello.m
include $(GNUSTEP_MAKEFILES)/tool.make
Or you can also just compile in command line like this
$ gcc `gnustep-config --objc-flags` hello.m -o hello `gnustep-config --base-libs`
The gnustep-config like pkg-config command can print out the compiling and linking options for gcc.
If I compile this QT c++ program in SuSE Linux
#include <iostream>
using namespace std;
int main ()
{
cout << "Hello World!";
return 0;
}
When I type
i386-mingw32-g++ helloworld.cpp
I get the following error
i386-mingw32-g++: error trying to exec 'cc1plus': execvp: No such file or directory
Is this because MinGW package which i installed contains only gcc in it.. hence i downloaded gcc-g++-3.4.5.rpm package and just copy pasted i386-mingw32-g++ and cc1plus executable along with C++ include files.
Pls reply.
Thanking You
Ugh. The cc1plus in gcc-g++-3.4.5.rpm is not for mingw32. You need the one for your distro.
e.g. for Fedora 10, use http://sourceforge.net/projects/outmodedbonsai/files/Mingw%20Cross-compiler/mingw-1.10-1.fc10.x86_64.rpm
Quoting from here:
It means that your shell could find
the g++ frontend of the GNU compiler
but that frontend couldn't find
cc1plus, the actual C++ compiler; it
could find cpp, the preprocessor, it
already ran. Go to the directory where
the g++ frontend is stored (type:
"which g++") and look for the file
cc1plus in that same directory or a
sub- directory thereof. If it isn't
there your compiler installation is
broken; if it is there some
configuration of it went berzerk.
Also, have a look at this thread.
suse cross-compile toolchain is here.
http://download.opensuse.org/repositories/CrossToolchain:/mingw/
Hi i am a beginner learning objective c.
i am finding an error "hello.m:1:34: Foundation/Foundation.h: No such file or directory"
i came to know that i need to make a make file
may i know how to make the make file please
No need to create a makefile. If you start MinGW from "All Programs -> GNUstep -> Shell" as Pax indicates above, you can just compile your .m file.
My GNUstep installation is in c:\GNUstep\GNUstep\System. If yours is different, you should change the import of Foundation.h accordingly.
I did this:
Create c:\myprogs\obj-c\hello\hello.m that looks like this:
//---------- Hello.m
#import <../../GNUstep/System/Library/Headers/Foundation/Foundation.h>
int main(int argc, const char* argv[])
{
NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
NSLog(#"Hello from Hello.m!");
[pool release];
return 0;
}
//----------
Start MinGW shell. (See above.)
On shell command line, change to directory where program code is located. (Note that, since this is not Unix, the Windows drive letter must be included.):
cd /c/myprogs/obj-c/hello
Compile the program:
gcc -o hello hello.m -I/c/GNUstep/GNUstep/System/Library/Headers \
-L /c/GNUstep/GNUstep/System/Library/Libraries -lobjc -lgnustep-base \
-fconstant-string-class=NSConstantString
(Note that "\" character allows us to extend command to multiple lines.)
I get the following informational messages when I compile:
Info: resolving ___objc_class_name_NSAutoreleasePool by linking to __imp____objc_class_name_NSAutoreleasePool (auto-import)
Info: resolving ___objc_class_name_NSConstantString by linking to __imp____objc_class_name_NSConstantString (auto-import)
Running resulting hello.exe gives me this:
2009-06-03 14:44:59.483 hello[1240] Hello from Hello.m!
That problem just looks like you haven't instructed gcc on where to find the relevant include files (i.e., the directory in which Foundation/Foundation.h resides).
Are you running gcc from under MinGW or from the command prompt. You should have a "All Programs -> GNUstep -> Shell" on your Start menu which brings up this shell.
A makefile for this should be as simple as:
include $(GNUSTEP_MAKEFILES)/common.make
TOOL_NAME = YourProg
YourProg_OBJC_FILES = source_code.m
include $(GNUSTEP_MAKEFILES)/tool.make
If you will put your source codes into home directory in GNUStep, you don't need to provide relative location of Foundation framework.
Using a makefile such as the one specified by paxdiablo is probably the easiest, because rather than trying to remember an arcane command line each time, you set up the makefile and then call make from the source folder.
However, my experience under Windows suggested that GNUStep and Windows, even with the shell, won't build using that because it can't find all the make files it needs - add an environment variable GNUSTEP_MAKEFILES with a value of /GNUstep/System/Library/Makefiles and restart that shell, and then any errors from it being unable to find the standard makefiles should be history.
(I had tried using full paths to the makefiles, but found that this included the specific makefiles but then failed when trying to include further ones, hence going the easy route and adding an environment variable.)