For some reason my imagemagick cant process any png files. They all complain with something like the following (can be replicated easily using identify -format %wx%h afile.png ):
identify: memory allocation failed `afile.png' # error/png.c/ReadOnePNGImage/2123.
identify: corrupt image `afile.png' # error/png.c/ReadPNGImage/3668.
Jpegs work fine. But no matter what png file I create on photoshop or download of the net it wont work.
I am using mac os x 10.5 and imagemagick 6.7.1-0 2011-08-01 Q8
CONFIGURE ./configure '--prefix=/usr/local' '--disable-static' '--with-modules' '--without-perl' '--without-magick-plus-plus' '--with-quantum-depth=8' '--disable-openmp' '--with-gs-font-dir=/usr/local/share/ghostscript/fonts' 'LDFLAGS=-L/usr/local/lib' 'CPPFLAGS=-I/usr/local/include'
CONFIGURE_PATH /usr/local/etc/ImageMagick/
COPYRIGHT Copyright (C) 1999-2011 ImageMagick Studio LLC
CPPFLAGS -I/usr/local/include/ImageMagick
CXX g++
CXXFLAGS -g -O2 -D_THREAD_SAFE -pthread
DEFS -DHAVE_CONFIG_H
DELEGATES bzlib freetype jpeg jng lcms2 png tiff x11 xml zlib
DISTCHECK_CONFIG_FLAGS 'CPPFLAGS=-I/usr/local/include' 'LDFLAGS=-L/usr/local/lib' --disable-deprecated --with-umem=no --with-autotrace=no --with-gslib=no --with-fontpath= --with-gs-font-dir=/usr/local/share/ghostscript/fonts --with-perl=no
DOCUMENTATION_PATH /usr/local/share/doc/ImageMagick-6.7.1/
EXEC-PREFIX /usr/local
EXECUTABLE_PATH /usr/local/bin
FEATURES
FILTER_PATH /usr/local/lib/ImageMagick-6.7.1/modules-Q8/filters
HOST i386-apple-darwin9.8.0
LDFLAGS -L/usr/local/lib -L/usr/local/lib -L/usr/X11/lib -R/usr/X11/lib
LIB_VERSION 0x671
LIB_VERSION_NUMBER 6,7,1,0
LIBRARY_PATH /usr/local/lib/ImageMagick-6.7.1
LIBS -lMagickCore -llcms2 -ltiff -lfreetype -ljpeg -lXext -lSM -lICE -lX11 -lXt -lbz2 -lz -lm -lpthread
NAME ImageMagick
I have googled everything but cant seem to get a handle on it. I am able to change settings in Imagemagick but I cant really pass in params to the function calls as I am calling this lib through a ruby on rails third party gem. Has anyone else had this issue?
You need to make sure you have installed the requisite PNG libraries and build ImageMagick with those libraries included.
The best instructions for building ImageMagick for use with rmagick (the Ruby on Rails gem) are at the source - http://rmagick.rubyforge.org/install-linux.html
Some additional notes, run your ./configure command again, or check your configure log, and look for the summary section (it is noted in the document linked above or just search for "ImageMagick is configured as follows". There you will see a list of libraries it is attempting to use and what are found. You should see a line like:
PNG --with-png=yes yes
If it says --with-png=no, or if it has the value "no", then that is your problem. You need to install the png libs. And make sure you install the png-devel libs too, since they are needed for building from source. Now, when you run ./configure, it should discover the png libs and included them in the build.
One last final note, not covered in the document linked above, is that you might need to include --disable-openmp in your ./configure parameters, depending on your hardware. And it looks like you have included it, so you should be good.
Related
I downloaded Codeblocks bundled with GCC from here
The C part is running fine
I read this wiki tutorial which says having GCC will allow me to compile objective C by just adding -lobjc to the compiler options
However, I have followed the steps mentioned in this tutorial and added the -lobjc option, but it doesn't compile
This is the build error message I get in codeblocks:
-------------- Build: Debug in test_prog_proj (compiler: GNU GCC Obj-C Compiler)---------------
mingw32-gcc.exe -Wall -g -c D:\backup\cb_files\objc_files\test_prog_proj\test_prog.m -o obj\Debug\test_prog.o
mingw32-gcc.exe: error: CreateProcess: No such file or directory
Process terminated with status 1 (0 minute(s), 2 second(s))
1 error(s), 0 warning(s) (0 minute(s), 2 second(s))
As shown above, it does not show the -lobjc option
I have also tried manually compiling the above program in Windows cmd by going into the folder containing the .m file. I gave the following command:
mingw32-gcc.exe -Wall -g -c D:\backup\cb_files\objc_files\test_prog_proj\test_prog.m -o obj\Debug\test_prog.o -lobjc
But I get the same error in cmd
mingw32-gcc.exe: error: CreateProcess: No such file or directory
I also tried
gcc -g -fgnu-runtime -O -c some_class.m
that I got from here, but it gives me the same CreateProcess error. How do I start compiling Objective C code in Windows (preferably using GCC and Codeblocks) ?
--- EDIT 1 ---
I did as suggested in Mike Kinghan's answer below, and uninstalled my older Codeblocks instgallation, then reinstalled MinGW and codeblocks separately. The Codeblocks uninstall removed the Codeblocks folder in Program Files, but when I reinstalled Codeblocks again (version without MinGW bundled together), the "GNU GCC Obj-C" settings I made with the previous installation was still there, along with the -lobjc flag in the "linker settings" tab.
However, the problem is that it's still not working. I get the following error if I try to build from Codeblocks
Goto "Settings->Compiler...->Global compiler settings->GNU GCC Obj-C Compiler->Toolchain executables" and fix the compiler's setup.
Tried to run compiler executable 'C:\Program Files\CodeBlocks\MinGW/bin/mingw32-gcc.exe', but failed!
Skipping... Nothing to be done (all items are up-to-date).
This is what Toolchains executable looks like:
If I try to compile it from cmd by going in to the folder with the .m file and issuing the command
mingw32-gcc.exe -Wall -g -c D:\backup\cb_files\objc_files\test_prog_proj\test_prog.m -o obj\Debug\test_prog.o -lobjc
it gives the error
mingw32-gcc.exe: error: CreateProcess: No such file or directory
What is the problem here?
--- EDIT 2 ---
Following the suggestion in Mike Kinghan's answer I deleted the old instance of "GNU GCC Obj-C Compiler" in the list of compiliers, and recreated with the current version of "GNU GCC Compiler"
However, the program still does not work. This is the message I get in the build log:
-------------- Build: Debug in test_prog_proj (compiler: GNU GCC Obj-C Compiler)---------------
Linking stage skipped (build target has no object files to link)
Nothing to be done (all items are up-to-date).
Cleaning the project and then building it again gives the same message. Trying to run the project anyway gives me a dialog box saying the project is not built, and clicking on Yes to build the project just pops the same "project not built yet" dialog box up again. The file icons in the Workspace tree of the Projects tab also seem to be grayed out:
This is what Toolchain Executable looks like:
I have added -lobjc in Linker Settings as mentioned here as well.
I right clicked the project icon in the Project tree, went to Build Options and added -lobjc in the Linker Settings as well:
What is the problem with this project at the moment?
--- EDIT 3 ---
I ended up completely uninstalling Codeblocks (uninstall from windows start menu, delete codeblocks folder in %APPDATA%), uninstalling MinGW (deleting the c:\MinGW folder) and reinstalling everything from scratch. I followed all the instructions in the Wiki (except the Troubleshooting section, but I think that part is irrelevant) and it still doesn't work (same problem as described in Edit 2 in this post).
How do I get Codeblocks to detect and compile obj-C code? Also, it is not showing me the compiler command line arguments when I try to build it from the Codeblocks interface. Why is this and how can I get it to show me whatever the full command line it is using?
The GCC program we loosely call the "the compiler" - [mingw32-](gcc|g++) -
is actually a compiler/linker frontend that invokes a real language
compiler and/or linker depending on what the input files and commandline options
indicate you want it to do.
Input files with an .m extension indicate they are Objective C source files
that are to be compiled with the GNU Objective C compiler, cc1obj. But you
haven't got it. Hence the failure you see.
A GCC installation will include the C compiler cc1 and, optionally, compilers
for other languages - C++, Fortran, Objective (C|C++), Go ... You say you got your MinGW GCC installation as
bundled with Code::Blocks. That bundled MinGW omits the Objective C compiler, cc1obj , because the maintainers
reckon it a niche language.
Best remove your CB installation and bundled MinGW and then install MinGW GCC independently from
one of the rival projects:-
https://sourceforge.net/projects/mingw-w64/
https://sourceforge.net/projects/mingw/
Run the installer and ensure that you get Objective C as well as any other compilers you
want.
After that, replace your CB installation it with the codeblocks-17.12-setup.exe installer (not codeblocks-17.12mingw-setup.exe),
from https://sourceforge.net/projects/codeblocks/files/Binaries/17.12/Windows/. This installer includes no compilers and
will auto-detect your MinGW installation.
Then proceed as you already did to create a GNU GCC Obj-C compiler setup in the CB IDE.
Later ... still not working
Your GNU GCC Obj-C compiler-setup has persisted from your previous
CB install and has been rendered out-of-date by the fact that your
new MinGW installation is no longer part of Code::Blocks. As you see,
it still looks for the toolchain executables in C:\Program Files\Codeblocks\MinGW,
whereas your new MinGW is somewhere else.
When you reinstalled Code::Blocks you should have seen its attempt to auto-detect compilers,
and that it detected your MinGW toolchain in (say) C:\MinGW. It will have configured
a compiler setup for GNU GCC Compiler on that basis, with the correct path to
the toolchain executables. But it will not have modified any persisting compiler setups that
you created yourself, such as GNU GCC Obj-C.
First check that the auto-detected setup GNU GCC Compiler is good just
by creating a "Hello world" C console project and seeing that you can build it.
I assume you'll be able to, but if not, then go into the GNU GCC Compiler setup
yourself and manually set the Compiler's installation directory correctly.
Then, set the same Compiler's installation directory for your GNU GCC Obj-C
compiler setup.
I'm building a dll to use PocoNetSSL to get some data via an HTTPS endpoint. I need to call that dll via C# in Unity which runs an old version of Mono.
I am using mingw-w64 shell to build my dll. There is a package of the Poco libraries available via the package manager pacman and I am using that.
$ pacman -Qs 'poco'
local/mingw-w64-x86_64-poco 1.6.0-2
POrtable COmponents C++ Libraries (mingw-w64)
I can build an executable and it builds fine & runs fine hitting the https endpoint. I have openssl installed somewhere or it may have come with mingw.
My problem is that I cannot open the dll with LoadLibrary. I get a null pointer and I'm guessing it's a dependency problem. Here's my build commands and a snapshot of dependency walker. Is there anything I am missing here. I think I should be able to do this but maybe not?
sburke#sburke-pc MINGW64 ~/sandbox/hitaws
$ scons
scons: Reading SConscript files ...
msys
scons: done reading SConscript files.
scons: Building targets ...
g++ -o gdoaws.os -c -Wall -DPOCO_WIN32_UTF8 -I/mingw64/include gdoaws.cpp
g++ -o gdoaws.dll -Wl,-no-undefined -shared -Wl,--out-implib=libgdoaws.dll.a -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--whole-archive gdoaws.os -Wl,--no-whole-archive -L/mingw64/lib -lPocoNetSSL.dll -lPocoNet.dll -lPocoUtil.dll -lPocoFoundation.dll
scons: done building targets.
Assuming your loading a dynamic library code is correct your app is very likely trying to load different version of openssl dlls than Poco was built against.
In msys2 you can check a dynamic library dependencies by:
ldd /mingw64/bin/libPocoNetSSL.dll
which depends on:
LIBEAY32.dll => /mingw64/bin/LIBEAY32.dll
SSLEAY32.dll => /mingw64/bin/SSLEAY32.dll
Is this what you see in dependency walker?
The best workround for this problem is to copy above dlls to the folder where your executable is and always distribute them with your software.
I'd like to link libpng found by pkg-config statically.
pkg-config --libs --static libpng
outputs
-L/usr/local/Cellar/libpng/1.6.15/lib -lpng16 -lz
I have both libpng16.a libpng16.dylib in that directory, and if I use these flags the library gets linked dynamically.
How can I tell either pkg-config or the linker (preferably in some portable-ish way) that I really want it linked statically?
I've tried adding -static before pkg-config's flags, but that makes clang's ld try and fail to link "crt0.o".
The pkg-config --static option relies on proper tagging in the .pc files. If providing the --static option does not return correct information necessary to link against the libpng archive, then you cannot use pkg-config for that purpose.
I suspect libpng (along with a majority of other packages) dropped support for static linking some time after libpng 1.2. They may still provide a library archive, but the libpng pkg-config file is no longer properly tagged to support a static link. You will have to manually tell ld to use the static lib.
Try:
-L/usr/local/Cellar/libpng/1.6.15/lib -l:libpng16.a -lz
Using -l with a : character allows you to specify the filename extension.
The -l: option is documented in the GNU ld 2.24 manual:
-l namespec
--library=namespec
Add the archive or object file specified by namespec to the list of files to link. This option may be used any number of times. If namespec is of the form :filename, ld will search the library path for a file called filename, otherwise it will search the library path for a file called libnamespec.a.
On systems which support shared libraries, ld may also search for files other than libnamespec.a. Specifically, on ELF and SunOS systems, ld will search a directory for a library called libnamespec.so before searching for one called libnamespec.a. (By convention, a .so extension indicates a shared library.) Note that this behavior does not apply to :filename, which always specifies a file called filename.
You could edit the .pc file to make it support static linking, especially if you are in a position to be compiling, patching, and installing software yourself instead of relying on some Linux distribution.
Here is an example of a .pc file that supports both dynamic and static linking. This is taken from /usr/lib/x86_64-linux-gnu/pkgconfig/xcb.pc on my Ubuntu system:
prefix=/usr
exec_prefix=${prefix}
libdir=${prefix}/lib/x86_64-linux-gnu
includedir=${prefix}/include
xcbproto_version=1.11
Name: XCB
Description: X-protocol C Binding
Version: 1.11.1
Requires.private: pthread-stubs xau >= 0.99.2 xdmcp
Libs: -L${libdir} -lxcb
Libs.private:
Cflags: -I${includedir}
If you run pkg-config --libs xcb, it assumes you want the dynamic version and it gives you just -lxcb. The xcb.so dynamically shared object will know how to load all of its own dependencies so you don't have to specify them when linking against it.
If you run pkg-config --libs xcb --static, then the .private fields come into play, and you get -lxcb -lXau -lXdmcp.
I have not encountered many build systems that know to pass the --static argument to pkg-config. So if your .pc file is only intended to support static linking, it's probably best to not use .private fields, and just provide all the dependencies people will need unconditionally. That way people can link against the library successfully even if they don't know it's static or don't know to pass --static to pkg-config.
Just adding to the post by #David Garyson above I would like to add . If a particular
*.pc file is unavailable with the command
pkg-config --libs
then you might need to add a variable to your PATH
Perhaps you should add the directory containing `nice.pc' to the PKG_CONFIG_PATH environment variable
I use this trick in my Makefile.
LIBRARIES := $(shell pkg-config --libs libpng | sed -E 's/-l([a-z0-9]*)/-l:lib\1.a/g')
It grabs output from pkg config and expands it by prefixing each item with : and the lib, and post-fixing it with an .a. The end result is just what you need
-l:libpng.a -l:libz.a
I've been trying to create a CMake-based build-system for a project that is supposed to use SDL2_image library. I do not want to force user to install any libraries to the system to be able to build the project, so I took advantage of the CMake's ability to download and build dependencies (freetype, SDL2 and SDL2_image) from source code as External Projects.
Everything is fine with freetype and SDL2 (which both include CMakeLists.txt files out of the box), but I've ran out of ideas how to make it work for SDL2_image. CMake's external projects support custom configuration and building settings which I used in different variants with no success.
The CMake file itself can be found here, but the problematic part is this:
# SDL_image library
ExternalProject_Add(sdl2_image_project
URL https://www.libsdl.org/projects/SDL_image/release/SDL2_image-2.0.0.tar.gz
DEPENDS sdl2_project
PREFIX ${LIBS_DIR}/SDL2_image
CONFIGURE_COMMAND LDFLAGS=-L${SDL2_BIN} CFLAGS=-I${SDL2_SRC}/include SDL2_CONFIG=${SDL2_BIN}/sdl2-config <SOURCE_DIR>/configure --prefix=<INSTALL_DIR> --enable-shared=no
BUILD_COMMAND make
INSTALL_COMMAND ""
)
An error occurs while building sdl2_image_project. Some trivial research discovered that the error is generated by the undefined references to parts of libdl. Here is a tiny part of the hole error:
libtool: link: gcc -I/home/snikitin/_src/img_glypher/libs/SDL2/src/sdl2_project/include -I/usr/local/include/SDL2 -D_REENTRANT -o showimage showimage.o -Wl,-rpath -Wl,/usr/local/lib -pthread -L/home/snikitin/_src/img_glypher/libs/SDL2/src/sdl2_project-build ./.libs/libSDL2_image.a -L/usr/local/lib -lSDL2 -pthread
/home/snikitin/_src/img_glypher/libs/SDL2/src/sdl2_project-build/libSDL2.a(SDL_dynapi.c.o): In function `get_sdlapi_entry':
/home/snikitin/_src/img_glypher/libs/SDL2/src/sdl2_project/src/dynapi/SDL_dynapi.c:227: undefined reference to `dlopen'
I think the problem takes place due to the fact that linker tries to create a shared version of SDL2_image library while linking it to a static libSDL2.a. The thing is - if this is right - SDL2 building step creates both static and shared versions of itself so one would assume that linker would use libSDL2-2.0.so instead (I do not actually need a shared library - just the static one, but I do not know how to prevent the build system from trying to create it apart from passing --enable-shared=no to SDL2_image configure script, which does not help in this case).
After a lot of googling I've discovered that the possible source of the problem is that sdl2-config (which is called to get some flags for compiler during SDL_image building) may be called with wrong arguments and produces wrong cflags which confuse everything else. But I'm not sure that is the case and also I do not know how to influence sdl2_config call from CMake (configure --help does not seem to unveil any useful options for this situation).
I am running Ubuntu 14.04 x64 if it matters in any way. Would appreciate any advice!
Looks like you need to link some libraries like m and dl. It can be fixed by providing
custom sdl2-config file. Copy sdl2-config from extracted archive and substitute --libs result:
--libs)
echo -L${exec_prefix}/lib -Wl,-rpath,${libdir} -pthread -lSDL2 -lm -ldl
;;
Note that order is important (that's why just modifying LIBS not works for me).
Now this file can be used in your ExternalProject_Add command instead of SDL2_CONFIG=${SDL2_BIN}/sdl2-config:
...
... CFLAGS=-I${SDL2_SRC}/include SDL2_CONFIG=${CMAKE_CURRENT_LIST_DIR}/sdl2-config <SOURCE_DIR>/configure
...
I compiled GMP with icc and -mmic option, but can't install on MIC. How should I install?
I wrote a demo program, compiled with icc. It says can't find gmp.h.
How should I install GMP library on MIC and where to place gmp.h?
Build GMP with Intel Compiler:
cd /home/
wget https://gmplib.org/download/gmp/gmp-6.0.0.tar.bz2
tar -xf gmp-6.0.0.tar.bz2
rm -f gmp-6.0.0.tar.bz2
cd gmp-6.0.0
mkdir mic
cd mic
../configure CC=icc CFLAGS="-mmic" --host=x86_64 --disable-assembly --prefix /home/gmp-6.0.0/mic/
make
make install
Use the Intel Compiler with environment variables for mic development:
GMP_INCDIR=/home/gmp-6.0.0/mic/include
GMP_LIBDIR=/home/gmp-6.0.0/mic/lib
Though I don't have any expertize on Xeon Phi or even ICC if you are running on Unix-like environment, then you might to try to step through normal configure/make procedure on GMP sources pointing on ICC compiler instead of default GCC in order to build static and/or shared library along with generated gmp.h header, that you can then link with your application. You might want to see GMP documentation on that. Here are some advices, that I stepped to trying to compile it for NVIDIA CUDA:
Supply ./configure with CC and CFLAGS variables to point to desired compiler and its whatever options that you want
Be sure that there is no ABI incompability between your host and Xeon Phi device, especially between 32 and 64 bit architecture.
Consider adding --disable-assembly option to generate "pure-C" build (I am not familiar with Xeon Phi assembly and if/how it is compatibile with x86)
Don't forget to run make check (possibly with -j parameter) after you compiled GMP in order to check if tests are passing, it's very important step if you want use it for some professional purpose.
The library is installed in OS by make install command, for default under /usr/local directory (you might add --prefix option if you want it somewhere else), specifically:
/usr/local/include for gmp.h header file
/usr/local/lib for static and/or shared libgmp binaries
You might also try to compile your application with mini-gmp package, which is contained within GMP sources (it's located under mini-gmp directory). It's a subset of mpz_* and mpn_* routines, not as sophisticated and fast as normal GMP (and it doesn't have as much serious tests coverage), but it could make the job done with small footprint (it's contained in one header and C-source file). For such option be sure to obtain most recent version of GMP (or even get it from their repository).