Dave Gomboc | 10 Sep 03:24 2014
Picon

problem report for 3.0.0 beta 1 PowerPC SysVInit instructions

Hello,

ISL configure fails with a message indicating that it could not
find the symbol "main" within gmp.  Indeed, there is no such
symbol within the file at /cross-tools/lib/libgmp.so.10.2.0
(according to "nm -C /cross-tools/lib/libgmp.so.10.2.0 | grep
main").  Plenty of other symbols are present, though.

tar xf ${CLFS_SOURCES}/isl-0.12.2.tar.lzma
cd isl-0.12.2/
LDFLAGS="-Wl,-rpath,/cross-tools/lib" ./configure
--prefix=/cross-tools --disable-static --with-gmp-prefix=/cross-tools
make
make install
cd ..
rm -rf isl-0.12.2/

A relevant excerpt from config.log is below.

What is the adjustment to the instructions that you recommend?

Thanks,
Dave Gomboc

configure:17242: checking which gmp to use
configure:17244: result: system
configure:17266: checking gmp.h usability
configure:17266: gcc -c -O3 -fomit-frame-pointer -malign-double
-fstrict-aliasing -ffast-math -I/cross-tools/include  conftest.c >&5
configure:17266: $? = 0
(Continue reading)

Running the 'final' gcc

Hi,

I am running the final gcc, not the native gcc from chapter 10. I have changed some of the directory names to match how our stuff is built.

IE lib->lib32 etc.using –libdir arguments. This is using the V3.0 book.

 

In our build, the check for a working gcc shows in the config.log that it is failing because ld can’t find crt1.o or crti.o.

What I see is that crti.o and crt1.o are in /tools/libxx while the other crtxxx.o are in the gcc/4.8.3/ directory in /cross-tools where the linker is looking for them. Using strace I can see that gcc/collect2/ld is looking in /cross-tools and not at all in any /tools directory.

I am trying to find out if my changes to the config lines is causing these files to be put in the wrong place or the SEARCH_DIR that ld is using is wrong.

I can provide the changes to the config lines if that makes a difference

Thanks

.

-Barry

 

CONFIDENTIALITY NOTICE: The information contained in this email message is intended only for use of the intended recipient. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately delete it from your system and notify the sender by replying to this email.  Thank you.

_______________________________________________
Clfs-support mailing list
Clfs-support <at> lists.cross-lfs.org
http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org

LDD shows local dependencies

Hi,

I am building CLFS for x86-unknown using the first few chapters of the V3.0 book from GIT. I was told this is stable enough now to use. Can’t get v2.1 to work correctly

What I am confused by is that when we try to run the GCC cross-compiler on a different host system than the one it was built on it fails. It tries to load the wrong (local) glibc from the /lib64 directory.

LDD on the x86_64-unk…..-gcc in the cross-tools/bin directory shows dependencies on local libc.so.6 and is trying to load the wrong version of glibc. I assumed an ldd on the cross gcc should only try to reference libraries installed in /cross-tools. The libc.so only seems to be installed in /tools not /crosstools and LD_PATH is not loading that one (LD_PATH is empty).

There is a gcc-4.8.3 but it doesn’t seem to be used by the cross-tools when I try to build things using it.

Any ideas?

Thanks

-Barry

 

CONFIDENTIALITY NOTICE: The information contained in this email message is intended only for use of the intended recipient. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately delete it from your system and notify the sender by replying to this email.  Thank you.

_______________________________________________
Clfs-support mailing list
Clfs-support <at> lists.cross-lfs.org
http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org

LDD shows local dependenciesw

Hi,

I am building CLFS for x86-unknown using the first few chapters of the V3.0 book from GIT. I was told this is stable enough now to use. Can’t get v2.1 to work correctly

What I am confused by is that when we try to run the GCC cross-compiler on a different host system than the one it was built on it fails. It tries to load the wrong (local) glibc from the /lib64 directory.

LDD on the x86_64-unk…..-gcc in the cross-tools/bin directory shows dependencies on local libc.so.6 and is trying to load the wrong version of glibc. I assumed an ldd on the cross gcc should only try to reference libraries installed in /cross-tools. The libc.so only seems to be installed in /tools not /crosstools and LD_PATH is not loading that one (LD_PATH is empty).

There is a gcc-4.8.3 but it doesn’t seem to be used by the cross-tools when I try to build things using it.

Any ideas?

Thanks

-Barry

 

 

CONFIDENTIALITY NOTICE: The information contained in this email message is intended only for use of the intended recipient. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately delete it from your system and notify the sender by replying to this email.  Thank you.

_______________________________________________
Clfs-support mailing list
Clfs-support <at> lists.cross-lfs.org
http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org
nagudaku | 7 Jun 20:58 2014
Picon

problem compiling glibc-2.19 on cygwin

i'm getting an error when cross-compiling glibc-2.19 with host=cygwin and target=x86_64-unknown-linux-gnu
i've followed the instructions in CLFS  GIT-20140604-x86_64-Pure64

error message during 'make' is as below:

...snip...

make  subdir=resolv -C resolv ..=../ others
make[2]: Entering directory '/mnt/clfs/sources/work/glibc-2.19/resolv'
make[2]: Nothing to be done for 'others'.
make[2]: Leaving directory '/mnt/clfs/sources/work/glibc-2.19/resolv'
make  subdir=nss -C nss ..=../ others
make  subdir=hesiod -C hesiod ..=../ others
make[2]: Entering directory '/mnt/clfs/sources/work/glibc-2.19/hesiod'
make[2]: Nothing to be done for 'others'.
make[2]: Leaving directory '/mnt/clfs/sources/work/glibc-2.19/hesiod'
make  subdir=sunrpc -C sunrpc ..=../ others
make[2]: Entering directory '/mnt/clfs/sources/work/glibc-2.19/sunrpc'
x86_64-unknown-linux-gnu-gcc -m64 rpc_main.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wstrict-prototypes        -D_RPC_THREAD_SAFE_ -I../include -I/mnt/clfs/sources/work/glibc-build/sunrpc  -I/mnt/clfs/sources/work/glibc-build  -I../sysdeps/unix/sysv/linux/x86_64/64/nptl  -I../sysdeps/unix/sysv/linux/x86_64/64  -I../nptl/sysdeps/unix/sysv/linux/x86_64  -I../nptl/sysdeps/unix/sysv/linux/x86  -I../sysdeps/unix/sysv/linux/x86  -I../sysdeps/unix/sysv/linux/x86_64  -I../sysdeps/unix/sysv/linux/wordsize-64  -I../nptl/sysdeps/unix/sysv/linux  -I../nptl/sysdeps/pthread  -I../sysdeps/pthread  -I../ports/sysdeps/unix/sysv/linux  -I../sysdeps/unix/sysv/linux  -I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../nptl/sysdeps/unix/sysv  -I../ports/sysdeps/unix/sysv  -I../sysdeps/unix/sysv  -I../sysdeps/unix/x86_64  -I../nptl/sysdeps/unix  -I../ports/sysdeps/unix  -I../sysdeps/unix  -I../sysdeps/posix  -I../nptl/sysdeps/x86_64/64  -I../sysdeps/x86_64/64  -I../sysdeps/x86_64/fpu/multiarch  -I../sysdeps/x86_64/fpu  -I../sysdeps/x86/fpu  -I../sysdeps/x86_64/multiarch  -I../nptl/sysdeps/x86_64  -I../sysdeps/x86_64  -I../sysdeps/x86  -I../sysdeps/ieee754/ldbl-96  -I../sysdeps/ieee754/dbl-64/wordsize-64  -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754/flt-32  -I../sysdeps/wordsize-64  -I../sysdeps/ieee754  -I../sysdeps/generic  -I../nptl  -I../ports  -I.. -I../libio -I. -nostdinc -isystem /mnt/clfs/cross-tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.3/include -isystem /mnt/clfs/cross-tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.3/include-fixed -isystem /tools/include  -D_LIBC_REENTRANT -include ../include/libc-symbols.h   -DNOT_IN_libc=1    -D_RPC_THREAD_SAFE_ -o /mnt/clfs/sources/work/glibc-build/sunrpc/rpc_main.o -MD -MP -MF /mnt/clfs/sources/work/glibc-build/sunrpc/rpc_main.o.dt -MT /mnt/clfs/sources/work/glibc-build/sunrpc/rpc_main.o
gcc   -D_RPC_THREAD_SAFE_ -D_GNU_SOURCE -DIS_IN_build -include /mnt/clfs/sources/work/glibc-build/config.h rpc_main.c \
        -o /mnt/clfs/sources/work/glibc-build/sunrpc/cross-rpc_main.o -MMD -MP -MF /mnt/clfs/sources/work/glibc-build/sunrpc/cross-rpc_main.o.dt -MT /mnt/clfs/sources/work/glibc-build/sunrpc/cross-rpc_main.o -c
rpc_main.c: In function 'find_cpp':
rpc_main.c:329:17: error: storage size of 'buf' isn't known
   struct stat64 buf;
                 ^
rpc_main.c: In function 'checkfiles':
rpc_main.c:1117:17: error: storage size of 'buf' isn't known
   struct stat64 buf;
                 ^
Makefile:165: recipe for target '/mnt/clfs/sources/work/glibc-build/sunrpc/cross-rpc_main.o' failed
make[2]: *** [/mnt/clfs/sources/work/glibc-build/sunrpc/cross-rpc_main.o] Error 1
make[2]: Leaving directory '/mnt/clfs/sources/work/glibc-2.19/sunrpc'
Makefile:213: recipe for target 'sunrpc/others' failed
make[1]: *** [sunrpc/others] Error 2
make[1]: Leaving directory '/mnt/clfs/sources/work/glibc-2.19'
Makefile:9: recipe for target 'all' failed
make: *** [all] Error 2


please suggest any steps to correct this error


~nagu.
_______________________________________________
Clfs-support mailing list
Clfs-support <at> lists.cross-lfs.org
http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org
William Harrington | 31 May 04:42 2014

Package Freeze and Future Release plan

Greetings,

CLFS 3.0 is coming along well.

Chris and I feel a package freeze would be good, very soon.

Does anyone know of any upcoming releases that may be major that we  
would want to wait for?

I can't think of anything we'd want to wait for, at the moment.

We may want to do a release candidate for the 3.0.0 BOOK. This will  
provide valuable input and testing.

Do we still have followers? The lists haven't been busy in a while.

Sincerely,

William Harrington
Andrei Tudor | 28 May 19:19 2014
Picon

Flex error -- requires texlive


Hello,

I am installing clfs using the Cross-Compiled Linux From Scratch - Version
GIT-20140525-x86_64-Multilib 

I am at chapter 10.23. Flex-2.5.39 32 Bit Libraries 

I chrooted into the system and compiled and installed all packages up to this one.

The output of the make command for 32 bit compilation:
------------------------------------------------------------------------------------
make[2]: Leaving directory '/sources/flex-2.5.39'
Making all in doc
make[2]: Entering directory '/sources/flex-2.5.39/doc'
TEXINPUTS=".:$TEXINPUTS" \
MAKEINFO='/bin/sh /sources/flex-2.5.39/missing --run makeinfo   -I .' \
texi2dvi --pdf --batch flex.texi
You don't have a working TeX binary (tex) installed anywhere in
your PATH, and texi2dvi cannot proceed without one.  If you want to use
this script, you'll need to install TeX (if you don't have it) or change
your PATH or TEX environment variable (if you do).  See the --help
output for more details.

