Compiler Option -nodeflib[s]

General discussion for topics related to the FreeBASIC project or its community.
Post Reply
TJF
Posts: 3809
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Compiler Option -nodeflib[s]

Post by TJF »

The compiler auto-links an executable to default libraries, which is good in most cases.

But sometimes a certain library isn't used in the object files, ie a simple command line app doesn't do any text magic, but links against libtinfo. To avoid that, one can use option -nodeflibs and afterwards add the libs needed one by one. But this gets a pain in the rear in case of complex code when using the fbc command line for linking. In that case it's better to directly build a custom command line for the ld-linker, which is complicated and hard to maintain as well.

From my point of view it would be nice to have an option that excludes just one (or a list of) default library, like

Code: Select all

fbc -nodeflib tinfo,dl
This should be easy to implement. Any thoughts?
TJF
Posts: 3809
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: Compiler Option -nodeflib[s]

Post by TJF »

Further optimization potential regarding option -W:

Most build systems (ie CMake) use the default linker flags

Code: Select all

-Wl,-z,relro
working for a bunch of compilers. But fbc complains about the first comma. One has to override the default by

Code: Select all

-Wl -z,relro
That's no big deal for a FreeBASIC only project. But in case of a polyglot project using multiple compilers it gets tricky to switch between different default settings. And it's hard to maintain such tricky build scripts.

In order to be more compatible, I see no reason why fbc shouldn't treat the first comma as a white space.
dkl
Site Admin
Posts: 3235
Joined: Jul 28, 2005 14:45
Location: Germany

Re: Compiler Option -nodeflib[s]

Post by dkl »

About -nodeflib <lib>, it would in theory be useful when linking against .so's, right? Normally the linker automatically skips specified but unused libraries, but not in that case...

However, regarding libtinfo: Does -nodeflibs already help to avoid the libtinfo dependency? I tried but it didn't seem to help. Even an empty FB program already requires libfb, which uses libtinfo already in its initialization code currently, so it seems unavoidable unless libfb would be changed.
TJF
Posts: 3809
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: Compiler Option -nodeflib[s]

Post by TJF »

Thanks for caring about that issue!
dkl wrote: Jun 05, 2022 0:15 About -nodeflib <lib>, it would in theory be useful when linking against .so's, right?
The problem occures when building DEB-packages for libpruio. The library has no IO features (ecxept a single PRINT statement in the DTOR), but the binary (and therefor debbuild) creates a dependency to libtinfo. And that (useless) dependency is causing trouble when installing the packages on different distros with newer libtinfo versions.
dkl wrote: Jun 05, 2022 0:15 However, regarding libtinfo: Does -nodeflibs already help to avoid the libtinfo dependency? I tried but it didn't seem to help. Even an empty FB program already requires libfb, which uses libtinfo already in its initialization code currently, so it seems unavoidable unless libfb would be changed.
I didn't test that yet, since I rate building a customized linker command line as a bad workaround.
dkl
Site Admin
Posts: 3235
Joined: Jul 28, 2005 14:45
Location: Germany

Re: Compiler Option -nodeflib[s]

Post by dkl »

