dgilmore changed the topic of #fedora-riscv to: Fedora on RISC-V https://fedoraproject.org/wiki/Architectures/RISC-V || Logs: https://libera.irclog.whitequark.org/fedora-riscv || Alt Arch discussions are welcome in #fedora-alt-arches
fuwei has quit [Quit: Konversation terminated!]
zsun has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
zsun has joined #fedora-riscv
davidlt has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
fuwei has joined #fedora-riscv
zsun has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
zsun has joined #fedora-riscv
U2FsdGVkX1 has joined #fedora-riscv
<fuwei> ping U2FsdGVkX1
zsun has quit [Client Quit]
<fuwei> Please explain the lp64d dir problem with glibc/gcc/meson
<fuwei> rwmjones_: and djdelorie may can help
<U2FsdGVkX1> Client: HexChat 2.16.1 • OS: Microsoft Windows 11 专业版 (x64) • CPU: AMD Ryzen 7 7700X 8-Core Processor (4.50GHz) • Memory: 15.7 GiB Total (3.5 GiB Free) • Storage: 575.9 GiB / 634.9 GiB (59.0 GiB Free) • VGA: Parsec Virtual Display Adapter, Radeon RX 580 Series • Uptime: 7h 27m 29s
<U2FsdGVkX1> sorry, wrong message
<rwmjones_> fuwei: hey
<rwmjones_> so I don't think it is necessarily a problem
<rwmjones_> there's discussion of it on the fedora-devel mailing list last week
<U2FsdGVkX1> now meson has a problem on fedora riscv
<U2FsdGVkX1> with meson find_library function
<rwmjones_> davidlt: ^^
<U2FsdGVkX1> because fedora glibc install to /lib64/lp64d, and it's a softlink to /lib64
<fuwei> rwmjones_: let me check it in mailing list , but what is the conclusion?
<rwmjones_> fuwei: well there was not really any conclusion :-(
<U2FsdGVkX1> when meson searches for libraries, it call gcc to search for libraries
<rwmjones_> U2FsdGVkX1: do you have an example of a build failure / something showing the error messages?
<U2FsdGVkX1> gcc will return "/lib64/lp64d/.../lib64/lp64d/" library directory
<U2FsdGVkX1> Normally it is equivalent to /lib64
<davidlt> morning
<davidlt> Yes, there is a problem with meson (sometimes) where we get a wrong path.
<U2FsdGVkX1> but meson has "optimized" the path
<U2FsdGVkX1> became /lib64/lib64/lp64d
<davidlt> Usually I found that a broken PC file is involved, but something else in meson logic is triggering this.
<davidlt> So the problem is that riscv64 is no FHS compliant. We don't do things like Debian where things are installed based on a triplet.
<davidlt> Thus we have a symlink so that both, /usr/lib64 and /usr/lib64/lp64d, work depending on what software does.
<rwmjones_> U2FsdGVkX1: what's the actual package that fails to build?
<davidlt> But not all software handle symlink lp64d -> . properly
<davidlt> The easiest way here would be to debug meson, and shouldn't be too difficult
* rwmjones_ is watching FOSDEM right now
<U2FsdGVkX1> Here's a snippet of code that reproduces
<davidlt> rwmjones_, example is here: http://fedora.riscv.rocks/koji/taskinfo?taskID=1556545
<davidlt> and you get: ninja: error: '/lib64/lib64/lp64d/libGenericCodeGen.a', needed by 'src/libplacebo.so.338', missing and no known rule to make it
<rwmjones_> right, with U2FsdGVkX1 's example I get
<U2FsdGVkX1> yes, libplacebo also causes this problem due to newer versions using meson
<rwmjones_> ninja: error: '/lib64/lib64/lp64d/libbz2.so', needed by 'main', missing and no known rule to make it
<davidlt> It's on a TODO list debug meson at some point
<rwmjones_> is the problem in /usr/lib64/pkgconfig/bzip2.pc ? or in meson?
<davidlt> most likely meson logic
<davidlt> not handling symlink which points back to the parent directory
<davidlt> but again, in some of these cases I found broken PC files, fixing those fixed the problem
<rwmjones_> fuwei: did you get the email I sent about FAS accounts?
<davidlt> but in general someone needs to debug meson, and look why double /lib64/lib64 happens.
<fuwei> rwmjones_: yes, I just asked them about this info
<rwmjones_> fuwei: ok no rush, I just wanted to check you saw the email
<fuwei> will reply right away
<rwmjones_> no rush :-)
<rwmjones_> I won't be able to do anything about it til next week anyway
<davidlt> U2FsdGVkX1, are you planning on debugging this?
<U2FsdGVkX1> as meson searches for libraries, ".." will be optimized and merged
<U2FsdGVkX1> I've debugged it and think the problem from glibc and gcc
<davidlt> In that case we need more details.
<davidlt> I still think meson logic just doesn't work for us.
<rwmjones_> do you have suggested patches? note this doesn't affect autoconf or pkgconf so seems more likely to be meson-specific
<davidlt> I am not sure what ".." optimized and merged means here.
<davidlt> It is meson specific.
<U2FsdGVkX1> No, it's not meson's problem
<davidlt> We need more details.
<U2FsdGVkX1> when you use "gcc --print-search-dirs", you also get this wrong directory
<rwmjones_> /lib64/lp64d/.../lib64/lp64d/ ?
<davidlt> checking
<U2FsdGVkX1> yes, when meson gets this directory, meson handles it in the above function
<davidlt> I think I might have a ticket on this or similar thing for X years ago
<davidlt> there is also a thing where ld.bfd generates "lib6464"
<rwmjones_> I don't see any problem in the output of 'gcc --print-search-dirs'
<rwmjones_> & I still don't understand the problem in _get_library_dirs either
<U2FsdGVkX1> Let me rephrase that
<U2FsdGVkX1> gcc gets "/lib64/lp64d/../lib64/lp64d" with --print-search-dirs, which is handled in meson by the _get_library_dirs function
<davidlt> So yeah, there is /lib64/lp64d/../lib64/lp64d
<fuwei> rwmjones_: email sent
<U2FsdGVkX1> then calls python os.path.abspath
<davidlt> That resolves (readlink -f) to /usr/lib64
<U2FsdGVkX1> You can do this in python
<U2FsdGVkX1> os.path.abspath("/lib64/lp64d/../lib64/lp64d")
<U2FsdGVkX1> It will return '/lib64/lib64/lp64d'
<davidlt> Does that resolve/canonicalize symlinks?
<rwmjones_> $ realpath /lib64/lp64d/../lib64/lp64d/
<rwmjones_> /usr/lib64
<U2FsdGVkX1> but meson uses python os.path.abspath function
<davidlt> So this should go through readlink 1st
<rwmjones_> >>> os.path.abspath("/lib64/lp64d/../lib64/lp64d")
<rwmjones_> '/lib64/lib64/lp64d'
<rwmjones_> ok so that still sounds like python / meson is broken
<davidlt> Python is probably OK, but meson didn't expect symlinks in the paths
<rwmjones_> I do understand the problem now though, so thanks
<davidlt> So yeah, os.path.realpath() dumps canonicalized path
<davidlt> In that case probably abs is not required too.
<davidlt> Python documentation states:
<davidlt> """This string manipulation may change the meaning of a path that contains symbolic links."""
<davidlt> That's what happening.
<davidlt> abspath changes the path meaning because symbolic link exit.
<davidlt> That's meson bug (most likely).
<davidlt> They have to canonilize (I cannot write this word) 1st.
<U2FsdGVkX1> Yes, that's what I call "optimized"
<rwmjones_> canonicalize :-)
<davidlt> File a meson bug with all the details and CC us. If you have a path before doing that it would be even better :)
<davidlt> patch
<davidlt> Sorry, late Saturday morning :)
<rwmjones_> the path is weird, but it does resolve properly .. so meson ought to be able to handle it
<rwmjones_> yeah that sounds like a plan to me
<davidlt> readlink -f / realpath does the right thing AFAIK, and it works.
<davidlt> meson doesn't incl. a check too, that abspath didn't break anything.
<rwmjones_> U2FsdGVkX1: do you agree, file a bug against meson?
<rwmjones_> fuwei: thanks, got the reply, I'll action that next week
<rwmjones_> fuwei: do you know tingting mao? she's giving a talk right now at fosdem
<rwmjones_> she works at raycom I think
<davidlt> rwmjones_, which talk is this?
<U2FsdGVkX1> I would think this is a problem with glibc&gcc, because directories like /lib64/lp64d/../lib64/lp64d should not be included
<rwmjones_> to watch the livestream you have to do it through element (see chat link)
<davidlt> it's still a valid path
<rwmjones_> U2FsdGVkX1: the path is still valid (I agree it's very weird)
<rwmjones_> so at the end of the day, meson ought to not break it
<rwmjones_> libtool doens't have a problem with it
<davidlt> Surprisingly it only breaks sometimes, most meson using projects build fine.
<rwmjones_> there could be other OSes that use symlinks and meson would be broken on those too
<davidlt> It would be great if we could remove this symlink staff long term, but I am not willing to test it :)
<rwmjones_> agree on that too, but the bigger point some other platform could be using symlinks for a different reason, and meson would be broken there as well, which points to a meson bug
<davidlt> Yeah, meson needs to properly handle it, and Python documentation tells it could break paths if using this function with symlinks.
<rwmjones_> so fixing this in meson will help others
<davidlt> So that's definitely a bug on meson side even if you don't like how paths could look like on Linux :)
<U2FsdGVkX1> ok i will try to solve this problem in meson
<rwmjones_> U2FsdGVkX1: I think filing a bug is the first step, even if you then fix the meson bug
<rwmjones_> can you CC me & davidlt on that too?
<davidlt> os.path.realpath will canonicalize the path
<davidlt> Correct. I think there is enough information with your investigation + the chat to properly describe the issue and get feedback sooner than later.
<rwmjones_> I was just looking to see if the bug is already reported, but I don't see anything
<U2FsdGVkX1> Okay, I will CC on do that
<rwmjones_> that minimal example you gave was great for reproducing it
<rwmjones_> I am @rwmjones on github
<davidlt> @davidlt for me
<U2FsdGVkX1> Roger that :)
<davidlt> I kinda poked around the files, still cannot see where abspath is used
<davidlt> Probably the actual implementation is mesonbuild/compilers/mixins/gnu.py
<davidlt> and _split_fetch_real_dirs talks about thing being fragile somewhat
<davidlt> oh, have to reboot
<davidlt> be back
fuwei has quit [Quit: Konversation terminated!]
davidlt has quit [Remote host closed the connection]
davidlt has joined #fedora-riscv
U2FsdGVkX1 has quit [Remote host closed the connection]
davidlt has quit [Ping timeout: 240 seconds]
zsun has joined #fedora-riscv
davidlt has joined #fedora-riscv
davidlt has quit [Remote host closed the connection]
davidlt has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
fuwei has joined #fedora-riscv
davidlt has quit [Ping timeout: 256 seconds]
fuwei has quit [Ping timeout: 240 seconds]
fuwei has joined #fedora-riscv