extra/alt: llvm-12 fails to compile with netbsd-curses at stage 8 of cgnutools about cmlfs HOT 19 CLOSED

Hmm, mine is fine using netbsd-curses .. 🤔

I’d say this the curse of ncurses!

from cmlfs.

Could you share with us the config.mak or you've used that which i wrote at extra/alt/cgnutools_7a-netbsd-curses?

Sure. I only built dynamic libraries and the program binaries.

# Build.
time { make CC="${CMLFS_TARGET}-gcc" all-dynamic; }

# Install.
time { make PREFIX=/cgnutools install-dynamic; }

Nice, i was doing all.
May i edit that later.

from cmlfs.

I'm not sure, but i think i figured out what actually happened.
I didn't unset'd LDFLAGS after 5-GCC-final, so may this is the cause to ncurses being mislinked.

from cmlfs.

Well, in fact, i think i've discovered the real problem here.
When i was compiling LLVM (and ncurses), i was trying to ld it to the host and not to the /cgnutools toolchain.
That was solved (at least i think, i'm compiling LLVM now with @owl4ce's last patch to remove ncurses dependency) using LDFLAGS="-Wl,-rpath,/cgnutools/lib", which was referenced before at the 25th line in 5-GCC-final.

I don't know if it's my host's (Arch Linux with LTS kernel) problem or if the docs are wrong in don't exporting LDFLAGS.

If you guys have any objection to this, just say. I'm closing this issue.

from cmlfs.

How could i do this? monocle_face

Only maintainer can do that, otherwise you can start a new discussion.

Well, may @dslm4515 could do this for us. 😃

from cmlfs.

Ugh. I always have issues with ncurses. Even back then when developing MLFS. For my first experimental build of CMLFS, I mysteriously built cgnutools without ncurses. I could never find out why as every other attempt, I had to build ncurses.

luckily, one can use patchelf to fix/change dependencies in built libraries. A quick and dirty way to force a toolchain to work, but I prefer not.

I admit, I did use different flags for ncurses in Optimux. I can’t remember off the top of my head if it’s was only for the final system in chroot or in one of the tools chains

from cmlfs.

Ugh. I always have issues with ncurses. Even back then when developing MLFS. For my first experimental build of CMLFS, I mysteriously built cgnutools without ncurses. I could never find out why as every other attempt, I had to build ncurses.

Yeah, i understand your pain. I've been experimenting with *MLFS since January and always ncurses was the source of some error in some part of the process.

luckily, one can use patchelf to fix/change dependencies in built libraries. A quick and dirty way to force a toolchain to work, but I prefer not.

I think it's better to just clean the toolchain and recompile it with the correct settings.
For now, i will just be building an experimental toolchain for my hobby-distro, so i'm really not worried about using GNU ncurses instead of netbsd-curses.

I admit, I did use different flags for ncurses in Optimux. I can’t remember off the top of my head if it’s was only for the final system in chroot or in one of the tools chains

Don't worry about that for now. :^)
May some people can solve this problem with netbsd-curses, so let's keep this issue open.

from cmlfs.

Hmm, mine is fine using netbsd-curses .. 🤔

from cmlfs.

Hmm, mine is fine using netbsd-curses .. thinking

Could you share with us the config.mak or you've used that which i wrote at extra/alt/cgnutools_7a-netbsd-curses?

What are your CFLAGS too? I don't remember exactly what i was using but it wasn't not that could harm the process in fact, i think.

from cmlfs.

BTW, removed netbsd-curses and built GNU ncurses on its place; trying to compile clang right now.

from cmlfs.

Could you share with us the config.mak or you've used that which i wrote at extra/alt/cgnutools_7a-netbsd-curses?

Sure. I only built dynamic libraries and the program binaries.

# Build.
time { make CC="${CMLFS_TARGET}-gcc" all-dynamic; }

# Install.
time { make PREFIX=/cgnutools install-dynamic; }

from cmlfs.

BTW, removed netbsd-curses and built GNU ncurses on its place; trying to compile clang right now.

And got the same error when linking to libterminfo.so.

May i will need to rebuild all my toolchain? 🤷🏽‍♂️ 😕

from cmlfs.

Well, may the problem is just mine.
I will try to rebuild the entire toolchain, if i got any progress i will update this issue.

PS: May it was because ncurses was being compiled with the host GCC and not the toolchain one.
Why? I don't know, i've setted CC=${CMLFS_TARGET}-gcc, it shouldn't being using host's GCC.

PS²: Besides that, i also figured out that i may have messed up with musl libc when fixing that link.

from cmlfs.

When i was compiling LLVM (and ncurses), i was trying to ld it to the host and not to the /cgnutools toolchain.

@takusuman

So strange, the GCC in the cgnutools should invoke the linker to links againts /cgnutools/lib/ld-musl-x86_64.so.1.

Also .. in my builds, I don't use these stuffs. The last, I only use make command.

from cmlfs.

When i was compiling LLVM (and ncurses), i was trying to ld it to the host and not to the /cgnutools toolchain.

@takusuman

So strange, the GCC in the cgnutools should invoke the linker to links againts /cgnutools/lib/ld-musl-x86_64.so.1.

CMLFS/1-cgnutools/5-GCC-final

Lines 53 to 70 in 1b8e2d7

	# Now adjust GCC to produce programs and libraries that will use musl libc in /cgnutools...
	export SPECFILE=`dirname $(${CMLFS_TARGET}-gcc -print-libgcc-file-name)`/specs
	${CMLFS_TARGET}-gcc -dumpspecs > specs
	sed -i 's/\/lib\/ld-musl-x86_64.so.1/\/cgnutools\/lib\/ld-musl-x86_64.so.1/g' specs
	# Check specs file
	grep "/cgnutools/lib/ld-musl-x86_64.so.1" specs --color=auto
	# Install specs file
	mv -v specs $SPECFILE
	unset SPECFILE
	# Check if GCC compiles as intended:
	echo "int main(){}" > dummy.c
	${CMLFS_TARGET}-gcc dummy.c
	readelf -l a.out | grep Requesting
	# Should output:
	# [Requesting program interpreter: /cgnutools/lib/ld-musl-x86_64.so.1]

Also .. in my builds, I don't use these stuffs. The last, I only use make command.

CMLFS/1-cgnutools/5-GCC-final

Line 25 in 1b8e2d7

AR=ar LDFLAGS="-Wl,-rpath,/cgnutools/lib" \

CMLFS/1-cgnutools/5-GCC-final

Lines 47 to 48 in 1b8e2d7

	make AS_FOR_TARGET="${CMLFS_TARGET}-as" \
	LD_FOR_TARGET="${CMLFS_TARGET}-ld"

Well, and it was, at least the dummy.c that i compiled at this step was linked to cgnutools' libc; but for some reason, after file, it was trying to link to host's libc.
That's weird, really weird-- for some reason, compiling things on Arch always leads to weird and interesting errors.
Well, let's see if LLVM will work anyway.

from cmlfs.

Btw, i'll reopen as this can be a really interesting discussion.

from cmlfs.

Btw, i'll reopen as this can be a really interesting discussion.

Should migrate to discussion tab. 😄

from cmlfs.

Btw, i'll reopen as this can be a really interesting discussion.

Should migrate to discussion tab. smile

How could i do this? 🧐
Although using GitHub since 2019, i still don't know how to use some features.

from cmlfs.

How could i do this? 🧐

Only maintainer can do that, otherwise you can start a new discussion.

from cmlfs.