undefined references
I'm compiling with DMD 2.065 using dub, and I've gotten some undefined reference errors for symbols inside my own project. Trying to run dustmite doesn't help, it keeps reporting that its done in one iteration, and gives me an empty results folder. I've used it before, its pretty straightforward, not sure whats going wrong. I'm not sure what else to try. This is my first encounter with a linker error that didn't have to do with an external library.
Re: undefined references
Ok, I've gotten to the bottom of this issue but I'm not totally
sure how to submit a bug report for this (no SSCCE: can't get
dustmite to work on it, and the problem won't show itself when I
use the offending module in isolation) so I will try to sum up
the issue and maybe I can provide some useful information for the
devs.
I have a generic Vector struct that is constructed by helper
functions that deduce the length and element type and forward the
arguments to the appropriate constructor. Almost all of them had
a constraint on them that required the length of the vector the
be at least 2, but the Vector class itself had no such
constraint, and one of the helper functions was missing it as
well.
When I added the constraint to either the Vector struct or the
helper function (I've since added them to both) then everything
links fine. It looks like what was happening was that a "fill
constructor helper function" (intended use: vector!4 (x) =>
vector (x, x, x, x)) was routing to a "variadic constructor
helper function" (vector (args) => vector!(args.length)(args))
that attempted to generate a 1-element vector and somewhere along
the way - linker error.
There are the mangled names that the linker could not resolve
references to:
`_D3evx7vectors16__T6VectorVm1TdZ6Vector6__initZ`
`_D3evx7vectors16__T6VectorVm1TdZ6Vector6__ctorMFNaNbNcNfdZS3evx7vectors16__T6VectorVm1TdZ6Vector`
the second of which demangles to this:
pure nothrow ref @safe evx.vectors.Vector!(1uL, double).Vector
evx.vectors.Vector!(1uL, double).Vector.__ctor(double)
So, there's my one-element vector constructor, which is likely
having a hard time with the following overloads:
this (Elements...)(Elements elements)
if (Elements.length == length)
{
foreach (i, element; elements)
components[i] = element;
}
this (Element element)
{
components[] = element;
}
So, while the mistake was mine, this should be an ambiguous
overload error at compile-time, instead of a linker error.
I realize that everyone contributing to D has their hands more
than full, and a bug this rare (assumption based on lack of
search results) is gonna be low-priority, so I'm just making this
post for posterity - maybe it'll help, and of course I'm happy to
try anything and give additional information. If anyone has any
suggestions on how I might go about making a useful bug report
out of this, I'm all ears.
Re: undefined references
On Monday, 11 August 2014 at 03:12:45 UTC, Vlad Levenfeld wrote:
[snip]
this (Elements...)(Elements elements)
if (Elements.length == length)
{
foreach (i, element; elements)
components[i] = element;
}
this (Element element)
{
components[] = element;
}
[snip]
The following gives an error in 2066
struct S(F, size_t L)
{
F[L] c;
this(E...)(E el)
if(E.length == L)
{
foreach(i, e; el) {
c[i]= e;
}
}
this(F e) {
c[0] = e;
}
}
void main()
{
auto s = S!(double, 1)(1);
auto s = S!(double, 3)(1,2,3); // <-- ERROR: declaration
hacks.main.s is already defined
}
Cheers,
uri
Re: undefined references
On Monday, 11 August 2014 at 04:02:12 UTC, uri wrote:
On Monday, 11 August 2014 at 03:12:45 UTC, Vlad Levenfeld wrote:
[snip]
this (Elements...)(Elements elements)
if (Elements.length == length)
{
foreach (i, element; elements)
components[i] = element;
}
this (Element element)
{
components[] = element;
}
[snip]
The following gives an error in 2066
struct S(F, size_t L)
{
F[L] c;
this(E...)(E el)
if(E.length == L)
{
foreach(i, e; el) {
c[i]= e;
}
}
this(F e) {
c[0] = e;
}
}
void main()
{
auto s = S!(double, 1)(1);
auto s = S!(double, 3)(1,2,3); // <-- ERROR: declaration
hacks.main.s is already defined
}
Cheers,
uri
Bah, never mind me I'm having a moment !
The above example works in 2066 when the second 's' is renamed to
s1, as does this:
auto s = S!(float, 1)(1); // eq: S!(float, 1)(1)
auto s1 = S!(float, 2)(1); // eq: S!(float, 2)(1,nan)
auto s2 = S!(float, 2)(1, 2) // eq: S!(float,2)(1,2)
Cheers,
uri
Re: undefined references
On Mon, Aug 11, 2014 at 03:12:43AM +, Vlad Levenfeld via Digitalmars-d-learn wrote: [...] > So, while the mistake was mine, this should be an ambiguous overload > error at compile-time, instead of a linker error. > > I realize that everyone contributing to D has their hands more than > full, and a bug this rare (assumption based on lack of search results) > is gonna be low-priority, so I'm just making this post for posterity - > maybe it'll help, and of course I'm happy to try anything and give > additional information. If anyone has any suggestions on how I might > go about making a useful bug report out of this, I'm all ears. While we generally prefer bug reports for which there is a small reproducible test case, I'd also say that filing a bug is better than not filing a bug, because chances are, *somebody* else out there might have encountered the same problem but haven't bothered to report it. If the problem isn't reported, then your helpful description will just get lost in the dusts of forum history, and it will never get fixed. If it's at least filed, then there's *some* hope somebody will figure out what the problem is and fix it. T -- In order to understand recursion you must first understand recursion.
Druntime undefined references
Hi guys! I build the druntime for an ARM Cortex-M based microcontroller and I trying to create an application and link it with the druntime. I am also using TockOS[1], which does not implement POSIX thread calls and other OS-dependent implementations. As I was looking through the errors I got, I found some functions and I don’t know what they do, or how should I solve the errors. The first one is: libdruntime-ldc.a(dwarfeh.o): in function `_d_eh_personality_common': dwarfeh.d:(.text._d_eh_personality_common[_d_eh_personality_common]+0x2c): undefined reference to `_d_eh_GetIPInfo' and the second one is: dl.d:(.text._D4core8internal3elf2dl12SharedObject14thisExecutableFNbNiZSQCgQCeQByQBxQBx[_D4core8internal3elf2dl12SharedObject14thisExecutableFNbNiZSQCgQCeQByQBxQBx]+0x1a): undefined reference to `dl_iterate_phdr' (the druntime was build as a static library, because I can’t use dynamic libraries on a microcontroller) Does anyone know what these exactly do and how important/essential are they? Is there any way I could solve them? Thank a lot. [1]: https://www.tockos.org
Re: Druntime undefined references
On 11/2/20 1:50 PM, Severin Teona wrote:
Hi guys!
I build the druntime for an ARM Cortex-M based microcontroller and I
trying to create an application and link it with the druntime. I am also
using TockOS[1], which does not implement POSIX thread calls and other
OS-dependent implementations. As I was looking through the errors I got,
I found some functions and I don’t know what they do, or how should I
solve the errors.
The first one is:
libdruntime-ldc.a(dwarfeh.o): in function `_d_eh_personality_common':
dwarfeh.d:(.text._d_eh_personality_common[_d_eh_personality_common]+0x2c):
undefined reference to `_d_eh_GetIPInfo'
and the second one is:
dl.d:(.text._D4core8internal3elf2dl12SharedObject14thisExecutableFNbNiZSQCgQCeQByQBxQBx[_D4core8internal3elf2dl12SharedObject14thisExecutableFNbNiZSQCgQCeQByQBxQBx]+0x1a):
undefined reference to `dl_iterate_phdr'
(the druntime was build as a static library, because I can’t use dynamic
libraries on a microcontroller)
Does anyone know what these exactly do and how important/essential are
they? Is there any way I could solve them?
Thank a lot.
[1]: https://www.tockos.org
cant' help much but just in case - see
https://github.com/ldc-developers/ldc/pull/2405#issuecomment-346187456,
may be it helps
also you can define this symbol yourself with assert(0) to check if it
is called at all
what about - quick glance at
https://linux.die.net/man/3/dl_iterate_phdr says us that this symbol is
used only with shared objects so you can try to define it yourself with
assert(0) like this (not tested!!!):
```D
extern(C):
alias Callback = int function (void*, size_t, void*);
int dl_iterate_phdr(Callback callback, void* data)
{
assert(0);
}
```
this lets you to link druntime at least and if those symbols were called
abort the execution
Re: Druntime undefined references
On Monday, 2 November 2020 at 10:50:06 UTC, Severin Teona wrote: Hi guys! I build the druntime for an ARM Cortex-M based microcontroller and I trying to create an application and link it with the druntime. I am also using TockOS[1], which does not implement POSIX thread calls and other OS-dependent implementations. As I was looking through the errors I got, I found some functions and I don’t know what they do, or how should I solve the errors. The first one is: libdruntime-ldc.a(dwarfeh.o): in function `_d_eh_personality_common': dwarfeh.d:(.text._d_eh_personality_common[_d_eh_personality_common]+0x2c): undefined reference to `_d_eh_GetIPInfo' and the second one is: dl.d:(.text._D4core8internal3elf2dl12SharedObject14thisExecutableFNbNiZSQCgQCeQByQBxQBx[_D4core8internal3elf2dl12SharedObject14thisExecutableFNbNiZSQCgQCeQByQBxQBx]+0x1a): undefined reference to `dl_iterate_phdr' (the druntime was build as a static library, because I can’t use dynamic libraries on a microcontroller) Does anyone know what these exactly do and how important/essential are they? Is there any way I could solve them? Thank a lot. [1]: https://www.tockos.org https://man7.org/linux/man-pages/man3/dl_iterate_phdr.3.html dl_iterate_phdr is used to iterate over the elf program headers and is used to get a textual back trace among other things. These are typically calls found in Linux systems and if you don't have that, you have to replace them with your own calls or just remove the call all together. Much of the elf stuff can be removed. The only things that might be essential is that druntime needs to know where the TLS data is per thread for scanning.
Undefined references in Druntime for microcontrollers
Hi guys, I have been trying to port the current druntime for microcontrollers (that very little RAM and flash memory). I have been using the 'ldc-build-runtime' tool and finally I managed to compile something that looks alright. The problem is that I compiled the druntime with the flag 'BUILD_SHARED_LIBS=OFF' (as the microcontrollers don't work with dynamic libraries), and when I try to link the druntime with the application for the microcontroller, I get many errors about undefined references (references that would normally be present in those dynamic libraries). Few of them are: - 'munmap' - 'clock_gettime' - `pthread_mutex_trylock' etc. Could you help me by telling me what libraries (and how) should I statically compile and link to the druntime? The microcontroller's CPU is an ARM Cortex-M4, and the libraries should be able to be compiled for this architecture. Thank you so much!
Re: Undefined references in Druntime for microcontrollers
On Monday, 19 October 2020 at 06:25:17 UTC, Severin Teona wrote: - 'munmap' - 'clock_gettime' - `pthread_mutex_trylock' etc. These are typically calls found in a Unix system, Linux for example. In a microcontroller you will likely not support these at all except clock_gettime. You need to dissect druntime a bit further to remove these and/or find a replacement that does the same thing.
Re: Undefined references in Druntime for microcontrollers
On Monday, 19 October 2020 at 06:25:17 UTC, Severin Teona wrote: Could you help me by telling me what libraries (and how) should I statically compile and link to the druntime? The microcontroller's CPU is an ARM Cortex-M4, and the libraries should be able to be compiled for this architecture. Thank you so much! Most probably they should be provided by your RTOS. At least, FreeRTOS have project for implement Posix thread calls.
Undefined references when linking to C library
Hello all. I'm writing a simple terminal game (that will eventually be turned into a simple SDL game) and thought I would add mouse support via libgpm. So, I converted gpm.h into gpm.d. Perhaps I didn't do this correctly because I get several undefined references when trying to link. Here's an example: The original gpm.h says: extern int gpm_zerobased; extern unsigned char_gpm_buf[]; extern unsigned short * _gpm_arg; My gpm.d says: extern int gpm_zerobased; extern char* _gpm_buf; extern ushort* _gpm_arg; When running 'dmd gev.d gpm.d -L-lgpm', I get: gpm.d:(.text._D3gpm15Gpm_DrawPointerFiiiZv+0x12): undefined reference to `_D3gpm8_gpm_bufPa' gpm.d:(.text._D3gpm15Gpm_DrawPointerFiiiZv+0x26): undefined reference to `_D3gpm13gpm_zerobasedi' gpm.d:(.text._D3gpm15Gpm_DrawPointerFiiiZv+0x34): undefined reference to `_D3gpm8_gpm_argPt' Does anyone have any ideas? Thank you, - Peter
Re: Undefined references when linking to C library
On Wednesday 22 December 2010 19:25:35 Peter Federighi wrote: > Hello all. > > I'm writing a simple terminal game (that will eventually be turned into a > simple SDL game) and thought I would add mouse support via libgpm. So, I > converted gpm.h into gpm.d. Perhaps I didn't do this correctly because I > get several undefined references when trying to link. > > Here's an example: > The original gpm.h says: > extern int gpm_zerobased; > extern unsigned char_gpm_buf[]; > extern unsigned short * _gpm_arg; > > My gpm.d says: > extern int gpm_zerobased; > extern char* _gpm_buf; > extern ushort* _gpm_arg; > > When running 'dmd gev.d gpm.d -L-lgpm', I get: > gpm.d:(.text._D3gpm15Gpm_DrawPointerFiiiZv+0x12): undefined reference to > `_D3gpm8_gpm_bufPa' > gpm.d:(.text._D3gpm15Gpm_DrawPointerFiiiZv+0x26): undefined reference to > `_D3gpm13gpm_zerobasedi' > gpm.d:(.text._D3gpm15Gpm_DrawPointerFiiiZv+0x34): undefined reference to > `_D3gpm8_gpm_argPt' > > Does anyone have any ideas? Did you wrap the C declarations in an extern(C) block? Without that, it's going to think that your variables are D variables not C variables. The same goes for any functions - _especially_ for the functions. In fact, a large portion of - in not all of - your gpm.d file should likely be in extern(C). You can try htod ( http://www.digitalmars.com/d/2.0/htod.html ) and see what it creates. It won't necessarily be correct, but it might be, and it might give you a better idea of where you screwed up. It's a Windows program, but it will run in wine. - Jonathan M Davis
Re: Undefined references when linking to C library
Jonathan M Davis wrote: > Did you wrap the C declarations in an extern(C) block? Without that, it's > going > to think that your variables are D variables not C variables. The same goes > for > any functions - _especially_ for the functions. In fact, a large portion of - > in > not all of - your gpm.d file should likely be in extern(C). I tried "extern (C)" for the whole module and individually. I get the following error: /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld: _gpm_arg: TLS reference in gev.o mismatches non-TLS definition in /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib/libgpm.so section .data /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib/libgpm.so: could not read symbols: Bad value collect2: ld returned 1 exit status --- errorlevel 1 Is this a 32/64 bit issue? I have both versions of libgpm installed. Those file paths are obtuse, but they do point to the 32 bit libraries. I've successfully compiled other programs that use C libraries such as SDL and OpenGL (both via the Derelict2 modules). I also tried htod and compared the output with what I wrote. The differences are inconsequential. Thank you, - Peter Federighi
Re: Undefined references when linking to C library
On Thursday 23 December 2010 11:38:28 Peter Federighi wrote: > Jonathan M Davis wrote: > > Did you wrap the C declarations in an extern(C) block? Without that, it's > > going to think that your variables are D variables not C variables. The > > same goes for any functions - _especially_ for the functions. In fact, a > > large portion of - in not all of - your gpm.d file should likely be in > > extern(C). > > I tried "extern (C)" for the whole module and individually. I get the > following error: > /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld: > _gpm_arg: TLS reference in gev.o mismatches non-TLS definition in > /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib/libgpm.so section > .data /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib/libgpm.so: > could not read symbols: Bad value > collect2: ld returned 1 exit status > --- errorlevel 1 > > Is this a 32/64 bit issue? I have both versions of libgpm installed. > Those file paths are obtuse, but they do point to the 32 bit libraries. > I've successfully compiled other programs that use C libraries such as SDL > and OpenGL (both via the Derelict2 modules). > > I also tried htod and compared the output with what I wrote. The > differences are inconsequential. Yeah. It looks like the compiler is finding the 64-bit versions rather than the 32-bit versions. How to fix that will likely depend on the libraries in question and on how your system is set up. Obviously, a 32-bit chroot environment would fix the problem, but that's also obviously not a pleasant, or even necessarily simple, solution. I'm not really all that well-versed in dealing with linking issues like this, but I'd say that either the compiler is just not finding the 32-bit versions, because of a messed up or missing path, or you need to be linking separately because you're on a 64-bit system (which I don't _think_ is the case, but it might be). Regardless, you can try compiling all of the code with -c and then linking it with gcc directly (probably with -m32). Unfortunately, while I do run a 64-bit environment, due to problems with Arch and multilib systems, I've generally had to run dmd in a chrooted environment, and you don't have to deal with the 32-bit vs 64-bit issues with that, so I don't have much experience with this sort of problem. Regardless, I'll be very glad when the 64-bit port of dmd is completed. - Jonathan M Davis
Re: Undefined references when linking to C library
Peter Federighi wrote: > Jonathan M Davis wrote: >> Did you wrap the C declarations in an extern(C) block? Without that, it's >> going >> to think that your variables are D variables not C variables. The same goes >> for >> any functions - _especially_ for the functions. In fact, a large portion of >> - in >> not all of - your gpm.d file should likely be in extern(C). > > I tried "extern (C)" for the whole module and individually. I get the > following > error: > /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld: > _gpm_arg: TLS reference in gev.o mismatches non-TLS definition in > /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib/libgpm.so section .data > /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib/libgpm.so: could not read > symbols: Bad value > collect2: ld returned 1 exit status > --- errorlevel 1 > > Is this a 32/64 bit issue? I have both versions of libgpm installed. Those > file > paths are obtuse, but they do point to the 32 bit libraries. I've > successfully > compiled other programs that use C libraries such as SDL and OpenGL (both via > the > Derelict2 modules). > I think gpm_zerobased, _bpm_buf and _gpm_arg should be declared __gshared. Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: Undefined references when linking to C library
On 23.12.2010 20:38, Peter Federighi wrote: Jonathan M Davis wrote: Did you wrap the C declarations in an extern(C) block? Without that, it's going to think that your variables are D variables not C variables. The same goes for any functions - _especially_ for the functions. In fact, a large portion of - in not all of - your gpm.d file should likely be in extern(C). I tried "extern (C)" for the whole module and individually. I get the following error: /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld: _gpm_arg: TLS reference in gev.o mismatches non-TLS definition in /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib/libgpm.so section .data /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib/libgpm.so: could not read symbols: Bad value collect2: ld returned 1 exit status --- errorlevel 1 Is this a 32/64 bit issue? I have both versions of libgpm installed. Those file paths are obtuse, but they do point to the 32 bit libraries. I've successfully compiled other programs that use C libraries such as SDL and OpenGL (both via the Derelict2 modules). I also tried htod and compared the output with what I wrote. The differences are inconsequential. Thank you, - Peter Federighi I've had simmilar issue a few days ago. The problem is that global values from C should be marked shared in D extern int val; -> extern (C) shared int val; or maybe __gshared. Both makes linking stage finishes with success.
Re: Undefined references when linking to C library
wrzosk wrote: > I've had simmilar issue a few days ago. The problem is that global values > from C should be marked shared in D > extern int val; -> extern (C) shared int val; > or maybe __gshared. Both makes linking stage finishes with success. Jerome M. Berger wrote: > I think gpm_zerobased, _bpm_buf and _gpm_arg should be declared __gshared. Indeed. So I added a bunch of "__gshared"s to all the variables and it compiles and links. Yah! I just have to remember to declare handler functions with extern (C), otherwise the program will segfault once the handler returns. Where should I post/upload the files that I converted? There are a whole two of them: One is gpm.h which is specific to libgpm. The other is paths.h which I was surprised to find not already available. I would assume that it should be available as std.c.linux.paths or core.sys.posix.paths. Also, should the files end with .d or .di I may be the only person who wants to use libgpm with D, but I figure it should be available just in case. Thank you all for your help. - Peter Federighi
gdc 12.1: undefined references when linking separately compiled files
I am trying to build a project with GDC. It successfully compiles with dmd and ldmd2. When I use gdc in one go the binary is successfully build: ``` $ gdc -o ppinsta esah.d evaluate.d jsr.d jsw.d parser.d ppinsta.d ptvr.d stack.d testdatagenerator.d ``` Though after compiling separately the linking fails: ``` $ make -f Makefile.gdc -j3 gdc -o ppinsta.o -c ppinsta.d gdc -o esah.o -c esah.d gdc -o evaluate.o -c evaluate.d gdc -o jsr.o -c jsr.d gdc -o jsw.o -c jsw.d gdc -o parser.o -c parser.d gdc -o ptvr.o -c ptvr.d gdc -o stack.o -c stack.d gdc -o testdatagenerator.o -c testdatagenerator.d gdc -o ppinsta ppinsta.o esah.o evaluate.o jsr.o jsw.o parser.o ptvr.o stack.o testdatagenerator.o ppinsta.o: In function `_D3std6format8internal5write__T8getWidthTAyaZQoFNaNfQlZl': ppinsta.d:(.text+0x1c5a): undefined reference to `_D3std9algorithm9searching__T3allSQBg6format8internal5write__T8getWidthTAyaZQoFQhZ9__lambda2Z__TQCpTQBcZQCxMFNaNfQBpZb' ppinsta.o: In function `_D3std6format8internal5write__T20formatValueImplUlongTSQCb5array__T8AppenderTAyaZQoTaZQCdFNaNfKQBpmIbMKxSQDzQDy4spec__T10FormatSpecTaZQpZv': ppinsta.d:(.text+0x2bcc): undefined reference to `_D3std9algorithm9searching__T3allSQBg6format8internal5write__T20formatValueImplUlongTSQDg5array__T8AppenderTAyaZQoTaZQCdFKQBlmIbMKxSQFaQDu4spec__T10FormatSpecTaZQpZ10__lambda16Z__TQFvTAaZQGcMFNaNfQmZb' ppinsta.d:(.text+0x2c5b): undefined reference to `_D3std9algorithm9searching__T3allSQBg6format8internal5write__T20formatValueImplUlongTSQDg5array__T8AppenderTAyaZQoTaZQCdFKQBlmIbMKxSQFaQDu4spec__T10FormatSpecTaZQpZ10__lambda17Z__TQFvTAaZQGcMFNaNfQmZb' collect2: error: ld returned 1 exit status make: *** [ppinsta] Error 1 ``` Any ideas?
Re: gdc 12.1: undefined references when linking separately compiled files
On Saturday, 28 May 2022 at 13:12:46 UTC, kdevel wrote: I am trying to build a project with GDC. It successfully compiles with dmd and ldmd2. When I use gdc in one go the binary is successfully build: [...] Is seperate compilation working successfully for dmd and ldc? The only bug I know of regarding seperate compilation is https://issues.dlang.org/show_bug.cgi?id=20641
Re: gdc 12.1: undefined references when linking separately compiled files
On Saturday, 28 May 2022 at 13:12:46 UTC, kdevel wrote: gdc -o ppinsta ppinsta.o esah.o evaluate.o jsr.o jsw.o parser.o ptvr.o stack.o testdatagenerator.o You might need to add -lgphobos or -lgphobos2 or whatever it is called too explicitly.
Re: gdc 12.1: undefined references when linking separately compiled files
On Saturday, 28 May 2022 at 13:12:46 UTC, kdevel wrote:
Any ideas?
ppinsta.d
```
import std.stdio : write, writeln;
import parser; // <- comment this out and gdc links
void main ()
{
string [string] h;
writeln (h);
}
```
parser.d
```
module parser;
import std.regex : regex;
private immutable auto VariableName = regex("^[a-zA-Z]*$");
```
Compile in one go:
```
$ gdc -o ppinsta ppinsta.d parser.d
$ ./ppinsta
[]
```
Compiled separately:
```
$ gdc -c ppinsta.d
$ gdc -c parser.d
$ gdc -o ppinsta ppinsta.o parser.o
ppinsta.o: In function
`_D3std6format8internal5write__T8getWidthTAyaZQoFNaNfQlZl':
ppinsta.d:(.text+0x11ea): undefined reference to
`_D3std9algorithm9searching__T3allSQBg6format8internal5write__T8getWidthTAyaZQoFQhZ9__lambda2Z__TQCpTQBcZQCxMFNaNfQBpZb'
ppinsta.o: In function
`_D3std6format8internal5write__T8getWidthTAaZQnFNaNfQkZl':
ppinsta.d:(.text+0x16ba): undefined reference to
`_D3std9algorithm9searching__T3allSQBg6format8internal5write__T8getWidthTAaZQnFQgZ9__lambda2Z__TQCoTQBbZQCwMFNaNfQBoZb'
ppinsta.o: In function
`_D3std6format8internal5write__T20formatValueImplUlongTSQCb5array__T8AppenderTAyaZQoTaZQCdFNaNfKQBpmIbMKxSQDzQDy4spec__T10FormatSpecTaZQpZv':
ppinsta.d:(.text+0x21d9): undefined reference to
`_D3std9algorithm9searching__T3allSQBg6format8internal5write__T20formatValueImplUlongTSQDg5array__T8AppenderTAyaZQoTaZQCdFKQBlmIbMKxSQFaQDu4spec__T10FormatSpecTaZQpZ10__lambda16Z__TQFvTAaZQGcMFNaNfQmZb'
ppinsta.d:(.text+0x2268): undefined reference to
`_D3std9algorithm9searching__T3allSQBg6format8internal5write__T20formatValueImplUlongTSQDg5array__T8AppenderTAyaZQoTaZQCdFKQBlmIbMKxSQFaQDu4spec__T10FormatSpecTaZQpZ10__lambda17Z__TQFvTAaZQGcMFNaNfQmZb'
ppinsta.o: In function
`_D3std6format8internal5write__T8getWidthTAwZQnFNaNbNiNfQoZl':
ppinsta.d:(.text+0x2996): undefined reference to
`_D3std9algorithm9searching__T3allSQBg6format8internal5write__T8getWidthTAwZQnFQgZ9__lambda2Z__TQCoTQBbZQCwMFNaNbNiNfQBsZb'
collect2: error: ld returned 1 exit status
```
Re: gdc 12.1: undefined references when linking separately compiled files
On Saturday, 28 May 2022 at 14:03:13 UTC, Adam D Ruppe wrote: On Saturday, 28 May 2022 at 13:12:46 UTC, kdevel wrote: gdc -o ppinsta ppinsta.o esah.o evaluate.o jsr.o jsw.o parser.o ptvr.o stack.o testdatagenerator.o You might need to add -lgphobos or -lgphobos2 or whatever it is called too explicitly. gdc -v -o ppinsta ppinsta.o parser.o It says [...]gcc-12.1/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.1.0/collect2 \ [...]ppinsta.o parser.o -Bstatic -lgphobos [...] ^
Re: gdc 12.1: undefined references when linking separately compiled files
On Saturday, 28 May 2022 at 13:55:09 UTC, Tejas wrote: On Saturday, 28 May 2022 at 13:12:46 UTC, kdevel wrote: I am trying to build a project with GDC. It successfully compiles with dmd and ldmd2. When I use gdc in one go the binary is successfully build: [...] Is seperate compilation working successfully for dmd and ldc? dmd: ``` $ dmd -c ppinsta.d $ dmd -c parser.d $ dmd -of=ppinsta ppinsta.o parser.o $ ./ppinsta [] ``` (checking ldc/ldmd2 later) The only bug I know of regarding seperate compilation is https://issues.dlang.org/show_bug.cgi?id=20641
Re: gdc 12.1: undefined references when linking separately compiled files
On Saturday, 28 May 2022 at 14:16:51 UTC, kdevel wrote: $ gdc -o ppinsta ppinsta.d parser.d Compiling together is faster anyway this is prolly what you want most the time. But I know what's going on now, it is the template emission thing, the compiler thinks, since it is from std, it was already compiled somewhere else and skips it but it isn't actually there so the linker errors. Using gdc -fall-instantiations -c parser.d Might generate it in that parser.o getting it to link. Might need to be used in all builds but I *think* just here, hard to say without a test.
Re: gdc 12.1: undefined references when linking separately compiled files
On Saturday, 28 May 2022 at 14:44:56 UTC, Adam D Ruppe wrote: On Saturday, 28 May 2022 at 14:16:51 UTC, kdevel wrote: $ gdc -o ppinsta ppinsta.d parser.d Compiling together is faster anyway this is prolly what you want most the time. But I know what's going on now, it is the template emission thing, the compiler thinks, since it is from std, it was already compiled somewhere else and skips it but it isn't actually there so the linker errors. Using gdc -fall-instantiations -c parser.d $ gdc -fall-instantiations -c ppinsta.d $ gdc -c parser.d $ gdc -o ppinsta ppinsta.o parser.o $ ./ppinsta [] Works. THX!
Re: gdc 12.1: undefined references when linking separately compiled files
On 5/28/22 10:44 AM, Adam D Ruppe wrote: On Saturday, 28 May 2022 at 14:16:51 UTC, kdevel wrote: $ gdc -o ppinsta ppinsta.d parser.d Compiling together is faster anyway this is prolly what you want most the time. But I know what's going on now, it is the template emission thing, the compiler thinks, since it is from std, it was already compiled somewhere else and skips it but it isn't actually there so the linker errors. It should only think that if it sees it instantiated. If it's instatiated in std, it should be included in the built phobos library. If it's not instantiated in std, then the compiler should be putting it inside the object file. Is this specific to gdc, or does it happen for other compilers as well? -Steve
Re: gdc 12.1: undefined references when linking separately compiled files
On Saturday, 28 May 2022 at 14:37:07 UTC, kdevel wrote: dmd: ``` $ dmd -c ppinsta.d $ dmd -c parser.d $ dmd -of=ppinsta ppinsta.o parser.o $ ./ppinsta [] ``` (checking ldc/ldmd2 later) ``` $ ldc2 -c ppinsta.d && ldc2 -c parser.d && ldc2 -of=ppinsta ppinsta.o parser.o && ./ppinsta [] $ ldmd2 -c ppinsta.d && ldmd2 -c parser.d && ldmd2 -of=ppinsta ppinsta.o parser.o && ./ppinsta [] ``` Both okay.
Re: gdc 12.1: undefined references when linking separately compiled files
On Saturday, 28 May 2022 at 15:10:25 UTC, Steven Schveighoffer wrote: [...] Is this specific to gdc, or does it happen for other compilers as well? The former.
Re: gdc 12.1: undefined references when linking separately compiled files
On Saturday, 28 May 2022 at 22:23:34 UTC, kdevel wrote: On Saturday, 28 May 2022 at 15:10:25 UTC, Steven Schveighoffer wrote: [...] Is this specific to gdc, or does it happen for other compilers as well? The former. Please check the dlang versions of all compilers. The template emission scheme is changing quite often between versions, indeed leading to linking problems with separate compilation and complex template instantiation trees (one of the main compiler upgrade issues at Weka, with LDC). -Johan
Re: gdc 12.1: undefined references when linking separately compiled files
On Saturday, 28 May 2022 at 14:44:56 UTC, Adam D Ruppe wrote:
On Saturday, 28 May 2022 at 14:16:51 UTC, kdevel wrote:
$ gdc -o ppinsta ppinsta.d parser.d
Compiling together is faster anyway this is prolly what you
want most the time.
But I know what's going on now, it is the template emission
thing, the compiler thinks, since it is from std, it was
already compiled somewhere else and skips it but it isn't
actually there so the linker errors.
Using
gdc -fall-instantiations -c parser.d
Might generate it in that parser.o getting it to link. Might
need to be used in all builds but I *think* just here, hard to
say without a test.
I just encountered this problem in recently released debian
bookworm (gdc 12.2.0), I was able to fix these undefined lambdas
inside std library with -fall-instantiations, and a bunch of
other undefined lambdas in my own code by changing template
arguments of the form
alias e = (a => a)
to a separate definition
auto (T)default_e(T a)
{
return a;
}
and
alias e = default_e
Re: gdc 12.1: undefined references when linking separately compiled files
On Thursday, 6 July 2023 at 22:44:27 UTC, Alexibu wrote:
I just encountered this problem in recently released debian
bookworm (gdc 12.2.0), I was able to fix these undefined
lambdas inside std library with -fall-instantiations, and a
bunch of other undefined lambdas in my own code by changing
template arguments of the form
alias e = (a => a)
to a separate definition
auto (T)default_e(T a)
{
return a;
}
and
alias e = default_e
Using GDC may require rewrite?
I have thought GDC use the same front-end as DMD & LDC?
dmd 2.099 regression: unittest -checkaction=context and import std.regex cause lots of undefined references
zstack.d:
```
module zstack;
import std.stdio: writeln;
void bar (int [] i)
{
writeln ("i: ", i);
}
unittest {
int [] arr;
bar (arr);
}
```
zrepo.d:
```
module parser;
import std.regex;
import zstack;
```
```
$ dmd -g -i -unittest -checkaction=context -main -run zrepro
2>&1 | ddemangle
```
gives
```
zrepro.o: In function `pure nothrow @nogc @safe immutable(char)[]
core.internal.dassert._d_assert_fail!(int)._d_assert_fail(scope
const(immutable(char)[]), const(int))':
[...]/dmd2/linux/bin64/../../src/druntime/import/core/internal/dassert.d:41:
undefined reference to `pure nothrow @nogc @safe bool
core.internal.dassert.inFinalizer!().inFinalizer()'
zrepro.o: In function `pure nothrow @nogc @safe uint
std.uni.sliceBits!(0uL,
8uL).sliceBits.opCall!(dchar).opCall(dchar)':
[...]/dmd2/linux/bin64/../../src/phobos/std/uni/package.d:5593:
undefined reference to `pure nothrow @nogc @safe
immutable(char)[]
core.internal.dassert._d_assert_fail!(const(uint))._d_assert_fail!(int)._d_assert_fail(scope const(immutable(char)[]), ref const(uint), const(int))'
zrepro.o: In function `pure nothrow @nogc @safe immutable(char)[]
core.internal.dassert._d_assert_fail!(bool)._d_assert_fail(scope
const(immutable(char)[]), ref const(bool))':
[...]/dmd2/linux/bin64/../../src/druntime/import/core/internal/dassert.d:41:
undefined reference to `pure nothrow @nogc @safe bool
core.internal.dassert.inFinalizer!().inFinalizer()'
zrepro.o: In function `pure nothrow @nogc @safe uint
std.uni.sliceBits!(13uL,
21uL).sliceBits.opCall!(dchar).opCall(dchar)':
[...]/dmd2/linux/bin64/../../src/phobos/std/uni/package.d:5593:
undefined reference to `pure nothrow @nogc @safe
immutable(char)[]
core.internal.dassert._d_assert_fail!(const(uint))._d_assert_fail!(int)._d_assert_fail(scope const(immutable(char)[]), ref const(uint), const(int))'
zrepro.o: In function `pure nothrow @nogc @safe uint
std.uni.sliceBits!(8uL,
13uL).sliceBits.opCall!(dchar).opCall(dchar)':
[...]/dmd2/linux/bin64/../../src/phobos/std/uni/package.d:5593:
undefined reference to `pure nothrow @nogc @safe
immutable(char)[]
core.internal.dassert._d_assert_fail!(const(uint))._d_assert_fail!(int)._d_assert_fail(scope const(immutable(char)[]), ref const(uint), const(int))'
zrepro.o: In function `pure nothrow @nogc @safe immutable(char)[]
core.internal.dassert._d_assert_fail!(ulong)._d_assert_fail!(ulong)._d_assert_fail(scope const(immutable(char)[]), ref const(ulong), const(ulong))':
[...]/dmd2/linux/bin64/../../src/druntime/import/core/internal/dassert.d:70:
undefined reference to `pure nothrow @nogc @safe bool
core.internal.dassert.inFinalizer!().inFinalizer()'
[...]/dmd2/linux/bin64/../../src/druntime/import/core/internal/dassert.d:75:
undefined reference to `pure nothrow @nogc @safe immutable(char)[]
core.internal.dassert.miniFormatFakeAttributes!(ulong).miniFormatFakeAttributes(ref
const(ulong))'
[...]/dmd2/linux/bin64/../../src/druntime/import/core/internal/dassert.d:77:
undefined reference to `pure nothrow @nogc @safe immutable(char)[]
core.internal.dassert.miniFormatFakeAttributes!(ulong).miniFormatFakeAttributes(ref
const(ulong))'
zrepro.o: In function `pure nothrow @nogc @safe immutable(char)[]
core.internal.dassert._d_assert_fail!(ulong)._d_assert_fail!(int)._d_assert_fail(scope const(immutable(char)[]), ref const(ulong), const(int))':
[...]/dmd2/linux/bin64/../../src/druntime/import/core/internal/dassert.d:70:
undefined reference to `pure nothrow @nogc @safe bool
core.internal.dassert.inFinalizer!().inFinalizer()'
[...]/dmd2/linux/bin64/../../src/druntime/import/core/internal/dassert.d:75:
undefined reference to `pure nothrow @nogc @safe immutable(char)[]
core.internal.dassert.miniFormatFakeAttributes!(ulong).miniFormatFakeAttributes(ref
const(ulong))'
zrepro.o: In function `pure nothrow @nogc @safe immutable(char)[]
core.internal.dassert._d_assert_fail!(ulong)._d_assert_fail!(ulong)._d_assert_fail(scope const(immutable(char)[]), ref const(ulong), ref const(ulong))':
[...]/dmd2/linux/bin64/../../src/druntime/import/core/internal/dassert.d:70:
undefined reference to `pure nothrow @nogc @safe bool
core.internal.dassert.inFinalizer!().inFinalizer()'
[...]/dmd2/linux/bin64/../../src/druntime/import/core/internal/dassert.d:75:
undefined reference to `pure nothrow @nogc @safe immutable(char)[]
core.internal.dassert.miniFormatFakeAttributes!(ulong).miniFormatFakeAttributes(ref
const(ulong))'
[...]/dmd2/linux/bin64/../../src/druntime/import/core/internal/dassert.d:77:
undefined reference to `pure nothrow @nogc @safe immutable(char)[]
core.internal.dassert.miniFormatFakeAttributes!(ulong).miniFormatFakeAttributes(ref
const(ulong))'
collect2: ld returned 1 exit status
Error: linker exited with status 1
```
If ```import std.regex;``` is commented out or if
```-checkaction=context``` is removed from the cmd line the
unittest passes. Can anybody reproduce this?
Re: dmd 2.099 regression: unittest -checkaction=context and import std.regex cause lots of undefined references
On Thursday, 17 March 2022 at 14:00:45 UTC, kdevel wrote: If ```import std.regex;``` is commented out or if ```-checkaction=context``` is removed from the cmd line the unittest passes. Can anybody reproduce this? https://run.dlang.io/is/GYDUBz File an issue, I'd say. The worst thing that can happen is that someone flags it as a duplicate.
Re: dmd 2.099 regression: unittest -checkaction=context and import std.regex cause lots of undefined references
On Friday, 18 March 2022 at 19:42:02 UTC, Anonymouse wrote: On Thursday, 17 March 2022 at 14:00:45 UTC, kdevel wrote: If ```import std.regex;``` is commented out or if ```-checkaction=context``` is removed from the cmd line the unittest passes. Can anybody reproduce this? https://run.dlang.io/is/GYDUBz File an issue, I'd say. The worst thing that can happen is that someone flags it as a duplicate. Issue 22902 - dmd 2.099 regression: unittest -checkaction=context and import std.regex causes link error (edit) https://issues.dlang.org/show_bug.cgi?id=22902
Re: dmd 2.099 regression: unittest -checkaction=context and import std.regex cause lots of undefined references
On Saturday, 28 May 2022 at 23:02:45 UTC, kdevel wrote: On Friday, 18 March 2022 at 19:42:02 UTC, Anonymouse wrote: On Thursday, 17 March 2022 at 14:00:45 UTC, kdevel wrote: If ```import std.regex;``` is commented out or if ```-checkaction=context``` is removed from the cmd line the unittest passes. Can anybody reproduce this? https://run.dlang.io/is/GYDUBz File an issue, I'd say. The worst thing that can happen is that someone flags it as a duplicate. Issue 22902 - dmd 2.099 regression: unittest -checkaction=context and import std.regex causes link error (edit) https://issues.dlang.org/show_bug.cgi?id=22902 Just came here to say I hit the same bug, here's my import list: ```d import std.typecons : Tuple; import std.container : Array; import std.format : format; import std.stdio; import std.file; import std.conv; import std.outbuffer; import core.stdc.stdio; import core.stdc.stdint; import core.sys.posix.fcntl; import core.sys.posix.unistd; ```
Re: dmd 2.099 regression: unittest -checkaction=context and import std.regex cause lots of undefined references
On Monday, 14 November 2022 at 17:08:38 UTC, Gavin Ray wrote: Just came here to say I hit the same bug, here's my import list: * https://issues.dlang.org/show_bug.cgi?id=19937 object._d_assert_fail linker error if compiling with -checkaction=context * https://issues.dlang.org/show_bug.cgi?id=22374 [REG 2.093] 'import std;' with -checkaction=context causes link error * https://issues.dlang.org/show_bug.cgi?id=22902 dmd 2.099 regression: unittest -checkaction=context and import std.regex causes link error Does `dmd -allinst ...` help in your case?
Re: dmd 2.099 regression: unittest -checkaction=context and import std.regex cause lots of undefined references
On Monday, 14 November 2022 at 20:37:12 UTC, kdevel wrote: On Monday, 14 November 2022 at 17:08:38 UTC, Gavin Ray wrote: Just came here to say I hit the same bug, here's my import list: * https://issues.dlang.org/show_bug.cgi?id=19937 object._d_assert_fail linker error if compiling with -checkaction=context * https://issues.dlang.org/show_bug.cgi?id=22374 [REG 2.093] 'import std;' with -checkaction=context causes link error * https://issues.dlang.org/show_bug.cgi?id=22902 dmd 2.099 regression: unittest -checkaction=context and import std.regex causes link error Does `dmd -allinst ...` help in your case? Hey, it does actually, thanks a bunch!