For information about obtaining TeX, please see http://tug.org/texlive,
or do a web search for TeX and your operating system or distro.
Makefile:364: recipe for target 'flex.pdf' failed
make[2]: *** [flex.pdf] Error 1
make[2]: Leaving directory '/sources/flex-2.5.39/doc'
Makefile:796: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/sources/flex-2.5.39'
Makefile:523: recipe for target 'all' failed
make: *** [all] Error 2
----------------------------------------------------------------------------------------

What I understand is that it needs tex to compile the documentation. I haven't installed texlive on it, but I
have it on the host linux (by the way it is ArchLinux with the kernel: 3.14.4-1-ARCH). 

I hope I provided all the information necessary. I don't know how to fix this error. The same result with the
64 bit flex. I have searched on google, but I don't see other people having this problem.

Any help is appreciated,
Andrei 
William Harrington | 16 May 02:01 2014

Sysvinit Branch BOok

Greetings,

the Systemd book and Sysvinit books are pretty much neck and neck with  
much needed changes which never had made it to the master book for a  
long time.

It will be much easier to maintain both in their current state.  Most  
of the editing we did has made it into the sysvinit book with the help  
of Chris Staub.

Let the testing begin!

By the way, has anyone been successful in using qemu for sparc64 or  
ppc64? I can't find any good combinations of images or command line  
options for qemu to test those books.

