I have cross-compiled libpng 1.6.28, libjpeg-turbo 1.5.1 and GLib 2.50.3 for MS Windows with i686-w64-mingw32 on Debian Stretch to a special folder, but still can't get gdk-pixbuf working. My commandline used for configure is:
./configure --host=i686-w64-mingw32 PKG_CONFIG_PATH=/usr/local/mingw32-i686/lib/pkgconfig --prefix=/usr/local/mingw32-i686
It passes the configure part fine, but problems start at making point. It throws the following error:
/usr/local/mingw32-i686/lib/libgio-2.0.a(libgio_2_0_la-giomodule.o): In function `DllMain#12':
/home/maju/GTK-build/glib-2.50.3/gio/giomodule.c:942: multiple definition of `DllMain#12'
./.libs/libgdk_pixbuf-2.0.a(libgdk_pixbuf_2_0_la-gdk-pixbuf-io.o):gdk-pixbuf-io.c:(.text+0x1ca): first defined here
collect2: error: ld returned 1 exit status
Makefile:1859: polecenia dla obiektu 'gdk-pixbuf-csource.exe' nie powiodły się
(last line is just untranslated error message for gdk-pixbuf-csource.exe).
It's also followed by warning messages:
*** Warning: This system cannot link to static lib archive libgdk_pixbuf-2.0.la.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** But as you try to build a module library, libtool will still create
*** a static module, that should work as long as the dlopening application
*** is linked with the -dlopen flag to resolve symbols at runtime.
for every required library.
Can anyone explain it to me?
the DllMain might mean “glib for doze doesn’t build static right”
this patch
https://lists.fedoraproject.org/pipermail/mingw/2013-March/006441.html
still applies for later versions of glib. lame.
updated version of patch https://bugzilla.redhat.com/show_bug.cgi?id=1306047
https://bugzilla.redhat.com/attachment.cgi?id=1122789 is seemingly final version of that patch, see
https://smani.fedorapeople.org/glib-prefer-constructors-over-DllMain.patch
Not sure about the cannot link, I configure glib for cross compile like --host=i686-w64-mingw32 --prefix=/Users/rdp/dev/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-i686/i686-w64-mingw32 --disable-shared --enable-static --with-pcre=internal
FWIW
Related
I'm new to emscripten; several days ago I've downloaded it just to try to make a port of a game to JS.
Anyway, after some steps, I'm having this issue now (on Ubuntu 16.04 STL).
By following build steps here, first of all, I've set environment variables with
source ./emsdk_env.sh and then I've tried to configure the project with emconfigure ./configure in the project directory. When checking for tools emscripten needs, I've got this error:
checking for SDL... no
configure: error: Package requirements (sdl2 >= 2.0.1) were not met:
No package 'sdl2' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables SDL_CFLAGS
and SDL_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
ERROR:root:Configure step failed with non-zero return code 1! Command line: ['./configure'] at ...
So I've tried to set that variable with the following command:
export PKG_CONFIG_PATH=/usr/lib/x86_64-linux-gnu/pkgconfig/
This is where actually sdl2.pc is located on my machine, but it didn't help.
So then I've set the following variables that emconfigure needed:
export SDL_PATH=/home/ustym/Documents/Projects/emsdk/emscripten/1.37.38/system/include/SDL/SDL.h
export SDL_LIBS=/home/ustym/Documents/Projects/emsdk/emscripten/1.37.38/system/include/SDL/SDL.h
export SDL_CFLAGS=/home/ustym/Documents/Projects/emsdk/emscripten/1.37.38/system/include/SDL/SDL.h
export SDLNET_LIBS=/home/ustym/Documents/Projects/emsdk/emscripten/1.37.38/system/include/SDL/SDL.h
export SDLNET_CFLAGS=/home/ustym/Documents/Projects/emsdk/emscripten/1.37.38/system/include/SDL/SDL.h
export SDLMIXER_LIBS=/home/ustym/Documents/Projects/emsdk/emscripten/1.37.38/system/include/SDL/SDL.h
export SDLMIXER_CFLAGS=/home/ustym/Documents/Projects/emsdk/emscripten/1.37.38/system/include/SDL/SDL.h
and relaunched emconfigure ./configure which has completed well.
So the next step is emmake make that gives me the following error:
make all-recursive
make[1]: Entering directory '/home/ustym/Documents/Projects/chocolate-doom-3.0.0'
Making all in textscreen
make[2]: Entering directory '/home/ustym/Documents/Projects/chocolate-doom-3.0.0/textscreen'
Making all in fonts
make[3]: Entering directory '/home/ustym/Documents/Projects/chocolate-doom-3.0.0/textscreen/fonts'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/home/ustym/Documents/Projects/chocolate-doom-3.0.0/textscreen/fonts'
Making all in .
make[3]: Entering directory '/home/ustym/Documents/Projects/chocolate-doom-3.0.0/textscreen'
CC txt_conditional.o
Traceback (most recent call last):
File "/home/ustym/Documents/Projects/emsdk/emscripten/1.37.38/emcc", line 11, in <module>
python_selector.run(__file__)
File "/home/ustym/Documents/Projects/emsdk/emscripten/1.37.38/tools/python_selector.py", line 38, in run
sys.exit(run_by_import(filename, main) if on_allowed_version() else run_by_subprocess(filename))
File "/home/ustym/Documents/Projects/emsdk/emscripten/1.37.38/tools/python_selector.py", line 13, in run_by_import
return getattr(importlib.import_module(os.path.basename(filename)), main)()
File "/home/ustym/Documents/Projects/emsdk/emscripten/1.37.38/emcc.py", line 1345, in run
assert header.endswith(HEADER_ENDINGS), 'if you have one header input, we assume you want to precompile headers, and cannot have source files or other inputs as well: ' + str(headers) + ' : ' + header
AssertionError: if you have one header input, we assume you want to precompile headers, and cannot have source files or other inputs as well: ['/home/ustym/Documents/Projects/emsdk/emscripten/1.37.38/system/include/SDL/SDL.h', 'txt_conditional.c'] : txt_conditional.c
Makefile:447: recipe for target 'txt_conditional.o' failed
make[3]: *** [txt_conditional.o] Error 1
make[3]: Leaving directory '/home/ustym/Documents/Projects/chocolate-doom-3.0.0/textscreen'
Makefile:467: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/home/ustym/Documents/Projects/chocolate-doom-3.0.0/textscreen'
Makefile:585: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/ustym/Documents/Projects/chocolate-doom-3.0.0'
Makefile:438: recipe for target 'all' failed
make: *** [all] Error 2
that means, I assume, that SDL_PATH, SDL_LIBS, SDL_CFLAGS... variables weren't set correctly. Or maybe I just need to precompile that headers in the SDL directory.
One last thing: if I skip setting SDL variables and the configuration step and just launch emmake make, the compilation goes well, but then, emcc command gives me
WARNING:root: .o is not valid LLVM bitcode
for all generated .o files. And that actually makes sense.
So I'm pretty stuck here. Somebody can tell me how to set correctly PKG_CONFIG_PATH for emscripten or if i really need to precompile those headers in the SDL directory? Thanks!
First of all, setting PKG_CONFIG_PATH, include or, even worse, library directories (-I and -L) to host libraries' ones looks like awful idea to me: Emscripten object files contain LLVM bitcode (and not host machine code), its .so files AFAIK contain bitcode as well. It is that bitcode that gets translated to JS, not host machine code. So you need to build your program's dependencies with Emscripten by yourself (and should most probably not install them to the host system). Fortunately, there are some official Emscripten ports (see here) for details.
Emscripten has its own implementation of SDL v1 (that you probably tried to use manually), but your program seems to require SDL2. Good news: you probably just need to pass -s USE_SDL=2 to CFLAGS and LDFLAGS when configureing (see later on the link above for information on SDL2 port). Bad news: something may not be fully ported. But I successfully used it to some extent.
When you have configured on host and make with emmake you probably had compiler paths among other parameters adjusted by emconfigure and emmake already baked into generated Makefile by ./configure not controlled by emconfigure, so host gcc/clang just generated machine code.
I try to execute fakeroot debian/rules binary-headers binary-genericand compile when building kernel but get the error.
Here error in below
arch/x86/built-in.o:(.rodata+0x1cb8): undefined reference to 'sys_monlak'
make[2]: *** [vmlinux] Error 1
make[2]: Leaving directory '/home/su/linux-lts-vivid-3.19.0/debian/build/build-generic'
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory '/home/su/linux-lts-vivid-3.19.0'
make: *** [/home/su/linux-lts-vivid-3.19.0/debian/stamps/stamp-build-generic] Error 2
I tried to build kernel following Build your own kernel and Clarkson.edu
I don't see any reference to the symbol "sys_monlak" inside any branch of the official Linux kernel. Are you using a branch obtained from somewhere else?
This error would happen if a driver depends on a symbol "sys_monlak" which should be defined elsewhere in the kernel but isn't, or perhaps the correct kernel module isn't enabled in the kernel config.
You can try running:
$ grep -R "sys_monlak"
If this produces a c file then you can then try to find the Makefile which should compile in this c file. If, for example, the file was called "arch/x86/monlak.c" you might find the following in the file "arch/x86/Makefile":
obj-$(CONFIG_MONLAK) += monlak.o
In this case you would want to try to enable CONFIG_MONLAK in the kernel config.
The other possibility is that you might want to disable the module that depends on the symbol 'sys_monlak'. Try to carefully read the description in the Kconfig file to see what each module does (the one that depends and the one that provides).
I am faced with the exact same situation as the question raised by Gustavo in the following Link. Also, I have tried all the solutions posted in that link and other tags (such as changing library names from opus.a to libopus.a, change '\' to '/' and so on) but none of these have solved my problem. By opening the properties of the library file, these are the following things displayed:
Path: /demo/opusfile/libopusfile.a
Type: File (Static Library)
Location: U:\data\Jag\eclipse\wrksp\demo\opusfile\libopusfile.a
The error message displayed by Mingw is as follows:
15:56:57 **** Incremental Build of configuration Debug for project demo ****
Info: Internal Builder is used for build
gcc -o demo.exe "src\\demo.o" -lU:/data/Jag/eclipse/wrksp/demo/opusfile/libopusfile.a
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: cannot find -lU:/data/Jag/eclipse/wrksp/demo/opusfile/libopusfile.a
collect2.exe: error: ld returned 1 exit status
collect2.exe: error: ld returned 1 exit status
Could someone please let me know what am I missing ? I am not able to resolve this issue
I think I found the solution, thanks to the answer posted in this Link. So basically to summarize the solution, I had to remove the 'lib' prefix, the '.a' suffix and the library path when I specified the libraries (-l parameters). The library path has to be specified in the -L parameter . This resolved the above problem but led to another hurdle by Mingw:
libopusfile.dll.a: could not read symbols: Archive has no index; run ranlib to add one.
I executed the 'ranlib' command in the command prompt
cmd_path> ranlib libopusfile.dll.a
, as suggested by the compiler, and this solved all my issues!
I am trying to modify the dynamic linker provided in the libc6(2.15-0ubuntu20.2) on a 64 bit Ubuntu machine.
So currently my code is using the same version of the glibc library. (I have downloaded the source code for the same and working on it). My question is that is it possible to modify and build only the linker source code which is present in glibc\elf\ directory without building the entire glibc library.
And if it is possible how can I make my test program to switch using the new version of dynamic linker that I have build myself instead of using the default unmodified linker.
Any pointers or suggestions are highly appreciated.
(If any more information is needed please let me know)
EDIT::
#constantius
I followed the steps in the post linked by you to build ld.so.
But I am getting following error on the make and I checked ld.so is not there in the elf.
The error is::
/var/services/homes/abhi/test/ld/eglibc-build/elf/librtld.os: In function `generic_getcwd':
/var/services/homes/abhi/test/ld/eglibc-2.15/elf/../sysdeps/posix/getcwd.c:356: undefined reference to `__closedir'
/var/services/homes/abhi/test/ld/eglibc-2.15/elf/../sysdeps/posix/getcwd.c:368: undefined reference to `__fdopendir'
/var/services/homes/abhi/test/ld/eglibc-2.15/elf/../sysdeps/posix/getcwd.c:384: undefined reference to `__readdir'
/var/services/homes/abhi/test/ld/eglibc-2.15/elf/../sysdeps/posix/getcwd.c:397: undefined reference to `rewinddir'
/var/services/homes/abhi/test/ld/eglibc-2.15/elf/../sysdeps/posix/getcwd.c:528: undefined reference to `__closedir'
/var/services/homes/abhi/test/ld/eglibc-2.15/elf/../sysdeps/posix/getcwd.c:490: undefined reference to `__closedir'
collect2: error: ld returned 1 exit status
make[2]: *** [/var/services/homes/abhi/test/ld/eglibc-build/elf/ld.so] Error 1
make[2]: Leaving directory `/var/services/homes/abhi/test/ld/eglibc-2.15/elf'
make[1]: *** [elf/subdir_lib] Error 2
make[1]: Leaving directory `/var/services/homes/abhi/test/ld/eglibc-2.15'
make: *** [all] Error 2
NOTE With the same infrastructure I can build and install the full GLIBC so I dont think there is an error with the infrastructure.
-- I guess the error is some where related to editing Makeconfig to all-subdirs = csu elf gmon io misc posix setjmp signal stdlib string time.
--Any suggestions on this..
SOLVED
Need to add dirent in the all-subdirs list in addition to what we edited before
Thanks
Citing this page. In case you don't get something, comment please — I'll try to explain.
Building
To compile Glibc (ld.so cannot be compiled independently) download and unpack Glibc source tarball.
1 Make sure the version of Glibc you downloaded is the same as the system's current one.
2 Make sure the environmental variable LD_RUN_PATH is not set.
3 Read the INSTALL and make sure all necessary tool chains (Make, Binutils, etc) are up-to-date.
4 Make sure the file system you are doing the compilation is case sensitive, or you will see weird errors like
/scratch/elf/librtld.os: In function `process_envvars':
/tmp/glibc-2.x.y/elf/rtld.c:2718: undefined reference to `__open'
...
5 ld.so should be compiled with the optimization flag on (-O2 is the default). Failing to do so will end up with weird errors (see Question 1.23 in FAQ)
6 Suppose Glibc is unpacked at
/tmp/glibc-2.x.y/
Then edit /tmp/glibc-2.x.y/Makefile.in: Un-comment the line
# PARALLELMFLAGS = -j 4
and change 4 to an appropriate number.
7 Since we are only interested in ld.so and not the whole Glibc, we only want to build the essential source files needed by ld.so. To do so, edit /tmp/glibc-2.x.y/Makeconfig: Find the line started with
all-subdirs = csu assert ctype locale intl catgets math setjmp signal \
...
and change it to
all-subdirs = csu elf gmon io misc posix setjmp signal stdlib string time
8 Find a scratch directory, say /scratch. Then
$ cd /scratch
$ /tmp/glibc-2.x.y/configure --prefix=/scratch --disable-profile
$ gmake
Since we are not building the entire Glibc, when the gmake stops (probably with some errors), check if /scratch/elf/ld.so exists or not.
ld.so is a static binary, which means it has its own implementation of standard C routines (e.g. memcpy, strcmp, etc) It has its own printf-like routine called _dl_debug_printf.
Testing
You can run the ld-linux.so directly. It will complain that this is probably not what you want (but you want exactly this) and offer you list of options with which you can run it. See also man ld-linux.so for debugging flags, i.e. there's LD_DEBUG environment variable you can define to see ld-linux.so debugging output.
While I'm not clear on whether the build system for glibc makes doing this easy, there's no fundamental reason why you can't build and use the glibc dynamic linker without building libc.so. I would peruse the top-level Makefile for ways to make this work.
As for testing it, there are two methods:
Explicitly invoke the dynamic linker to run a program, as in:
./ld-linux.so.2 a.out args ...
When linking your program, specify an alternate dynamic linker pathname (which will get stored in its PT_INTERP program header) by passing this option to the compiler driver:
-Wl,-dynamic-linker,/path/to/alternate/ld-linux.so.2
I would like to be able to use talloc in an embedded project I am working on, but have been unable to determine how I go about incorporating it into my development environment. The environment in question is a vendor-supplied Windows IDE that uses ARM GCC 4.4.1, and I am using it to target an ARM7 device.
I have gotten to the stage where the compiler is complaining about conflicting types:
In file included from .\talloc-2.0.8\talloc.c:33:
.\talloc-2.0.8\lib\replace/replace.h:626: error: conflicting types for 'ptrdiff_t'
c:\program files (x86)\cypress\psoc creator\2.2\psoc creator\import\gnu_cs\arm\4.4.1\bin\../lib/gcc/arm-none-eabi/4.4.1/include/stddef.h:149: note: previous declaration of 'ptrdiff_t' was here
.\talloc-2.0.8\lib\replace/replace.h:848: error: conflicting types for 'useconds_t'
c:\program files (x86)\cypress\psoc creator\2.2\psoc creator\import\gnu_cs\arm\4.4.1\bin\../lib/gcc/arm-none-eabi/4.4.1/../../../../arm-none-eabi/include/sys/types.h:253: note: previous declaration of 'useconds_t' was here
.\talloc-2.0.8\talloc.c:123: error: expected specifier-qualifier-list before 'uint8_t'
I noticed that replace.h tries to include a file called config.h that does not exist in the talloc source tree - a problem I got around by creating a blank file by that name. Is the idea to use config.h to inform talloc what functions are already defined by the system? Is this just a matter of using the #define directive to prevent replace.h from trying to replace existing types?
Given that this is the first time I have attempted to use code that I did not write myself in a project, I am somewhat confused as to how to go about reconciling these conflicts.
config.h should be generated automatically. For tmalloc, it's done by waf (python-based build system).
$ python ./buildtools/bin/waf configure
Checking for program gcc or cc : /usr/lib/ccache/gcc
Checking for program cpp : /usr/bin/cpp
Checking for program ar : /usr/bin/ar
Checking for program ranlib : /usr/bin/ranlib
Checking for gcc : ok
Checking for program git : /usr/bin/git
Check for -MD : yes
....
$ python ./buildtools/bin/waf build
.....