Compiling lang/gcc46 returns //lib/libc.a: cound not read symbols: Bad value

J

jozze

Hello everyone!

I hope I won't turn you away with my long post. Mostly it's explanation of things I already tried. Any suggestions are appreciated.

I have a problem for about 3 weeks now when I try to compile certain ports. Amongst them are lang/gcc46 and java/openjdk6. lang/gcc46 is needed for all Haskell related ports. I already have them installed, but just in case I need to recompile I'd like to have this operational. java/openjdk6 is needed for java/icedtea-web, affects java/opencv-core and quite a lot of ports, if you have Java support enabled. I tried compiling lang/gcc46 without Java, but it still fails, others, like multimedia/libbluray and multimedia/ffmpeg, build without a problem if there is no Java/OpenCV support.

At the time of this writing, I use FreeBSD 9.1-STABLE r251151. However, I tried reverting to RELENG yesterday, but to no avail. Also, pointyhat claims those ports build fine even on STABLE, so it's a problem with my ports.

I removed /usr/ports and initialized a fresh checkout, but the problem persists. I rebuilt my world with clang and gcc-4.2 but still the problems persisted.

My world/kernel is built with clang-3.2. I tried with gcc-4.2 too, but it didn't work.

I also ran # portupgrade -fa ; portupgrade -fa, to really get list of all the ports that have the same problem. It seems that whatever is the cause for those two, is the cause for all further failures. They may have two different causes, but I hope it's a problem, that is common to both of them.

Excerpt from lang/gcc46 build output:
Code: 
...
# @multilib_flags@ is still needed because this may use
# /usr/ports/lang/gcc46/work/build/./gcc/xgcc -B/usr/ports/lang/gcc46/work/build/./gcc/ -B/usr/local/x86_64-portbld-freebsd9.1/bin/ -B/usr/local/x86_64-portbld-freebsd9.1/lib/ -isystem /usr/local/x86_64-portbld-freebsd9.1/include -isystem /usr/local/x86_64-portbld-freebsd9.1/sys-include    and -O2  -g -O2 -pipe -march=corei7 -I/usr/local/include -fno-strict-aliasing -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include   -fPIC -pthread -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector  directly.
# @multilib_dir@ is not really necessary, but sometimes it has
# more uses than just a directory name.
/bin/sh ../.././../gcc-4.6.4/libgcc/../mkinstalldirs .
/usr/ports/lang/gcc46/work/build/./gcc/xgcc -B/usr/ports/lang/gcc46/work/build/./gcc/ -B/usr/local/x86_64-portbld-freebsd9.1/bin/ -B/usr/local/x86_64-portbld-freebsd9.1/lib/ -isystem /usr/local/x86_64-portbld-freebsd9.1/include -isystem /usr/local/x86_64-portbld-freebsd9.1/sys-include    -O2  -g -O2 -pipe -march=corei7 -I/usr/local/include -fno-strict-aliasing -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include   -fPIC -pthread -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector  -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o ./libgcc_s.so.1.tmp -g -O2 -pipe -march=corei7 -I/usr/local/include -fno-strict-aliasing -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o addtf3_s.o divtf3_s.o eqtf2_s.o getf2_s.o letf2_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o floatditf_s.o floatunditf_s.o fixtfti_s.o fixunstfti_s.o floattitf_s.o floatuntitf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o unwind-dw2_s.o unwind-dw2-fde-glibc_s.o unwind-sjlj_s.o gthr-gnat_s.o unwind-c_s.o emutls_s.o libgcc.a -lc && rm -f ./libgcc_s.so && if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 && ln -s libgcc_s.so.1 ./libgcc_s.so
/usr/local/bin/ld: //lib/libc.a(malloc.o): relocation R_X86_64_32S against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
//lib/libc.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
gmake[3]: *** [libgcc_s.so] Error 1
gmake[3]: Leaving directory `/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd9.1/libgcc'
gmake[2]: *** [all-stage1-target-libgcc] Error 2
gmake[2]: Leaving directory `/usr/ports/lang/gcc46/work/build'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/usr/ports/lang/gcc46/work/build'
gmake: *** [all] Error 2
*** [do-build] Error code 1

