dslm4515 / CMLFS

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.

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

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.

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

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.

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

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

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

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.

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.

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.

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

I’d say this the curse of ncurses!

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.

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"

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.

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

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

Should migrate to discussion tab. 😄

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.

How could i do this? 🧐

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

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

	# 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]

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

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