Jonathan Norman got a replacement board for his dual G5, but not sure  
on the status of the repair.

Sincerely,

William Harrington
William Harrington | 15 May 04:08 2014

CLFS Systemd and Sysvinit Books

Greetings,

Chris and I have updated the site.

Our system will render the systemd and sysvinit books as changes occur  
in git.

Trac download and read online sections have been updated.

Please report any broken links or any other issues which affect  
viewing the book or downloads and broken links.

Note that for git, the master branch is now the systemd book and the  
sysvinit book is in the sysvinit branch.

Also, the sysvinit book is the 2.x dev book and the systemd book is  
the 3.x dev book as for now.

Sincerely,

William Harrington
Gary Greene | 10 May 09:42 2014
Picon

Having issues building GLIBC 32bit

I’m currently working through building a version of CLFS from the 2.x development book (x86_64,
multilib). I’ve gotten through building GCC 4.8.2 static from chapter 5, and am working on getting
GLibC 2.19 32-bit built.

Unfortunately, I cannot get it to build. Originally, I was having an issue getting it to find errno.h when
building the stuff in sunrpc. After doing some digging, I found this was due to libtirpc 32bit being
installed on the host system. After removing that library and it’s headers from the system, I run into
the following odd error when the system looks to be linking libresolv: 

