I have defined the following module:

/**
 * Module containing unit test helper functions for date time operations.
 */
module common.test.unit.datetime;

/**
 * Imports.
 */
import std.conv;
import std.datetime;

/**
 * Return a unix timestamp.
 *
 * Params:
 *     T = The return type of the unix timestamp.
 *     A = Variadic argument type for args parameter.
 *     args = Time arguments as specified by the DateTime struct.
 *
 * Reference:
 *     $(LINK http://dlang.org/phobos/std_datetime.html#.DateTime)
 */
T getUnixTime(T, A...)(A args)
{
	return to!T(SysTime(DateTime(args)).toUnixTime());
}

But when i import it and use the getUnixTime function i get the following linker error:

Undefined symbols for architecture x86_64:
  "_D6common4test4unit8datetime12__ModuleInfoZ", referenced from:
      _D5logic25generalstatisticprocessor12__ModuleInfoZ in main.o
      _D5logic14eventprocessor12__ModuleInfoZ in main.o
      _D5logic24devicestatisticprocessor12__ModuleInfoZ in main.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status

Any idea why this is? If i comment out the getUnixTime function and put in other code it seems to import and work ok. Is it anything to do with the way i've written the function?

On 2013-08-14 15:21, Gary Willoughby wrote:
> I have defined the following module:
>
> /**
>   * Module containing unit test helper functions for date time operations.
>   */
> module common.test.unit.datetime;
>
> /**
>   * Imports.
>   */
> import std.conv;
> import std.datetime;
>
> /**
>   * Return a unix timestamp.
>   *
>   * Params:
>   *     T = The return type of the unix timestamp.
>   *     A = Variadic argument type for args parameter.
>   *     args = Time arguments as specified by the DateTime struct.
>   *
>   * Reference:
>   *     $(LINK http://dlang.org/phobos/std_datetime.html#.DateTime)
>   */
> T getUnixTime(T, A...)(A args)
> {
>      return to!T(SysTime(DateTime(args)).toUnixTime());
> }
>
> But when i import it and use the getUnixTime function i get the
> following linker error:
>
> Undefined symbols for architecture x86_64:
>    "_D6common4test4unit8datetime12__ModuleInfoZ", referenced from:
>        _D5logic25generalstatisticprocessor12__ModuleInfoZ in main.o
>        _D5logic14eventprocessor12__ModuleInfoZ in main.o
>        _D5logic24devicestatisticprocessor12__ModuleInfoZ in main.o
> ld: symbol(s) not found for architecture x86_64
> collect2: ld returned 1 exit status
>
> Any idea why this is? If i comment out the getUnixTime function and put
> in other code it seems to import and work ok. Is it anything to do with
> the way i've written the function?

Have you compiled all the files? Show us the command you use to compile your code. Usually this is enough "rdmd main.d", where "main.d" is the file containing the main function.

-- 
/Jacob Carlborg

On Wednesday, 14 August 2013 at 14:05:07 UTC, Jacob Carlborg wrote:
> Have you compiled all the files? Show us the command you use to compile your code. Usually this is enough "rdmd main.d", where "main.d" is the file containing the main function.

I'm sure all source files are compiled during the build and this is the only import giving me problems. Like i said before if i comment out that function everything seems to work. If i import the above module into another project i get the same issue. It's weird.

Compiler command:

rdmd --force -D -Dd../docs -de -debug -I~/Projects/shared/d -m64 -property -unittest -w main.d

On Wednesday, 14 August 2013 at 16:11:38 UTC, Gary Willoughby wrote:
> ...

Hm, I remember I had similar issue once which faded away once I have stopped naming main module as `main`. Was not able to track exact conditions to trigger it - this may be something similar.

I don't have an answer, but in case you are not familiar with cryptic linker:

On Wednesday, 14 August 2013 at 13:21:49 UTC, Gary Willoughby wrote:
> But when i import it and use the getUnixTime function i get the following linker error:
>
> Undefined symbols for architecture x86_64:

The linker is complaining specifically about 64bit, this likely means it found this symbol in 32bit.

>   "_D6common4test4unit8datetime12__ModuleInfoZ", referenced from:

