Summary: | [patch] 'emerge freetype' always fails for version 2.x with missing files '/unix-def.mk' and '/unix-cc.mk' in package! | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | D King <dking> |
Component: | New packages | Assignee: | foser (RETIRED) <foser> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | Eddward |
Priority: | Normal | ||
Version: | 2004.3 | ||
Hardware: | x86 | ||
OS: | Linux | ||
URL: | http://forums.gentoo.org/viewtopic.php?t=280310 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
This patch includes my proposed fix.
The output of my 'emerge -ep world' This patch includes the fixes from the first patch but includes backward compatability with the old one as to not break systems this is not a problem on. However its in sh and I guess thats not what they use?! |
Description
D King
2005-01-16 02:04:55 UTC
Here is my full 'emerge freetype' output: hanah root # emerge freetype Calculating dependencies ...done! >>> emerge (1 of 1) media-libs/freetype-2.1.9-r1 to / >>> md5 src_uri ;-) freetype-2.1.9.tar.bz2 >>> Unpacking source... >>> Unpacking freetype-2.1.9.tar.bz2 to /var/tmp/portage/freetype-2.1.9-r1/work * Applying freetype-2.1.9-fix_bci.patch ... [ ok ] * Using GNU config files from /usr/share/libtool * Updating builds/unix/config.sub [ ok ] * Updating builds/unix/config.guess [ ok ] * Applying uClibc/libtool patches ... >>> Source unpacked. ./builds/unix/configure --host=i686-pc-linux-gnu --prefix=/usr --with-zlib --libdir=/usr/lib configure: WARNING: If you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used. checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking for i686-pc-linux-gnu-gcc... i686-pc-linux-gnu-gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether i686-pc-linux-gnu-gcc accepts -g... yes checking for i686-pc-linux-gnu-gcc option to accept ANSI C... none needed checking how to run the C preprocessor... i686-pc-linux-gnu-gcc -E checking for rm... rm -f checking for rmdir... rmdir checking for a BSD-compatible install... /bin/install -c checking for grep that handles long lines... checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for an ANSI C-conforming const... yes checking for int... yes checking size of int... 4 checking for long... yes checking size of long... 4 checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking whether munmap is declared... yes checking for munmap's first parameter type... void * checking for memcpy... yes checking for memmove... yes checking for gzsetparams in -lz... yes checking zlib.h usability... yes checking zlib.h presence... yes checking for zlib.h... yes checking for a sed that does not truncate output... /bin/sed checking for ld used by i686-pc-linux-gnu-gcc... /usr/i686-pc-linux-gnu/bin/ld checking if the linker (/usr/i686-pc-linux-gnu/bin/ld) is GNU ld... yes checking for /usr/i686-pc-linux-gnu/bin/ld option to reload object files... -r checking for BSD-compatible nm... nm checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for i686-pc-linux-gnu-g++... i686-pc-linux-gnu-g++ checking whether we are using the GNU C++ compiler... yes checking whether i686-pc-linux-gnu-g++ accepts -g... yes checking how to run the C++ preprocessor... i686-pc-linux-gnu-g++ -E checking for i686-pc-linux-gnu-g77... i686-pc-linux-gnu-g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether i686-pc-linux-gnu-g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse nm output from i686-pc-linux-gnu-gcc object... ok checking for objdir... .libs checking for i686-pc-linux-gnu-ar... no checking for ar... ar checking for i686-pc-linux-gnu-ranlib... no checking for ranlib... ranlib checking for i686-pc-linux-gnu-strip... no checking for strip... strip checking if i686-pc-linux-gnu-gcc static flag works... yes checking if i686-pc-linux-gnu-gcc supports -fno-rtti -fno-exceptions... no checking for i686-pc-linux-gnu-gcc option to produce PIC... -fPIC checking if i686-pc-linux-gnu-gcc PIC flag -fPIC works... yes checking if i686-pc-linux-gnu-gcc supports -c -o file.o... yes checking whether the i686-pc-linux-gnu-gcc linker (/usr/i686-pc-linux-gnu/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by i686-pc-linux-gnu-g++... /usr/i686-pc-linux-gnu/bin/ld checking if the linker (/usr/i686-pc-linux-gnu/bin/ld) is GNU ld... yes checking whether the i686-pc-linux-gnu-g++ linker (/usr/i686-pc-linux-gnu/bin/ld) supports shared libraries... yes checking for i686-pc-linux-gnu-g++ option to produce PIC... -fPIC checking if i686-pc-linux-gnu-g++ PIC flag -fPIC works... yes checking if i686-pc-linux-gnu-g++ supports -c -o file.o... yes checking whether the i686-pc-linux-gnu-g++ linker (/usr/i686-pc-linux-gnu/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for i686-pc-linux-gnu-g77 option to produce PIC... -fPIC checking if i686-pc-linux-gnu-g77 PIC flag -fPIC works... yes checking if i686-pc-linux-gnu-g77 supports -c -o file.o... yes checking whether the i686-pc-linux-gnu-g77 linker (/usr/i686-pc-linux-gnu/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes configure: creating ./config.status config.status: creating unix-cc.mk config.status: creating unix-def.mk config.status: creating freetype-config config.status: creating freetype2.pc config.status: creating ftconfig.h FreeType build system -- automatic system detection The following settings are used: platform unix compiler cc configuration directory ./builds/unix configuration rules ./builds/unix/unix.mk If this does not correspond to your system or settings please remove the file `config.mk' from this directory then read the INSTALL file for help. Otherwise, simply type `make' again to build the library, or `make refdoc' to build the API reference (the latter needs python). make: Nothing to be done for `unix'. config.mk:25: /unix-def.mk: No such file or directory config.mk:26: /unix-cc.mk: No such file or directory make: *** No rule to make target `/unix-cc.mk'. Stop. !!! ERROR: media-libs/freetype-2.1.9-r1 failed. !!! Function src_compile, Line 55, Exitcode 2 !!! (no error message) !!! If you need support, post the topmost build error, NOT this status message. this is a dupe of an old bug, look for that one. I did some debugging of the code in config.mk and its missing dependancies. It uses the 'wildcard' command and its not listed as a dependancy like it should. If I could emerge that this just might install. no iirc the problem is it tries to build the wrong target, but i already said there was a similar bug to this one. Then there are 2 problems then. A 'updatedb && locate wildcard' command shows the build system is calling a application named 'wildcard' that is not installed on the system. If I knew what to emerge to get 'wildcard' I could test that further, but I have been searching since I opened this bug and can't find it. wildcard is not a command.. what is your 'make' version ? hanah bin # make --version GNU Make 3.80 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I got the 'wildcard' command from the part of the config.mk file that is failing: have_mk := $(strip $(wildcard $(TOP_DIR)/builds/unix/unix-def.mk)) ifneq ($(have_mk),) include $(TOP_DIR)/builds/unix/unix-def.mk include $(TOP_DIR)/builds/unix/unix-cc.mk else # we are building FT2 not in the src tree include $(OBJ_DIR)/unix-def.mk include $(OBJ_DIR)/unix-cc.mk endif As you can see, 'wildcard' is clearly used as a command before 'strip'. Once again, this is my first time trying to debug a emerge, ut I will help however I can, I can't use my gentoo box until this is fixed and I can emerge stuff. :( It seems to me simply taking out the 2 '/' chars in the above code would fix this ebuild. Let the build system add the extra '/' to the pre-pended path instead. Created attachment 48800 [details, diff]
This patch includes my proposed fix.
This patch should fix the install, if my theory is correct.
This is problem is not common, this is local. Your patch may fix it, but I don't see a good explanation of why it would fix it and what it fixes exactly. It takes out the two slashes that are appended to the path of the 2 files that are being called with the wrong path and instead forces the script to look in the current directory for them. Like I said, This is my first bug report with emerge or gentoo. But I'm willing to do what it takes to fix this, It effectivly blocks anything from being installed and kills the idea of using gentoo for anything useful. I can't even emerge in apache+mysql+php due to it failing to emerge and there are many more packages that fail on this dependancy. If this is local and others are having it, then maybe it has to do with the packages that are installed? A forgotten package for the arch perhaps? The conditional in the above code I posted from the failing file is failing, my patch simply fixes the error gained from the code called by that failure. I would rather find out why its failing myself, but like I said its using commands strangly so I am ignorant. I use 'strip' all the time to strip binaries after development in C/C++ but I have no idea why they are calling it on a confog file for the build system. So if there is one thing I do know it's that I don't know everything. Let me see about getting you a list of everything installed on my system in case it is the missing package idea. I just did a emerge -e world last night so everything is up to date. Created attachment 48912 [details]
The output of my 'emerge -ep world'
This is my emerge -ep world output. I hope that helps.
This system was ment to be used by several different people. So far due to this
bug only my brother has made any use out of it; If you need anything else from
me just ask.
Created attachment 49008 [details, diff]
This patch includes the fixes from the first patch but includes backward compatability with the old one as to not break systems this is not a problem on.
However its in sh and I guess thats not what they use?!
This patch fixes the bug if my theory on it is correct, and it should do so
without breaking backwards compatability with the old build system for systems
that this was not a issue on.
Comment on attachment 49008 [details, diff]
This patch includes the fixes from the first patch but includes backward compatability with the old one as to not break systems this is not a problem on.
However its in sh and I guess thats not what they use?!
nm I didnt test it. Use it as a template to fix the problem.
The last patch I submited would have fixed the bug is whatever you guys are using allows for valid shell scripting in make files. All it does is add an additional check after the first failure to see if the file to be included even exists of not using the path called in the script. If it does not then the files are included from the current directory instead. This should fix the problem, however I have had no contact from anybody about this and it has been a very long time and 3 installs of gentoo so far by 2 different people and this STILL remains a problem. IT IS NOT JUST MY SYSTEM. Please respond. Please Fix this problem. I have submited all needed data to fix this and gotten no responce. Please respond ASAP. http://bugs.gentoo.org/show_bug.cgi?id=18160 One of the comments indicates OBJ_DIR doesn't get set for some reason and thus induces this behaviour. Could you find out if the same thing is happening here & if yes why ? & this is not a blocker.. you are the only soul seeing this for some reason. I'm having the same problem. And, right: OBJ_DIR is not being set on my system. Grepping for "OBJ_DIR" shows, that OBJ_DIR might be set in two places. One is a section in the configure-script that starts with the comment "uh oh - taken from autoconf, they know what they're doing" followed by a jungle of weird sed-regexp-stuff. It finally results in a comparison of "$abs_curr_dir" and "$abs_ft2_dir" which are equal in my case so that "OBJ_DIR=$abs_current_dir" will not be appended to the Makefile. The second place where OBJ_DIR might be set is in unix-def.mk itself, which obviously can't be invoked without OBJ_DIR being set. There seems to be another way of using $(BUILD_DIR)/unix-def.mk instead of $(OBJ_DIR)/unix-def.mk but my BUILD_DIR is ./builds/unix and does contain neither unix-def.mk nor unix-cc.mk. Don't know if this is any help to you. I'm not too familiar with automake/autoconf/Makefile-stuff. But I'll keep on trying to figure out how all the scripts and sub-scripts and sub-sub-scripts are supposed to work together... > & this is not a blocker.. Yes it is. Nothing on my system would build. > you are the only soul seeing this for some reason. No he is not. I found I had a 'Makefile' in / , after removing that Freetype built fine. I was trying to avoid adding a mere "me too", but, um. Me too. I'm not completely hosed because my system was already up, but I can't get freetype to upgrade. I'm still trying to figure out what in #18269 was the work-around. Just a follow up. Renaming the /Makefile directory worked for me. this is not a blocker, because except a few individuals noone is having it. Plus that so far pretty much everyone had the same _local_ problem of a Makefile in the root. What's the deal with that ? No ebuild should put that there and if it is done by an ebuild, that should be fixed, not freetype. The only useful comments here are the investigations in $OBJ_DIR , it could possibly be improved to workaround your local problem. But it still would be an odd cornercase. I've had the same problem 2.1.9-r1, moving /Makefile is the solution This may be related with bug #18160 *** This bug has been marked as a duplicate of 18160 *** |