New compile error

Compiling from git head, using webkit-gtk either 4.0 or 4.1, I get:

[143/227] Linking target libbalsa/
FAILED: libbalsa/
cc -o libbalsa/ libbalsa/ -Wl,–as-needed -Wl,–no-undefined -shared -fPIC -Wl,–start-group -Wl,-soname, -pg -g -pg -no-pie -Og /usr/lib64/libg /usr/lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/li /usr/lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/ -pthread /usr/lib64/ /usr/lib64/ /us
r/lib64/ -lical -licalss -licalvcal /usr/lib64/ /usr/lib64/ -Wl,–export-dynamic /usr/lib64/ /usr/lib64/ /usr/lib64/libs /usr/lib64/ /usr/lib64/ /usr/lib64/ -Wl,–end-group
/usr/lib/gcc/x86_64-pc-linux-gnu/12/…/…/…/…/x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/12/…/…/…/…/lib64/gcrt1.o: in function _start': (.text+0x17): undefined reference to main’
collect2: error: ld returned 1 exit status
I had initially thought it was related to the version of webkit-gtk, but it fails the same with either one. It’s also not clear to me why would need reference to main.
Thanks for any suggestions.


Hi @ostroffjh !

I haven’t seen that failure, building with meson. It’s been a while since I’ve used the autotools build; I’m not sure I remember how!

Sorry if it wasn’t obvious, but that was using meson and ninja. Like
you, I’ve forgotten what I knew about using autotools, but I seem to
have figured it out, and did get a successful build that way.
Definitely strange.

I finally remembered how to build out-of-tree with autotools :sweat_smile:, and that worked for me, too.

That reference to main is really mysterious, since says that libhtmlfilter is a shared_library, not an executable. I’m stuck.

It’s complaining while creating, but the error is about /usr/lib64/gcrt1.o (which is part of glibc) but I don’t see gcrt.o mentioned in the command that seems to have failed. I’ve briefly looked into the glibc code and gcrt1.o is apparently used instead of crt1.0 to handle debug cases when you might use gprof. That makes me think the error can be avoided by a release build, and is somehow triggered by either the “–buildtype debugoptimized” parameter, or perhaps by my use of -g, -Og. I also see I’ve set CFLAGS to include -no-pie and -pg (also in LDFLAGS) and I have to admit I don’t know what all of them do, and whether I can safely change them.

Maybe go back to a vanilla meson build, and if that succeeds, add options until it fails? If it fails, we have a deeper problem!

It is specifically the --no-pie that causes the failure. I have to go
digging to figure out why I added that. All I can imagine is either I
saw it somewhere else, or I thought it should somehow facilitate
debugging, not that that makes any sense to me now. It’s also not
clear to me why that CFLAG would cause that error - but I suppose
that’s a question for the glibc folks.

This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.