It is looking for a unit test within datetime.

>       _D5logic25generalstatisticprocessor12__ModuleInfoZ in main.o
>       _D5logic14eventprocessor12__ModuleInfoZ in main.o
>       _D5logic24devicestatisticprocessor12__ModuleInfoZ in main.o
> ld: symbol(s) not found for architecture x86_64
> collect2: ld returned 1 exit status

Repeating original complaint.

I would expect removing -unittest from the command line will fix this error. But I don't know why it is trying to pull in Phobos unittests.

On 2013-08-15 20:54, Jesse Phillips wrote:
> I don't have an answer, but in case you are not familiar with cryptic
> linker:
>
> On Wednesday, 14 August 2013 at 13:21:49 UTC, Gary Willoughby wrote:
>> But when i import it and use the getUnixTime function i get the
>> following linker error:
>>
>> Undefined symbols for architecture x86_64:
>
> The linker is complaining specifically about 64bit, this likely means it
> found this symbol in 32bit.

No, I don't think so. At least on Mac OS X it always tell you the architecture:

void foo();

void main ()
{
    foo();
}

Undefined symbols for architecture x86_64:
  "_D4main3fooFZv", referenced from:
      __Dmain in main.d.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status

-- 
/Jacob Carlborg

On Thursday, 15 August 2013 at 18:54:40 UTC, Jesse Phillips wrote:
> I don't have an answer, but in case you are not familiar with cryptic linker:
>
> On Wednesday, 14 August 2013 at 13:21:49 UTC, Gary Willoughby wrote:
>> But when i import it and use the getUnixTime function i get the following linker error:
>>
>> Undefined symbols for architecture x86_64:
>
> The linker is complaining specifically about 64bit, this likely means it found this symbol in 32bit.
>
>>  "_D6common4test4unit8datetime12__ModuleInfoZ", referenced from:
>
> It is looking for a unit test within datetime.
>
>>      _D5logic25generalstatisticprocessor12__ModuleInfoZ in main.o
>>      _D5logic14eventprocessor12__ModuleInfoZ in main.o
>>      _D5logic24devicestatisticprocessor12__ModuleInfoZ in main.o
>> ld: symbol(s) not found for architecture x86_64
>> collect2: ld returned 1 exit status
>
> Repeating original complaint.
>
> I would expect removing -unittest from the command line will fix this error. But I don't know why it is trying to pull in Phobos unittests.

You might be onto something here as i only import this module into unit tests. When i get time i'll investigate a little further.

On Friday, 16 August 2013 at 06:39:42 UTC, Jacob Carlborg wrote:
> No, I don't think so. At least on Mac OS X it always tell you the architecture:
>
> void foo();
>
> void main ()
> {
>     foo();
> }
>
> Undefined symbols for architecture x86_64:
>   "_D4main3fooFZv", referenced from:
>       __Dmain in main.d.o
> ld: symbol(s) not found for architecture x86_64
> collect2: ld returned 1 exit status

Well, I've only seen the architecture mentioned when it couldn't find a library with the of the matching arch, guess I applied that wrong.

On Friday, 16 August 2013 at 09:52:53 UTC, Gary Willoughby wrote:
> You might be onto something here as i only import this module into unit tests. When i get time i'll investigate a little further.

If i take the import out of the unit test and place it at the top of my source file everything works as expected. This is really odd. It only fails if the import is placed inside a unit test.

On Tuesday, 10 September 2013 at 10:42:44 UTC, Gary Willoughby wrote:
> On Friday, 16 August 2013 at 09:52:53 UTC, Gary Willoughby wrote:
>> You might be onto something here as i only import this module into unit tests. When i get time i'll investigate a little further.
>
> If i take the import out of the unit test and place it at the top of my source file everything works as expected. This is really odd. It only fails if the import is placed inside a unit test.

I can't narrow it down anymore so probably not enough information for a bug report. But as i mentioned before it only occurred if i imported the module into a unit test not the module itself.

I've since renamed the function *and* renamed the file (renaming the file alone had no effect) and it now imports with no error at all when imported within a unit test. Very strange.