I am new to this iPhone. So I installed the GNUstep compiler and I imported one small program. Now I want to compile this and execute the code... I did this by using the code:
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
but it is giving the error as
1./GNUstep/GNUstep/system/library/libraries:permission denied
2.ld.exe : cannot find -lobjc
3.ld.exe : cannot find -lgnustep-base-fconstant-string-class=NSConstantString
collect2:id returned 1 exit status
Please help me anyone.. have I too add any new libraries to this?
Try using this command:
$ gcc `gnustep-config --objc-flags` -o hello hello.m -L C:/GNUstep/GNUstep/Syst
em/Library/Libraries -lobjc -lgnustep-base
You can simple check out my you tube tutorial about that : here
I use GNUstep GORM to make a Objective-C project. The GORM will make a GNUmakefile automatically. If you want to command line style for compile the project, open Shell (you may close the GORM), change to the project directory using cd command, and type make. The GNUstep will compile the project (followed the GNUmakefile). There is a simple project by Yen-Ju Chen at http://www.nongnu.org/gstutorial/en/ch10.html.
Related
I have this strange issue where creating / using a static library works in my Ubuntu VM but not on macOS:
ld: warning: ignoring file ./dist/libXXXX.a, building for macOS-x86_64 but attempting to link with file built for macOS-x86_64
Command to create the static library is:
ar rcs libtest.a obj1.o obj2.o ...
Compiler invocation:
gcc -g -Wall -Wextra main.c -L./dist -lXXXX -o main
Searching on google didn't yield any usable results except for this (maybe) related question on SO:
Possible related question
I realize this is an old post and you found your fix, but let me post this here for anyone else who runs into this problem for whom these answers don't provide a solution.
You might be using two different toolchains unknowingly, one from Apple (installed via Xcode) and one from GNU (installed via Home-brew or MacPorts). If you type ranlib --version and see version info showing that ranlib is GNU, this is likely the case.
Make sure that /usr/bin comes in your $PATH before /usr/local/bin and /opt/local/bin. When you run which -a ranlib, the first result in the list should be /usr/bin/ranlib. Same for which -a ar-- the first result should be /usr/bin/ar. If it is not so, you need to fix your $PATH.
Once you fix your path and clean your project, try building again and things should work.
The issue was solved when I directly put those object files rather than gathering them into a static library, i.e.,
gcc -g -Wall -Wextra main.c obj1.o obj2.o -o main
After that, I got many warnings like ld: warning: object file (obj1.o) was built for newer macOS version (11.0) than being linked (10.14), but it is a warning, and the object is linked, so the problem is solved.
The root cause is that some library passes -mmacosx-version-min=10.14 to gcc, so the object file is built for 10.14, but my macos is now 11.0.
If you want to make things work, try directly using object files rather than creating a static library.
If you want to resolve all the warnings, find ``-mmacosx-version-min` and comment it.
After looking at my script that automatically creates the static library I've found the culprit:
For some reason my tool created object files for header files (resulting in files like header.h.o).
Removing those fixed the issue.
I am trying to build some software for AmigaDOS 3.x on a ubuntu 16.04 host system, but at link time I get this error:
/opt/m68k-amigaos/m68k-amigaos/bin/ld: cannot open crt0.o: No such file or directory
The process of building from .c to .o works fine and with no errors. Its only the link stage that displays any error. The link command I am using is:
sst: $(OFILES)
m68k-amigaos-gcc -o sst $(OFILES) -lm
Any ideas?
The question was answered here:
https://github.com/adtools/amigaos-cross-toolchain/issues/12
I will copy/paste it here, in case the original post on Github became unavailable:
You need to use -noixemul switch during linking stage, otherwise the toolchain will try to use ixemul startup routine which is not available.
$ m68k-amigaos-gcc -noixemul hello.c -o hello
So I have installed / compiled speech_tools, and Festival (2.3) using Cygwin on my Win8.1 machine to the point that I can successfully produce speech using this command:
echo "hello world" | \src\main\festival --tts
The next step is for me to get FestVox running. I have downloaded FestVox 2.6 and I have run ./configure; however, the 'make' step is giving me trouble, producing this error:
gcc -O3 -Wall -o phonealign phonealign_main.o -LC:/cygwin64/Festival/build
/speech_tools/lib -lestools -lestbase -leststring -lncurses -lstdc++ -lm -lwinmm -luser32
/usr/bin/ld: cannot find -leststring
collect2: error: ld returned 1 exit status
Makefile:80: recipe for target 'phonealign' failed
So, I looked at my Makefile at where it might be trying to look for this file, and it looks like in that directory (build\speech_tools\lib) I am missing a libeststring.a partner for my libeststring.lib. Both libestbase and libestools have .lib and .a files in that directory.
At what step did I go wrong?? Should a libeststring.a have been created at some point??? When? How can I fix this?
I think the problem is that you should use compiler in Windows instead of gcc within Cygwin. The role in Cygwin for building Festival is to run configure to generate a Makefile for VC. Then run nmake in Windows command line not make within Cygwin.
Cygwin cannot build a native Windows application like what MINGW does. Application build in Cygwin can only run within Cygwin.
*.a is the static library for Linux, which is built by gcc. *.lib is the static library for Windows, which is built by VC.
So I suggest you taking a look at README, INSTALL files in FestVox. To find whether there is description for make a Makefile for Windows like process "3. Make makefile for VC in Cygwin" in my document (http://www.eguidedog.net/doc_build_win_festival.php)
Cameron
I am new to Pandaboard development. I am using CodeSourcery cross compiler to cross compile my application code. My application is a simple 'hello world' app. I am using this for cross-compilation:
arm-none-linux-gnueabi-gcc app.c -o app.out -march=armv5
I am able to generate the app.out.
But when I copied this app.out to my panda board and tried to execute it, I got this exception:
-bash: ./app.out: No such file or directory
How can I resolve this?
This issue is solved using the static linking of shared libraries.The command to do the same is given below.
arm-none-linux-gnueabi-gcc app.c -o app.out -march=armv5 -static
i tried making library with
ar -r -c -s libtestlib.a *.o
as given in this tutorial http://matrixprogramming.com/Tools/CompileLink.html
But on linking with library following error comes
g++ -o uni2asc uni2asc.o -L../Modules -ltestlib
../Modules/libtestlib.a: could not read symbols: Archive has no index; run ranlib to add one
collect2: ld returned 1 exit status
i tried with ranlib also but still the error comes..
im working with ubuntu9.10
Please suggest me some solution for this
Your archive command looks fine, can you try the following.
1) Get the object files in the archive/static library
ar -t libtestlib.a
2) For each object file (say foo.o) from step 1
file foo.o
This will tell you the format of the object file. If the object file was compiled for a different platform, this would cause a failure to build the index for the archive.
To correct this you would need to recompile these files.
3) For each object file from step 1, do
nm foo.o
This will list the symbols exported from the file.
I was using MinGW to compile a windows app when I got the error, so I found the built-in MinGW commands:
i686-w64-mingw32-ar
And
x86_64-w64-mingw32-ar
Try using those instead of ar if you encounter the problem in MinGW. They both fixed the question's problem for me.
libtool also has an useful option:
-export-symbols-regexp.
I ran into the exact same problem when trying to compile the NBIS libraries. There is an option for
make install LIBNBIS=yes
which creates a single archive containing the other archive files. The gcc linker does not handle this gracefully and just emits the Archive has no index message. The fix is to leave the archives as separate files
make install LIBNBIS=no
Then just link the application to the required archive(s). The archive feed order is important to be sure that the linker identifies the required dependencies, then resolves them as it processes the .a files.