Stop in /usr/ports/lang/gcc46.
*** [install] Error code 1

Stop in /usr/ports/lang/gcc46.

Excerpt from java/openjdk6 build output:
Code: 
...
gmake \
        SKIP_FASTDEBUG_BUILD=true \
        SKIP_DEBUG_BUILD=true \
         \
        generic_build_repo_series
gmake[1]: Entering directory `/usr/ports/java/openjdk6/work'
/bin/mkdir -p ./build/bsd-amd64
/bin/mkdir -p ./build/bsd-amd64/j2sdk-image
/bin/mkdir -p /usr/ports/java/openjdk6/work/build/bsd-amd64/langtools
(cd  ./langtools/make && \
 gmake JDK_TOPDIR=/usr/ports/java/openjdk6/work/jdk JDK_MAKE_SHARED_DIR=/usr/ports/java/openjdk6/work/jdk/make/common/shared EXTERNALSANITYCONTROL=true TARGET_CLASS_VERSION=5 MILESTONE=fcs BUILD_NUMBER=b27 JDK_BUILD_NUMBER=b27 FULL_VERSION=1.6.0_32-b27 PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.6.0_32 JDK_MKTG_VERSION=6u32 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=6 JDK_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_JDK_UPDATE_VERSION=320 COOKED_BUILD_NUMBER=27 ANT_HOME="/usr/ports/java/openjdk6/work/apache-ant-1.8.4" ALT_OUTPUTDIR=/usr/ports/java/openjdk6/work/build/bsd-amd64/langtools ALT_BOOTDIR=/usr/local/openjdk6 all)
gmake[2]: Entering directory `/usr/ports/java/openjdk6/work/langtools/make'
JAVA_HOME=/usr/local/openjdk6 ANT_OPTS=-Djava.io.tmpdir='/usr/ports/java/openjdk6/work/build/bsd-amd64/langtools/build/ant-tmp' /usr/ports/java/openjdk6/work/apache-ant-1.8.4/bin/ant -Djdk.version=1.6.0_32 -Dfull.version='1.6.0_32-b27'  -Drelease=1.6.0_32 -Dbuild.number=b27 -Djavac.target=5 -Dboot.java.home=/usr/local/openjdk6 -Dbuild.dir=/usr/ports/java/openjdk6/work/build/bsd-amd64/langtools/build -Ddist.dir=/usr/ports/java/openjdk6/work/build/bsd-amd64/langtools/dist build
Buildfile: /usr/ports/java/openjdk6/work/langtools/make/build.xml
gmake[2]: *** [build] Segmentation fault: 11 (core dumped)
gmake[2]: Leaving directory `/usr/ports/java/openjdk6/work/langtools/make'
gmake[1]: *** [langtools-build] Error 2
gmake[1]: Leaving directory `/usr/ports/java/openjdk6/work'
gmake: *** [build_product_image] Error 2
*** [do-build] Error code 1

Stop in /usr/ports/java/openjdk6.
*** [install] Error code 1

Stop in /usr/ports/java/openjdk6.

I tried rebuilding both ports, and world with -fPIC flag enabled, but it didn't help. Also, these errors are there regardless of the compiler I use (graphics/opencv-core is said not to be able to build with clang). Any suggestions would be more than welcome.

Thank you for your time,
Jože
 
Code: 
/usr/local/bin/ld: //lib/libc.a(malloc.o): relocation R_X86_64_32S against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
//lib/libc.a: could not read symbols: Bad value
collect2: ld returned 1 exit status

That means that compiled a shared object without using -fPIC flag. Under ELF platform shared objects are compiled with position independent code (PIC) - code that can run from any location in memory, if this flag is not given, the code that is generated is position dependent, so it is not possible to use this shared object.