After thinking about this a bit more, I feel like -nodeflibs might already be good enough. It seems better to maintain a list of required dependencies as in -nodeflibs -l fbmt -l pthread -l c (or via #inclib "fbmt" etc. in code), than to maintain an exclude list of dependencies that are not required. I can see both cases potentially requiring updates if the default dependencies for FB change though. Or am I missing something?

Edit: Ah OK, I just noticed another detail: -nodeflibs also disables fbrt0.o, so that would have to be re-added manually aswell...
TJF
Posts: 3809
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: Compiler Option -nodeflib[s]

Post by TJF »

dkl wrote: Jun 20, 2022 17:05... Or am I missing something?
Perhaps ...

Maintaining a white list with multiple entries is much more effort than maintaining a blacklist with a single entry.

The white list may change when the source requires further features. But it also may change when an other set of standard libraries is required in a new compiler version. For handling this the build system has to make a verbose test compilation, fetching a list of all linked library names, before generating a linker command without the black-listet library.

This may be possible for an experienced coder, but may confuse others when they try to build the project themself (or build packages for distros).

The black list would be a more professional solution, without complex build commands for the workaround.

Anyhow, the main issue is libtinfo. When we could get rid of that dependency, there may be no need for any change?

Edit:
dkl wrote: Jun 20, 2022 17:05Edit: Ah OK, I just noticed another detail: -nodeflibs also disables fbrt0.o, so that would have to be re-added manually aswell...
When libfbrt0 is adding further dependencies (perhaps in future), they would have to be re-added manually aswell...
dodicat
Posts: 7976
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: Compiler Option -nodeflib[s]

Post by dodicat »

I tried this in windows.
using the -v option, here are (in part) the libraries linked
-(" -lfb -lgcc -lmsvcrt -lkernel32 -luser32 -lmingw32 -lmingwex -lmoldname -lgcc_eh "-)"
I created an empty program and called it libmingwex.bas.
I compiled to dll and thus libmingwex.dll appeared.
I then loaded this library into my program
#inclib "mingwex"
Here is now my -v output
-(" -lmingwex -lfb -lgcc -lmsvcrt -lkernel32 -luser32 -lmingw32 -lmoldname -lgcc_eh "-)"
So this dummy library has superseded the original.
(I assume the freebasic rule that dynamic before static).
For one unwanted library, could this method not be used if the dummy library in not intrusive?
Or is this whole idea just plain silly?
TeeEmCee
Posts: 375
Joined: Jul 22, 2006 0:54
Location: Auckland

Re: Compiler Option -nodeflib[s]

Post by TeeEmCee »

A commandline arg to exclude a single library would be great. Here's another case where I need it: when including a header that contains an #inclib that I don't actually want to link to, because I instead do runtime linking with dlopen. I get around these problems by not using fbc to link. Or was there already a way to disable inclib?
TJF
Posts: 3809
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: Compiler Option -nodeflib[s]

Post by TJF »

@Dodicat, thanks for testing!

The dummy library isn't necessary, just verbose compile the empty programm.

This basic stuff gets done once when the build system is checking for the compiler. The script CMakeTestFbcCompiler.cmake creates a list of all implicitly linked libraries. Example

Code: Select all

SET(CMAKE_Fbc_IMPLICIT_LINK_LIBRARIES /usr/local/lib/freebasic/linux-x86_64/fbextra.x;/usr/lib/x86_64-linux-gnu/crt1.o;/usr/lib/x86_64-linux-gnu/crti.o;/usr/lib/gcc/x86_64-linux-gnu/11/crtbegin.o;/usr/local/lib/freebasic/linux-x86_64/fbrt0.o;fb;tinfo;m;dl;pthread;gcc;gcc_eh;c;/usr/lib/gcc/x86_64-linux-gnu/11/crtend.o;/usr/lib/x86_64-linux-gnu/crtn.o)
In order to generate a working linker command line for a real project, this list has to get adapted for each dependency added to or removed from source. In case of the libpruio project this is one list for the library and one list for each of the more than ten examples.
adeyblue
Posts: 299
Joined: Nov 07, 2019 20:08

Re: Compiler Option -nodeflib[s]

Post by adeyblue »

TeeEmCee wrote: Jun 21, 2022 10:04 I get around these problems by not using fbc to link. Or was there already a way to disable inclib?
Edit the relevant bi to
#ifndef DISABLE_LINKING_TO_THIS_LIBRARY
#inclib "whatever"
#endif

Then define that when you compile.
dkl
Site Admin
Posts: 3235
Joined: Jul 28, 2005 14:45
Location: Germany

Re: Compiler Option -nodeflib[s]

Post by dkl »

Opened a pull request now, where I'm proposing a -nolib option. It can override default libs or any others such as from #inclib.
TJF
Posts: 3809
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: Compiler Option -nodeflib[s]

Post by TJF »

Thanks for doing the coding, much appreciated!

I miss some docs on the syntax. Is it used by appending one lib name separated by a whitespace like
-nolib tinfo

Can a list of multiple lib names get append separated by comma like
-nolib tinfo,fbrt0

As always: examples would be nice.
dkl
Site Admin
Posts: 3235
Joined: Jul 28, 2005 14:45
Location: Germany

Re: Compiler Option -nodeflib[s]

Post by dkl »

Yea, it's -nolib a,b,c as you had suggested. I've put that into the fbc --help output and the man page, and if this pull request is accepted I'll update the wiki docs too.

I've been using -nolib ncurses,tinfo to test some other changes (rtlib without requiring termcap/ncurses/libtinfo, but those are not included in that pull request).
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Compiler Option -nodeflib[s]

Post by coderJeff »

Pull request looks good and it is merged in. Thanks, dkl.
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Compiler Option -nodeflib[s]

Post by fxm »

Documentation updated (with new compiler option -nolib):
- CompilerOptnolib → fxm [added new page 'Compiler Option: -nolib']
- CatPgCompOpt → fxm [added link to page 'Compiler Option: -nolib']
- CompilerCmdLine → fxm [added link to page 'Compiler Option: -nolib']
- PrintToc → fxm [added link to page 'Compiler Option: -nolib']
Post Reply