When compiling a program from source code that has many
required library's, and compiling them from source also
is there a way to determine what order
the required libs need to be compiled?

On 16/08/2023 17:05, Kirk_Rockstein wrote:
> When compiling a program from source code that has many
> required library's, and compiling them from source also
> is there a way to determine what order
> the required libs need to be compiled?

It's in the makefile. If A depends on B, B is compiled first.

--
In a Time of Universal Deceit, Telling the Truth Is a Revolutionary Act.

- George Orwell

On 2023-08-16 13:21, The Natural Philosopher wrote:
> On 16/08/2023 17:05, Kirk_Rockstein wrote:
>> When compiling a program from source code that has many
>> required library's, and compiling them from source also
>> is there a way to determine what order
>> the required libs need to be compiled?
>
> It's in the makefile.  If A depends on B, B is compiled first.

Or, if they're from different packages, prerequisites are documented in
the INSTALL file that is customarily part of the source.

If A depends on B it will say so in the INSTALL (or README) file for A.
Then the docs for B could say it depends on C. So you read up on
package C, and so on until you get to a library that doesn't depend on
any other. Then you start by compiling it and working your way back up
the chain.

If you're building from source, it's typically up to you handle
dependencies manually.

On Wed, 16 Aug 2023 15:18:22 -0400, John-Paul Stewart wrote:

> On 2023-08-16 13:21, The Natural Philosopher wrote:
>> On 16/08/2023 17:05, Kirk_Rockstein wrote:
>>> When compiling a program from source code that has many
>>> required library's, and compiling them from source also
>>> is there a way to determine what order
>>> the required libs need to be compiled?
>>
>> It's in the makefile.  If A depends on B, B is compiled first.
>
> Or, if they're from different packages, prerequisites are documented in
> the INSTALL file that is customarily part of the source.
>
> If A depends on B it will say so in the INSTALL (or README) file for A.
> Then the docs for B could say it depends on C. So you read up on
> package C, and so on until you get to a library that doesn't depend on
> any other. Then you start by compiling it and working your way back up
> the chain.
>
> If you're building from source, it's typically up to you handle
> dependencies manually.

Quite often (in my experience, most of the time) 3rd-party source packages
come with the support files for one (or more) build systems. For these
packages, you use tools like CMake or Autoconf to build the makefile that
will then be used to build the program, libraries, etc.

In these cases, the build system detects and reports missing dependencies.

The OP should look for these reports, and manually follow the chain
of dependent installations.

HTH
--
Lew Pitcher
"In Skills We Trust"

Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> On Wed, 16 Aug 2023 15:18:22 -0400, John-Paul Stewart wrote:
>> Or, if they're from different packages, prerequisites are documented in
>> the INSTALL file that is customarily part of the source.
>>
>> If A depends on B it will say so in the INSTALL (or README) file for A.
>> Then the docs for B could say it depends on C. So you read up on
>> package C, and so on until you get to a library that doesn't depend on
>> any other. Then you start by compiling it and working your way back up
>> the chain.
>>
>> If you're building from source, it's typically up to you handle
>> dependencies manually.
>
> Quite often (in my experience, most of the time) 3rd-party source packages
> come with the support files for one (or more) build systems. For these
> packages, you use tools like CMake or Autoconf to build the makefile that
> will then be used to build the program, libraries, etc.
>
> In these cases, the build system detects and reports missing dependencies.

Maybe, but both ./configure scripts, and the few times I've used
CMake, they tend to quietly disable functionality (eg. GUI) if
certain libraries aren't found. With most ./configure scripts you
can use --enable-[option] to force behaviour based on the options
listed with "./configure --help". CMake has some silly interactive
equivalent. If there's a good README or INSTALL file then the
instructions there are probably clearer than guessing things based
on vague configure options, but often there isn't.

Pkgsrc can also be used to automate resolving dependencies while
compiling software on Linux, if the program has been packaged for
NetBSD. But it's not all that reliable in my (minimal) experience.

--
__ __
#_ < |\| |< _#

On 2023-08-16 15:38, Lew Pitcher wrote:
> On Wed, 16 Aug 2023 15:18:22 -0400, John-Paul Stewart wrote:
>
>> On 2023-08-16 13:21, The Natural Philosopher wrote:
>>> On 16/08/2023 17:05, Kirk_Rockstein wrote:
>>>> When compiling a program from source code that has many
>>>> required library's, and compiling them from source also
>>>> is there a way to determine what order
>>>> the required libs need to be compiled?
>>>
>>> It's in the makefile.  If A depends on B, B is compiled first.
>>
>> Or, if they're from different packages, prerequisites are documented in
>> the INSTALL file that is customarily part of the source.
>>
>> If A depends on B it will say so in the INSTALL (or README) file for A.
>> Then the docs for B could say it depends on C. So you read up on
>> package C, and so on until you get to a library that doesn't depend on
>> any other. Then you start by compiling it and working your way back up
>> the chain.
>>
>> If you're building from source, it's typically up to you handle
>> dependencies manually.
>
> Quite often (in my experience, most of the time) 3rd-party source packages
> come with the support files for one (or more) build systems. For these
> packages, you use tools like CMake or Autoconf to build the makefile that
> will then be used to build the program, libraries, etc.
>
> In these cases, the build system detects and reports missing dependencies.
>
> The OP should look for these reports, and manually follow the chain
> of dependent installations.

Sure, that's another way to achieve the same result.

Personally, I find it infuriating to run the configure script, discover
a missing prerequisite, install it, and then re-run configure only to
discover another missing prerequisite and so on and so forth. That is
to say, autoconf-based configure scripts tend to abort at the first
missing prerequisite rather than listing them all at once, IME.
Conversely, good documentation will list them all.

But whatever works, works! It's good for the OP to know there's more
than one way to get there.

On 17/08/2023 00:13, John-Paul Stewart wrote:
> Personally, I find it infuriating to run the configure script, discover
> a missing prerequisite, install it, and then re-run configure only to
> discover another missing prerequisite and so on and so forth. That is
> to say, autoconf-based configure scripts tend to abort at the first
> missing prerequisite rather than listing them all at once, IME.
> Conversely, good documentation will list them all.

What i find irritating is that they need a newer versions of some
library than the one you have installed, and you have to upgrade the
whole operating system to compile some hacked up bit of code that
doesn't work anyway.

These days I prefer to write my own code

--
Climate Change: Socialism wearing a lab coat.

The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 17/08/2023 00:13, John-Paul Stewart wrote:
>> Personally, I find it infuriating to run the configure script, discover
>> a missing prerequisite, install it, and then re-run configure only to
>> discover another missing prerequisite and so on and so forth. That is
>> to say, autoconf-based configure scripts tend to abort at the first
>> missing prerequisite rather than listing them all at once, IME.
>> Conversely, good documentation will list them all.
>
> What i find irritating is that they need a newer versions of some
> library than the one you have installed, and you have to upgrade the
> whole operating system to compile some hacked up bit of code that
> doesn't work anyway.
>
> These days I prefer to write my own code

The worst one like that lately for me has been OpenSSL. Now that
I've finally got everything comfortable with v1.1.1, I recently
ran into trouble with something that expected v3!

But I'm not going to try writing my own encryption code, for
obvious reasons.

--
__ __
#_ < |\| |< _#