According to Options for Code Generation Conventions:
Code: 
[B]-fPIC[/B]
     If supported for the target machine, emit position-independent code, suitable for dynamic 
     linking and avoiding any limit on the size of the global offset table. This option makes a 
     difference on the m68k, PowerPC and SPARC.

     Position-independent code requires special support, and therefore works only on certain machines.

     When this flag is set, the macros __pic__ and __PIC__ are defined to 2.

See http://lists.freebsd.org/pipermail/freebsd-amd64/2005-April/004644.html.
 
Thanks for the reply and suggestions for further reading.

Unfortunately, the very first thing I did when I got this error, was to see what this `-fPIC' flag was about. But the thing is, due to many warnings on this forum, I didn't tamper with CFLAGS or CXXFLAGS, so I don't see what could cause the problem. Afterwards I did set them in the make.conf like

Code: 
CFLAGS+=-fPIC
CXXFLAGS+=-fPIC

but it gave me the same error. Perhaps I should force the port to use the BSD make program (lang/gcc46 is set to use gmake by default), and see what happens.

BTW, thank you for the reading material. I will look into it now ;)
 
I tried it again, with conservative options (I didn't switch to BSD make after all), and with -fPIC added, but it still doesn't build. I ran # portupgrade -Nu --noconfig lang/gcc46 and it didn't work either. I'll rerun it with the additional -Rf flags.

EDIT: Nope, no changes. It seems that one of the objects is linked statically, but I don't know how to change that.
 
I found this explanation about invalid relocations and missing symbols on x86-64.

Quoted from gcc(1)() man page:
Code: 
[B]-shared[/B]
           Produce a shared object which can then be linked with other objects
           to form an executable.  Not all systems support this option.  For
           predictable results, you must also specify the same set of options
           that were used to generate code (-fpic, -fPIC, or model suboptions)
           when you specify this option.[1]

Also you should file a PR on freebsd-amd64 mailing list, if you consider it necessary.
 
Thank you again :) After your suggestion, I also did some searching on this -shared thing. Some people here are suggesting the opposite (although it's not the same problem):

http://stackoverflow.com/questions/...nst-rodata-while-compiling-on-64-bit-platform

http://stackoverflow.com/questions/1147890/relocation-r-x86-64-32-against-a-local-symbol-error

I will try both with, and without -shared support, and see what happens. Right now I have decided to rebuild the world without the 'WITH_BIND_LARGE_FILE' enabled, and without the -j flag.

Fun fact: last updates to lang/gcc46 were two weeks ago, and I did manage to compile it at that time. Same goes for java/openjdk6 although those were 3 weeks ago.
 
Nope, rebuilding world didn't help. I tried -shared -fPIC, --disable-shared, options for -Xlinker, -shared-libgcc, -mno-static, -mno-shared ...

By the way, my files /etc/libmap.conf and /etc/libmap32.conf are empty (I deleted lang/gcc46 compiler some days ago when I noticed this error). If I type # apropos java it suggests gcj46, but if I try to open that manpage, it's non-existing (this probably explains the inability to build java/openjdk6 -- because I need gcj46 to do it).

So far, I didn't file a PR, because this is a local problem, and there have been no reports of others having the same problem, but maybe I'll also ask on a mailing list.
 
If you want to be able to build with PIC or without PIC, add something like this in bsd.port.mk:
Code: 
.ifdef WITH_PIC
CFLAGS+= -fPIC
CXXFLAGS+= -fPIC
.endif

So just add WITH_PIC=yes to the ports that need it.

Please, show your /etc/make.conf and /etc/src.conf files.
 
My /etc/src.conf and my /etc/make.conf.

The flag --disable-shared didn't work -- it didn't pass the config phase, output stated that this compiler (I tried with gcc at the time) cannot produce executable code, and exited with a segmantation fault.

I have to go now, but I'll try again in a few hours.
 
Remove all these from your make.conf:
Code: 
ARCHDEF?=x86_64			# atlas
COPTFLAGS+=-O3

Compile with -shared will fail unless the static libraries (as libc.a) are built with -fPIC. So the solution is to compile the statically linked library with position independent code (PIC).

Run # objdump -r *.o | grep R_X86_64_32S > output.txt to find the object that contains the R_X86_64_32S relocation.
 
cpu82 said:
Remove all these from your make.conf:
Code: 
ARCHDEF?=x86_64			# atlas
COPTFLAGS+=-O3
Click to expand...

I already did that a few days ago, but it doesn't change anything. I tried with commenting out all lines in /etc/src.conf and /etc/make.conf but it didn't affect these particular ports.

@troberts I'll try installing lang/gcc and see what happens. I tried installing higher versions of gcc and they had the same problem. Maybe lower don't ... I will also try reverting lang/gcc46 to one of the previous revisions, and try with those.

Thank you both for your help!
 
Last edited by a moderator:
cpu82 said:
Run # objdump -r *.o | grep R_X86_64_32S to find the object that contains the R_X86_64_32S relocation.
Click to expand...

Oh! Very good idea! I'll do that now! I took the liberty of modifying your command a little bit

Code: 
cd /usr/ports/lang/gcc46/work/build
objdump -r `find . -name "*.o"` | grep R_X86_64_32S

EDIT:
The output is quite large, ([cmd=""]wc -l[/cmd] stated 252481 lines). I put it on pastebin, but I was unable to paste the entire file there. Is there another way with which I can display this entire file for you guys?

@troberts distinfo of lang/gcc states this is gcc-4.6. I tried to compile it anyways, but it gave the same error.

In the meantime, I think sometime ago I may have broken something without realizing it. Maybe there is a symbolic link somewhere that is giving # make installworld a bad time, without it actually saying anything. I was thinking of reinstalling world in a chroot environment to test this statement, and then check for differences. What do you think?
 
Last edited by a moderator:
Please, run % objdump -r *.o | grep R_X86_64_32S > output.txt. To share it you can upload to your github repository.

jozze said:
In the meantime, I think sometime ago I may have broken something without realizing it. Maybe there is a symbolic link somewhere that is giving # make installworld a bad time, without it actually saying anything. I was thinking of reinstalling world in a chroot environment to test this statement, and then check for differences. What do you think?
Click to expand...

Give a try.
 
cpu82 said:
Please, run % objdump -r *.o | grep R_X86_64_32S > output.txt. To share it you can upload to your github repository.
Click to expand...
Oh, right, I forgot about that! Still, I will run objdump with the [cmd=""]find /usr/ports/lang/gcc46/work -name "*.o"[/cmd], because I think objdump expects those files to be in the current working directory.

I made a chroot with
Code: 
# setenv CHROOT /root/chroot
# mkdir -p $CHROOT/etc
# mkdir -p $CHROOT/dev
# mkdir -p $CHROOT/usr/tmp
# chmod 777 $CHROOT/usr/tmp
# cd /usr/src
# make -j16 buildworld
# make installworld DESTDIR=$CHROOT
# make distribution DESTDIR=$CHROOT
# mount -t devfs devfs $CHROOT/dev
# cp /etc/wpa_supplicant.conf $CHROOT/etc
# svn co svn://svn.freebsd.org/ports/head $CHROOT/usr/ports

but I realized I have to rebuild it with pkg_* support, otherwise I cannot install anything. I will try building lang/gcc46 inside there. I will upload the file with R_X86_64_32S to my github repository as soon as I finish with building world.
 
Within my chrooted environment, using my previous /usr/src.conf (I only commented out the line with PKGTOOLS) I can build lang/gcc46 with gcc and with clang + CPUTYPE?=native. It seems my suspicions were proven true. Same goes for java/openjdk6. I used the same compile time flags.

Another thing I noticed, was that there was no file /lib/libc.a in my chrooted environment. There is /usr/lib/libc.a. # file /lib/libc.a also doesn't recognize it as a shared library. Right now I renamed it to /lib/libc.a.bak and am trying to install lang/gcc46.

Any suggestions on how I can find differences between my chrooted environment and my running world?

@cpu82, I uploaded the file on my github repository, but it's quite big, so it's impossible to open it, or view it in its raw form (it has 14 MB).
 
Last edited by a moderator:
As I said before, after I renamed the /lib/libc.a, I tried to install lang/gcc46 again. The compiling process managed to get past that error, but there seemed to be another one:

Code: 
config.status: executing libtool commands
config.status: executing include/gstdint.h commands
config.status: executing generate-headers commands
gmake[2]: Entering directory `/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd9.1/libstdc++-v3/include'
echo timestamp > stamp-pb
echo timestamp > stamp-host
echo 0 > stamp-namespace-version
echo 1 > stamp-visibility
echo 1 > stamp-extern-template
sed -e '/^#pragma/b' \
    -e '/^#/s/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_][ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*\)/_GLIBCXX_\1/g' \
    -e 's/_GLIBCXX_SUPPORTS_WEAK/__GXX_WEAK__/g' \
    -e 's,^#include "\(.*\)",#include <bits/\1>,g' \
    < /usr/ports/lang/gcc46/work/gcc-4.6.4/libstdc++-v3/../gcc/gthr.h > x86_64-portbld-freebsd9.1/bits/gthr.h
sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' \
    < /usr/ports/lang/gcc46/work/gcc-4.6.4/libstdc++-v3/../gcc/gthr-single.h > x86_64-portbld-freebsd9.1/bits/gthr-single.h
sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' \
    -e 's/SUPPORTS_WEAK/__GXX_WEAK__/g' \
    -e 's/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*USE_WEAK\)/_GLIBCXX_\1/g' \
    < /usr/ports/lang/gcc46/work/gcc-4.6.4/libstdc++-v3/../gcc/gthr-posix.h > x86_64-portbld-freebsd9.1/bits/gthr-posix.h
sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' \
    -e 's/SUPPORTS_WEAK/__GXX_WEAK__/g' \
    -e 's/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*USE_WEAK\)/_GLIBCXX_\1/g' \
    < /usr/ports/lang/gcc46/work/gcc-4.6.4/libstdc++-v3/../gcc/gthr-tpf.h > x86_64-portbld-freebsd9.1/bits/gthr-tpf.h
sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' \
    -e 's/SUPPORTS_WEAK/__GXX_WEAK__/g' \
    -e 's/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*USE_WEAK\)/_GLIBCXX_\1/g' \
    -e 's,^#include "\(.*\)",#include <bits/\1>,g' \
    < /usr/ports/lang/gcc46/work/gcc-4.6.4/libstdc++-v3/../gcc/gthr-posix.h > x86_64-portbld-freebsd9.1/bits/gthr-default.h
