Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

FreeBSD with LLVM backend: Link error for symbols environ and __progname #501

Closed
endofexclusive opened this issue Dec 18, 2017 · 6 comments · May be fixed by #1020
Closed

FreeBSD with LLVM backend: Link error for symbols environ and __progname #501

endofexclusive opened this issue Dec 18, 2017 · 6 comments · May be fixed by #1020
Labels
Backend: LLVM GHDL using Low-Level Virtual Machine for code generation OS: FreeBSD

Comments

@endofexclusive
Copy link
Contributor

GHDL with the LLVM back-end builds nicely on FreeBSD 11.1. However, using the generated GHDL does not work out of the box: the linker fails at elaboration.

The problem described in this issue can be solved by adding environ and __progname to src/grt/grt.ver. I choose to add an issue rather than a pull request, since I don't have full understanding of the behavior, and there might be better solutions.

$ git describe
v0.35-20-g1d61cbbd
$ uname -a
FreeBSD sb 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321309: Fri Jul 21 02:08:28 UTC 2017     root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
$ /usr/local/gcc6-aux/bin/gnatmake --version
GNATMAKE 6.3.1 20170202 (snapshot) -=> GNAT AUX [FreeBSD64]
$ /usr/local/llvm40/bin/llvm-config --version
4.0.1
$ mkdir build-llvm && cd build-llvm
$ MAKE=gmake GNATMAKE=/usr/local/gcc6-aux/bin/gnatmake ../configure --prefix=/opt/ghdl-dev-llvm --with-llvm-config=/usr/local/llvm40/bin/llvm-config
$ gmake
$ gmake install
$ ghdl --version
GHDL 0.36-dev (v0.35-20-g1d61cbbd) [Dunoon edition]
 Compiled with GNAT Version: 6.3.1 20170202 (snapshot)
 llvm code generator
$ # GHDL builds OK! Now try it
$ cd /tmp/hello
$ ghdl -a hello.vhdl
$ ls
hello.o       hello.vhdl    work-obj93.cf
$ ghdl -e hello_world
/usr/local/bin/ld: hello_world: local symbol `environ' in /usr/lib/crt1.o is referenced by DSO
/usr/local/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
ghdl:error: compilation error
$ ghdl -e -v hello_world
/home/asdf/opt/ghdl-dev-llvm/bin/ghdl1-llvm -P/home/asdf/opt/ghdl-dev-llvm/lib/ghdl/v93/std/ -P/home/asdf/opt/ghdl-dev-llvm/lib/ghdl/v93/ieee/ --elab hello_world -l e~hello_world.lst -c -o e~hello_world.o e~hello_world
/usr/local/bin/gcc -o hello_world e~hello_world.o /home/asdf/opt/ghdl-dev-llvm/lib/ghdl/v93/std/std_standard.o /home/asdf/opt/ghdl-dev-llvm/lib/ghdl/v93/std/textio.o /home/asdf/opt/ghdl-dev-llvm/lib/ghdl/v93/std/textio_body.o hello.o /home/asdf/opt/ghdl-dev-llvm/lib/ghdl/libgrt.a -lm -Wl,--version-script=/home/asdf/op
t/ghdl-dev-llvm/lib/ghdl/grt.ver -Wl,--export-dynamic -L./ -lz
/usr/local/bin/ld: hello_world: local symbol `environ' in /usr/lib/crt1.o is referenced by DSO
/usr/local/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
ghdl:error: compilation error
@Paebbels Paebbels added Backend: LLVM GHDL using Low-Level Virtual Machine for code generation OS: FreeBSD labels Dec 19, 2017
@tgingold
Copy link
Member

Can you know which DSO references 'environ' ?
Can you try to link with grt.ver and without --export-dynamic ?

It is not a problem to add these symbols on freebsd, we I'd like to fully understand the issue first.

@endofexclusive
Copy link
Contributor Author

Linking without --export-dynamic did not change it.

Indeed /lib/libc.so.7 references both environ and __progname which is defined in /usr/lib/crt1.o:

$ nm --print-file-name -D /lib/*.so*|grep -e " environ" -e " __progname"
/lib/libc.so.7:                 U __progname
/lib/libc.so.7:                 U environ

And it is mentioned in the FreeBSD libc source code aswell, in lib/libc/include/libc_private.h:

/*
 * This is a pointer in the C run-time startup code. It is used
 * by getprogname() and setprogname().
 */
extern const char *__progname;

environ is used at different places:

$ cd lib/libc
$ git grep "environ;"
gen/auxv.c:extern char **environ;
gen/auxv.c:     sp = (Elf_Addr *)environ;
gen/exec.c:extern char **environ;
gen/popen.c:extern char **environ;
gen/posix_spawn.3:extern char **environ;
gen/posix_spawn.c:extern char **environ;
gen/tls.c:extern char **environ;
gen/tls.c:      sp = (Elf_Addr *) environ;
stdlib/getenv.c:extern char **environ;
stdlib/getenv.c:        origEnviron = environ;
stdlib/getenv.c:                origEnviron = environ;
tests/gen/ftw_test.c:extern char **environ;

Just adding

__progname;
environ;

to the global section of grt.ver does the trick.

@tgingold
Copy link
Member

tgingold commented Dec 20, 2017 via email

@endofexclusive
Copy link
Contributor Author

with -Wl,--version-script=<dir>grt.ver -Wl,--export-dynamic: link failure (default case)
with -Wl,--version-script=<dir>grt.ver: link failure
with -Wl,--export-dynamic: link OK
removing both --version-script and --export-dynamic: link OK

I tried to follow the linking dependencies with the linker --trace option and with -Map=file, but nothing more was revealed. My understanding is that the grt.ver description explicitly marks certain symbols local (defined by FreeBSD crt1.o in this case), and that the linker later refuses to resolve references to these (from FreeBSD libc.a).

Similar issue in 2015:
http://ghdl-discuss.gna.narkive.com/ezVsU0Rk/ghdl-0-32rc1-problem-on-freebsd-10-1
The patch proposed in that thread was:

src/grt/Makefile.inc
   ifeq ($(filter-out netbsd freebsd% dragonfly%,$(osys)),)
-    GRT_EXTRA_LIB=-lm $(GRT_ELF_OPTS)
+    GRT_EXTRA_LIB=-lm
   endif

I tried it with the vests tests and it passes.

@tgingold
Copy link
Member

tgingold commented Dec 23, 2017 via email

@tgingold
Copy link
Member

tgingold commented Jan 2, 2018

I close this issue; any pull request is welcome.

@tgingold tgingold closed this as completed Jan 2, 2018
@endofexclusive endofexclusive mentioned this issue Nov 14, 2019
Open
@tgingold tgingold mentioned this issue Feb 23, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Backend: LLVM GHDL using Low-Level Virtual Machine for code generation OS: FreeBSD
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Allow building GHDL mcode on FreeBSD endofexclusive/ghdl
3 participants
@Paebbels @endofexclusive @tgingold