extra/alt: llvm-12 fails to compile with netbsd-curses at stage 8 of cgnutools

[takusuman]

I was compiling llvm and then i got this error:

Full text log: https://termbin.com/eibv
As you can see, it's trying to "call"/link to libc.so.6 from the host system, not the toolchain one.
So, just to be sure, i ran ldd both from the toolchain and from the host just to see where exactly libterminfo.so was trying to link:

And yes; apparently, when i built netbsd-curses, it was linked to the wrong libc.

I'm not sure if i will fix this right now -- it's late and i have to study and work tomorrow -- , so take this as a reminder and as an advice.

[dslm4515]

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

[takusuman]

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.

[owl4ce]

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

[takusuman]

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.

[takusuman]

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

[owl4ce]

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; }

[takusuman]

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? 🤷🏽‍♂️ 😕

[takusuman]

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.

[takusuman]

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.

[takusuman]

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.

[dslm4515]

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

I’d say this the curse of ncurses!

[takusuman]

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.

[owl4ce]

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"

[takusuman]

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.

[takusuman]

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

[owl4ce]

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

Should migrate to discussion tab. 😄

[takusuman]

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.

[owl4ce]

How could i do this? 🧐

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

[takusuman]

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. 😃

[dslm4515]

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. 😃

Done!

[takusuman]

Thanks! 🙏🏽

[takusuman]

Well, i don't have a clue of what happened after compiling file that resulted in those weird errors and if it is in fact related to Arch Linux.
May some of you guys could test compiling it over Arch and see if you get the same errors.

For now i'll just try to compile the "vanilla" Musl-LFS. 🤷🏽‍♂️

EDIT: Screw that, i'm trying CMLFS again.
Already remade my .bashrc.

[takusuman]

Now i think i did figured out.
cmake was calling host's C Compiler, not cgnutools' one.
This was workarounded in Musl-LFS with a link from ${CMLFS_TARGET}-gcc to cc if i recall correctly.

"Why it worked in my X distro?" Well, i think it's because Arch filesystem structure sucks in a certain way and cmake tries to search for cc instead of just listening to me and using $CMAKE_C_COMPILER (apparently ?).

[takusuman]

Cool, apparently i fixed this exporting CC, CXX and everything (except for LD, because it was giving me a "symbol not found" error ) in .bashrc explicitly as $CMLFS_TARGET-g{cc,++}.
Let's see if it compiles now-- i think it won't compile anyway. 🤣
Damn, compiling GCC was a lot easier.

[dslm4515]

Damn, compiling GCC was a lot easier.

Crazy, is it not? It's easy to build a small compiler or cross-compiler with GCC. LLVM? too many options to turn off to the point one has to use a script and there is no built-in means to create a simple compiler with out the fancy tools and features. I am tempted to fork LLVM into a simple C++/C compiler... but i'm sure its way over my head.

[owl4ce]

I am tempted to fork LLVM into a simple C++/C compiler... but i'm sure its way over my head.

LLVM is modular, modern, and complete (compiler is not only their purpose), if you want simpler compiler/toolchain just use another compiler. LLVM has really nice features like Clang CFI, faster linker also ThinLTO (lld), etc. Many programming language like rust uses LLVM these days, and most projects attempts converting into LLVM bitcode.

[dslm4515]

That is true. But LLVM is practically the only alternative to GCC. Other compilers I have seen are closed source (like Intel's that is protected by a paywall and only runs on Glibc) or too basic to build a linux system (if ignoring all the GCC-isms and Glibc-isms)... unless I have not found them yet.

Of course, it also a matter of purpose: Would that alternative to GCC exist solely to be an alternative to GCC?

[takusuman]

I think it's just my fault.
I will just build GCC MLFS for now and when i change my host i will try Clang MLFS again.

[dslm4515]

I'm building Optimux for a Chromebook as GalliumOS is very very slow when running off a class 10 micro-SD card. Booted an old CMLFS build on the chromebook and it's very snappy and boots way faster than GalliumOS (may change once I build Wayland+Wayfire).

So i am going to try to use netbsd-curses instead of GNU's ncurses. Is this the correct source URL?
http://ftp.barfooze.de/pub/sabotage/tarballs/netbsd-curses-0.3.2.tar.xz

[dslm4515]

So far built Tools for Optimux with netBSD's curses. But when I build util-Linux in chroot, build fails as more.c uses the function tparm from ncurses. Ncurses defines function with 3 parameters but netBSD defined it with 5. Luckily, there is a compatible function, tiparm that more.c can use. I'll make a patch soon.

[dslm4515]

Follow up: Completed an Optimux build using netBSD's curses. So far first issue is htop will not compile