x86_64-altimatos-linux-gnu-gcc -m32 -shared -static-libgcc -Wl,-O1  -Wl,-z,refs
 -Wl,-dynamic-linker=/tools/lib/ld-linux.so.2
 -B/home/builder/sources/glibc-build-32/csu/
 -Wl,--version-script=/home/builder/sources/glibc-build-32/libresolv.map
 -Wl,-soname=libresolv.so.2 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both
  -L/home/builder/sources/glibc-build-32
  -L/home/builder/sources/glibc-build-32/math
  -L/home/builder/sources/glibc-build-32/elf
  -L/home/builder/sources/glibc-build-32/dlfcn
  -L/home/builder/sources/glibc-build-32/nss
  -L/home/builder/sources/glibc-build-32/nis
  -L/home/builder/sources/glibc-build-32/rt
  -L/home/builder/sources/glibc-build-32/resolv
  -L/home/builder/sources/glibc-build-32/crypt
  -L/home/builder/sources/glibc-build-32/nptl

-Wl,-rpath-link=/home/builder/sources/glibc-build-32:/home/builder/sources/glibc-build-32/math:/home/builder/sources/glibc-build-32/elf:/home/builder/sources/glibc-build-32/dlfcn:/home/builder/sources/glibc-build-32/nss:/home/builder/sources/glibc-build-32/nis:/home/builder/sources/glibc-build-32/rt:/home/builder/sources/glibc-build-32/resolv:/home/builder/sources/glibc-build-32/crypt:/home/builder/sources/glibc-build-32/nptl 
 -o /home/builder/sources/glibc-build-32/resolv/libresolv.so
 -T /home/builder/sources/glibc-build-32/shlib.lds /home/builder/sources/glibc-build-32/csu/abi-note.o
 -Wl,--whole-archive /home/builder/sources/glibc-build-32/resolv/libresolv_pic.a
 -Wl,--no-whole-archive /home/builder/sources/glibc-build-32/elf/interp.os
 -Wl,--start-group /home/builder/sources/glibc-build-32/libc.so /home/builder/sources/glibc-build-32/libc_nonshared.a
 -Wl,--as-needed /home/builder/sources/glibc-build-32/elf/ld.so
 -Wl,--no-as-needed
 -Wl,--end-group
/home/builder/sources/glibc-build-32/resolv/libresolv_pic.a(ns_print.os): In function `__GI_ns_sprintrrf':
ns_print.c:(.text+0x48f): undefined reference to `__stack_chk_guard'
ns_print.c:(.text+0x5b8): undefined reference to `__stack_chk_guard'
/home/builder/sources/glibc-build-32/resolv/libresolv_pic.a(gethnamaddr.os): In function `getanswer':
gethnamaddr.c:(.text+0x766): undefined reference to `__stack_chk_guard'
gethnamaddr.c:(.text+0x7a5): undefined reference to `__stack_chk_guard'
/home/builder/sources/glibc-build-32/resolv/libresolv_pic.a(gethnamaddr.os): In function `__GI_res_gethostbyname2':
gethnamaddr.c:(.text+0x109c): undefined reference to
`__stack_chk_guard'
/home/builder/sources/glibc-build-32/resolv/libresolv_pic.a(gethnamaddr.os):gethnamaddr.c:(.text+0x127e):
more undefined references to `__stack_chk_guard' follow
collect2: error: ld returned 1 exit status
make[2]: *** [/home/builder/sources/glibc-build-32/resolv/libresolv.so] Error 1
make[2]: Leaving directory `/AltimatOS/sources/glibc-2.19/resolv'
make[1]: *** [resolv/others] Error 2
make[1]: Leaving directory `/AltimatOS/sources/glibc-2.19'
make: *** [all] Error 2

Any assistance on this would be appreciated.

--
Gary L. Greene, Jr.
================================================================================
Volunteer Developer for the AltimatOS and KDE F/OSS projects.
Please refrain from sending me closed office file formats (DOC, XLS, PPT).
================================================================================

_______________________________________________
Clfs-support mailing list
Clfs-support <at> lists.cross-lfs.org
http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org
Koornstra, Reinoud | 7 May 22:34 2014
Picon

your gcc patch

Hi William,

I looked in the patch you wrote for gcc in gcc/config/aarch64/aarch64-linux.h for example

#define GLIBC_DYNAMIC_LINKER "/tools/lib/ld-linux-aarch64.so.1"

You added /tools in front of /lib
Does this only work, because you did:

ln -sv ${CLFS}/tools /

if you didn't make this link you'd have to change this with: 

#define GLIBC_DYNAMIC_LINKER "/mnt/clfs/tools/lib/ld-linux-aarch64.so.1"

Correct?
Thanks,

Reinoud.

Gmane