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.
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
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.
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 __gshareds 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
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