gmake[2]: Leaving directory `/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd9.1/libstdc++-v3/include'
gmake[1]: Leaving directory `/usr/ports/lang/gcc46/work/build'
gmake: *** [all] Error 2
*** [do-build] Error code 1

Stop in /usr/ports/lang/gcc46.
*** [build] Error code 1

Stop in /usr/ports/lang/gcc46.
 
Ok, check for broken symlinks # find . -type l probably some existing symlink is pointing to a non-existent file. In such case GCC sees the broken link and decides the dynamic version of libc that isn't available and attempts to link with the static one, which fails.
 
OK, I found the problem! After looking around the sea of symlinks, I remembered what went wrong in those past weeks:

Our house lost power, I rebooted the computer and after I started the computer, my computer froze, just as I entered login manager. I booted the LiveCD and ran # fsck -t ufs -fy /dev/ada1p2 which is my / partition. I did the same for the rest of them. I mounted / in /mnt and the rest of my system there too. I tried chrooting there, but my system was saying there was no ld-elf.so, or that it was broken or something (did fsck remove it?). Silly me then just copied stuff from /usr/lib to /lib, with flag not to overwrite existing files, which caused libc.a (and a bunch of other files) to appear in /lib, which shouldn't be there. Sorry for not saying this earlier, I have completely forgotten about it until now, because the system seemed to be working OK.

