[Solved]uade-git - Dependency problem

Maniaxx · 2022-02-12 21:15:13

Hallo,
i've compiled uade-git and the main binary works ok. But the Audacious plugin (libuade.so) does not. See the upstream bug report for details. I've changed LDFLAGS (removed '--as-needed') of uade-git PKGBUILD as seen below so the lib links the bencode library but its not accepted then by Audacious. But i'm not sure if that's even correct.

Any idea what's wrong with the compilation of the library?

build() {
  cd ${pkgname%-git}
  LDFLAGS="-Wl,-O1,--sort-common,-z,relro,-z,now"
  ./configure --prefix=/usr
  make
}

Last edited by Maniaxx (2022-02-19 16:45:10)

ayekat · 2022-02-13 16:00:31

If you set `LDFLAGS` like that, it's just a shell variable, not an environment variable that is passed down to child processes. Written like that, neither `configure` nor `make` will see it.

Either export it to the environment with `export`, or invoke `configure` and/or `make` with `LDFLAGS=…` prefixed.

Maniaxx · 2022-02-19 16:44:43

LDFLAGS will be picked up properly. But that doesn't seem to be the problem. I haven't got an explicit answer yet from the developer but it looks like Audacious is not supported anymore. 'configure --help' doesn't show any Audacious option. The lib i selected is probably not intended for Audacious at all.

ayekat · 2022-02-19 21:23:37

Maniaxx wrote:

LDFLAGS will be picked up properly.

Then it's an LDFLAGS that has been previously set. The `./configure` invocation there does not see your LDFLAGS you set there. That's just a basic shell/bash fact.

But yeah, if the issue is with Audacious or that plugin, potentially someone else has a better idea for how to approach this.

Maniaxx · 2022-02-20 07:03:59

ayekat wrote:

The `./configure` invocation there does not see your LDFLAGS you set there. That's just a basic shell/bash fact.

Why shouldn't it see the variable?

ayekat · 2022-02-20 19:01:35

If you set a variable in shell like

foo=bar

that is just a variable visible by the shell interpreter. It is not added to the process environment (and thus not passed down to any child processes, like the call to `./configure` there).

If you want to set a variable in the process environment (such that it is passed down to child processes), you have to export it like

export foo=bar

or

foo=bar
export foo

Alternatively, if you want to start a child process and set an environment variable there (but not in the current shell process), you can also

foo=bar somecommand  # 'somecommand' will inherit foo=bar, but not the shell itself

See https://mywiki.wooledge.org/Environment for more details.

--edit, after reply below I'm talking to a wall here. Good luck.
--edit2 Welp, dumb me. I was wrong.

Last edited by ayekat (2022-02-21 20:19:08)

Maniaxx · 2022-02-21 08:17:28

Yes, that's true regarding running a shell environment like bash. But a makepkg/pkgbuild script environment is not the same.

In short, it does work. The difference of the resulting libraries can be verified/compared with 'ldd'.

If you create any variables of your own in any of these functions, it is recommended to use the Bash local keyword to scope the variable to inside the function.
https://man.archlinux.org/man/PKGBUILD.5

Last edited by Maniaxx (2022-02-21 08:25:17)

Alad · 2022-02-21 15:48:48

Then it's an LDFLAGS that has been previously set. The `./configure` invocation there does not see your LDFLAGS you set there. That's just a basic shell/bash fact.

makepkg exported the variable before you give it a new value in the build() function. See prepare_buildenv() in /usr/share/makepkg/buildenv.sh. So yes, in PKGBUILD the specified LDFLAGS is visible to ./configure whether you explicitly use export or not.

(The quote about the local keyword is however, irrelevant - unless you want to have a local CFLAGS in your build function...)

ayekat · 2022-02-21 20:18:31

Oh, I totally missed that one can `export` a variable and later modify it (and that will also affect the value that was `export`ed), which is indeed the case for certain variables (like LDFLAGS) in makepkg.

Maniaxx, I'd like to apologise for the noise. Alad, thanks for clearing it up.

Maniaxx · 2022-02-22 19:14:32

Np, i've learned more than i expected as well.

Thx guys!

Arch Linux

#1 2022-02-12 21:15:13

[Solved]uade-git - Dependency problem

#2 2022-02-13 16:00:31

Re: [Solved]uade-git - Dependency problem

#3 2022-02-19 16:44:43

Re: [Solved]uade-git - Dependency problem

#4 2022-02-19 21:23:37

Re: [Solved]uade-git - Dependency problem

#5 2022-02-20 07:03:59

Re: [Solved]uade-git - Dependency problem

#6 2022-02-20 19:01:35

Re: [Solved]uade-git - Dependency problem

#7 2022-02-21 08:17:28

Re: [Solved]uade-git - Dependency problem

#8 2022-02-21 15:48:48

Re: [Solved]uade-git - Dependency problem

#9 2022-02-21 20:18:31

Re: [Solved]uade-git - Dependency problem

#10 2022-02-22 19:14:32

Re: [Solved]uade-git - Dependency problem

Board footer