I made backups of /lib and /libexec and temporarily copied the ones from my chroot there for testing. So far I have been able to build lang/gcc46, I will let you know how it goes with java/openjdk6, but I have a good feeling about it. Just building it failed, so I am rebuilding it now with all dependencies.

Thank you so much!
 
jozze said:
OK, I found the problem! After looking around the sea of symlinks, I remembered what went wrong in those past weeks:

Our house lost power, I rebooted the computer and after I started the computer, my computer froze, just as I entered login manager. I booted the LiveCD and ran # fsck -t ufs -fy /dev/ada1p2 which is my / partition. I did the same for the rest of them. I mounted / in /mnt and the rest of my system there too. I tried chrooting there, but my system was saying there was no ld-elf.so, or that it was broken or something (did fsck remove it?). Silly me then just copied stuff from /usr/lib to /lib, with flag not to overwrite existing files, which caused libc.a (and a bunch of other files) to appear in /lib, which shouldn't be there. Sorry for not saying this earlier, I have completely forgotten about it until now, because the system seemed to be working OK.
Click to expand...

That make sense ;)
Code: 
[CMD]% file /usr/lib/libc.a[/CMD]
/usr/lib/libc.a: current ar archive

As is detailed in hier(7)():
Code: 
/usr/      contains the majority of user utilities and applications
           lib/      shared and archive ar(1)-type libraries
I took a look to your text relocations that is useful to find broken object code and requires time. Already you found which was the problem, the static library libc.a path, so I think I'll leave for another day :e

To compare directories and check if they are the same, run % diff -r /dir1 /dir2
 
OK, I was too fast to say java/openjdk6 builds in my chroot environment. It apparently failed, with both gcc and clang. Failure is the same, as it was in the first entry to this thread.

After some searching I came across this PR, which seems to be unresolved. That is weird, because I did compile it few weeks ago. I used clean config flags to build it, but it still failed.

Since I cannot build it in a completely clean chroot, maybe I have to use the GENERIC kernel, or maybe it is a problem with the current revision of the -STABLE branch.
 
Try compile with DEBUG option enabled and see what goes. If segfault again, you can get a good backtrace to debug.

See core(5)() man page:
Code: 
# mkdir -p /var/coredumps
# chmod 1777 /var/coredumps
# sysctl kern.sugid_coredump=1
# sysctl kern.corefile=/var/coredumps/%U/%N.core
 
This is a good idea.

I checked again in my chroot if it really failed in my chrooted environment. It didn't -- it IS there. Before I checked with # pkg_info openjdk6 and it didn't give me anything, but it is there if I run # pkg_version -v | grep openjdk.

I was able to build it, but I am unable to rebuild it. I didn't change anything in my chroot. Strangely enough, maybe it is meant to be this way ...
 
Passing -Ix options should show it:
Code: 
[CMD]% pkg_info -Ix openjdk6[/CMD]
openjdk6-b27_3      Oracle's Java 6 virtual machine release under the GPL v2
 
cpu82 said:
Passing -Ix options should show it:
Code: 
[CMD]% pkg_info -Ix openjdk6[/CMD]
openjdk6-b27_3      Oracle's Java 6 virtual machine release under the GPL v2
Click to expand...

Oh, thank you! Yes, it does. I have been using PKGNG for a while now, because it has # pkg autoremove option which is safer than pkg_cutleaves, and I have forgotten how to use pkg_* (which I use in my chrooted system), because with PKGNG I can test with just # pkg info openjdk6 to see if the port has been installed or not.
 
You must log in or register to reply here.
Back
Top