www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Weird OSX issue

reply Steven Schveighoffer <schveiguy yahoo.com> writes:
OK, so I think I found a bug, but I have no idea how to "reproduce" it. 
It seems to be dependent on environment.


weirdness. All versions are 2.067, and I did use dmd -v to make sure 
rogue dmd.conf or library files are not playing any role, and that the 
files I compare below are being used. Please help figure this out :)



Stevens-MacBook-Pro:teststatic steves$ type dmd
dmd is hashed (/usr/bin/dmd)



Stevens-MacBook-Pro:teststatic steves$ cmp /usr/bin/dmd 
~/Downloads/dmd2/osx/bin/dmd
Stevens-MacBook-Pro:teststatic steves$ cmp 
/usr/share/dmd/lib/libphobos2.a ~/Downloads/dmd2/osx/lib/libphobos2.a


Stevens-MacBook-Pro:teststatic steves$ diff 
/usr/share/dmd/src/phobos/std/concurrency.d 
~/Downloads/dmd2/src/phobos/std/concurrency.d


Stevens-MacBook-Pro:teststatic steves$ diff 
/usr/share/dmd/src/druntime/import/core/thread.d 
~/Downloads/dmd2/src/druntime/import/core/thread.d



Stevens-MacBook-Pro:teststatic steves$ cat mod1.d
module mod1;
import std.concurrency;
import std.stdio;

__gshared static int foo;

void main()
{
     auto tid = spawn((Tid o){foo = 5; o.send(true);}, thisTid);
     receiveOnly!bool();
     writeln(foo);
}


Stevens-MacBook-Pro:teststatic steves$ dmd mod1.d
Undefined symbols for architecture x86_64:
   "_D4core6thread6Thread5startMFZv", referenced from:
 
_D3std11concurrency61__T6_spawnTPFS3std11concurrency3TidZvTS3std11concurrency3TidZ6_spawnFbPFS3std11concurrency3TidZvS3std11concurrency3TidZS3
td11concurrency3Tid 
in mod1.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see 
invocation)
--- errorlevel 1




Stevens-MacBook-Pro:teststatic steves$ nm mod1.o | grep core6thread6Thread5
                  U _D4core6thread6Thread5startMFZv


Stevens-MacBook-Pro:teststatic steves$ ~/Downloads/dmd2/osx/bin/dmd mod1.d



Stevens-MacBook-Pro:teststatic steves$ nm mod1.o | grep core6thread6Thread5
                  U _D4core6thread6Thread5startMFNbZC4core6thread6Thread

So am I going crazy? Or is dmd doing things differently depending on 
where its environment is? Any compiler gurus out there understand why 
the symbol is different?

I don't want to file a bug with this, because it seems dependent on 
installation location, would possibly not be reproducible.

-Steve
Apr 24 2015
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-04-24 20:37, Steven Schveighoffer wrote:


 So am I going crazy? Or is dmd doing things differently depending on
 where its environment is? Any compiler gurus out there understand why
 the symbol is different?

 I don't want to file a bug with this, because it seems dependent on
 installation location, would possibly not be reproducible.


I can't reproduce this with DMD from DVM (compiler is installed in the 
user home directory).

-- 
/Jacob Carlborg
Apr 24 2015
parent reply Dan Olson <zans.is.for.cans yahoo.com> writes:
Jacob Carlborg <doob me.com> writes:


 On 2015-04-24 20:37, Steven Schveighoffer wrote:


 So am I going crazy? Or is dmd doing things differently depending on
 where its environment is? Any compiler gurus out there understand why
 the symbol is different?

 I don't want to file a bug with this, because it seems dependent on
 installation location, would possibly not be reproducible.


 I can't reproduce this with DMD from DVM (compiler is installed in the
 user home directory).


I have lots of version laying around and they all worked fine on the
posted code.

But maybe a clue here...

$ ~/dmd2.066.0/osx/bin/dmd mod1.d
$ nm mod1.o | grep start
                 U _D4core6thread6Thread5startMFZv
$ dmd mod1.d
$ nm mod1.o | grep start
                 U _D4core6thread6Thread5startMFNbZC4core6thread6Thread

--- a/src/core/thread.d
+++ b/src/core/thread.d
   -587,7 +587,7    class Thread
      * Throws:
      *  ThreadException if the thread fails to start.
      */
-    final Thread start()
+    final Thread start() nothrow
     in
     {
         assert( !next && !prev );

I wonder if dmd -v will show where its picking up stuff.
Apr 25 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/25/15 3:07 AM, Dan Olson wrote:

 Jacob Carlborg <doob me.com> writes:


 On 2015-04-24 20:37, Steven Schveighoffer wrote:


 So am I going crazy? Or is dmd doing things differently depending on
 where its environment is? Any compiler gurus out there understand why
 the symbol is different?

 I don't want to file a bug with this, because it seems dependent on
 installation location, would possibly not be reproducible.


 I can't reproduce this with DMD from DVM (compiler is installed in the
 user home directory).


 I have lots of version laying around and they all worked fine on the
 posted code.

 But maybe a clue here...

 $ ~/dmd2.066.0/osx/bin/dmd mod1.d
 $ nm mod1.o | grep start
                   U _D4core6thread6Thread5startMFZv
 $ dmd mod1.d
 $ nm mod1.o | grep start
                   U _D4core6thread6Thread5startMFNbZC4core6thread6Thread

 --- a/src/core/thread.d
 +++ b/src/core/thread.d
    -587,7 +587,7    class Thread
        * Throws:
        *  ThreadException if the thread fails to start.
        */
 -    final Thread start()
 +    final Thread start() nothrow
       in
       {
           assert( !next && !prev );

 I wonder if dmd -v will show where its picking up stuff.


Thank you. It is something I missed. Lo and behold:

dmd -v mod1.d:

...

import    core.thread	(/usr/share/dmd/src/druntime/import/core/thread.di)

...

~/Downloads/dmd2/osx/bin/dmd -v mod1.d:

...

import    core.thread 
(/Users/steves/Downloads/dmd2/osx/bin/../../src/druntime/import/core/thread.d)

...

Hm... thread.di vs thread.d (and I didn't notice before because all the 
other imports were .d, I just glanced over that detail).

And so, let's see here:

ls -l /usr/share/dmd/src/druntime/import/core/thread.*

-rw-rw-r--   1 steves  staff  157781 Mar 24 10:44 thread.d
-rw-rw-r--+  1 steves  staff   31382 Feb 24  2014 thread.di

Hey, looky there :)

So, looking at time machine (love that feature), I found that when I 
installed 2.066, back in October, we had switched to using thread.d 
instead of thread.di. But the installer did not erase the old thread.di.

BTW, found this: https://github.com/D-Programming-Language/druntime/pull/865

So I think the issue here is that the pkg installer on OSX does not 
clean up the target directory if it already exists (or at least 
purposely remove thread.di). Will look into fixing that. At least now, 
it works properly, thanks (did a rm -rf /usr/share/dmd and reinstall).

-Steve
Apr 27 2015
next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/27/15 9:54 AM, Steven Schveighoffer wrote:


 So I think the issue here is that the pkg installer on OSX does not
 clean up the target directory if it already exists (or at least
 purposely remove thread.di). Will look into fixing that. At least now,
 it works properly, thanks (did a rm -rf /usr/share/dmd and reinstall).


Looked into this further, I added a line to the post install to remove 
thread.di. However, when attempting to duplicate by installing 2.065 
first, and then 2.067 over the top, it appears that installing over an 
old version doesn't actually leave thread.di behind. I think possibly 
this happened because I got a new mac and copied the files from my old 
mac, but I don't think this would be a normal cause for concern.

I do still think a pre-install script of rm -rf /usr/share/dmd would be 
better. But I don't know if it's warranted.

-Steve
May 11 2015
prev sibling parent "Chris" <wendlec tcd.ie> writes:
On Monday, 27 April 2015 at 13:54:42 UTC, Steven Schveighoffer
wrote:

 On 4/25/15 3:07 AM, Dan Olson wrote:

 Jacob Carlborg <doob me.com> writes:


 On 2015-04-24 20:37, Steven Schveighoffer wrote:


 So am I going crazy? Or is dmd doing things differently 
 depending on
 where its environment is? Any compiler gurus out there 
 understand why
 the symbol is different?

 I don't want to file a bug with this, because it seems 
 dependent on
 installation location, would possibly not be reproducible.


 I can't reproduce this with DMD from DVM (compiler is 
 installed in the
 user home directory).


 I have lots of version laying around and they all worked fine 
 on the
 posted code.

 But maybe a clue here...

 $ ~/dmd2.066.0/osx/bin/dmd mod1.d
 $ nm mod1.o | grep start
                  U _D4core6thread6Thread5startMFZv
 $ dmd mod1.d
 $ nm mod1.o | grep start
                  U 
 _D4core6thread6Thread5startMFNbZC4core6thread6Thread

 --- a/src/core/thread.d
 +++ b/src/core/thread.d
    -587,7 +587,7    class Thread
       * Throws:
       *  ThreadException if the thread fails to start.
       */
 -    final Thread start()
 +    final Thread start() nothrow
      in
      {
          assert( !next && !prev );

 I wonder if dmd -v will show where its picking up stuff.


 Thank you. It is something I missed. Lo and behold:

 dmd -v mod1.d:

 ...

 import    
 core.thread	(/usr/share/dmd/src/druntime/import/core/thread.di)

 ...

 ~/Downloads/dmd2/osx/bin/dmd -v mod1.d:

 ...

 import    core.thread 
 (/Users/steves/Downloads/dmd2/osx/bin/../../src/druntime/import/core/thread.d)

 ...

 Hm... thread.di vs thread.d (and I didn't notice before because 
 all the other imports were .d, I just glanced over that detail).

 And so, let's see here:

 ls -l /usr/share/dmd/src/druntime/import/core/thread.*

 -rw-rw-r--   1 steves  staff  157781 Mar 24 10:44 thread.d
 -rw-rw-r--+  1 steves  staff   31382 Feb 24  2014 thread.di

 Hey, looky there :)

 So, looking at time machine (love that feature), I found that 
 when I installed 2.066, back in October, we had switched to 
 using thread.d instead of thread.di. But the installer did not 
 erase the old thread.di.

 BTW, found this: 
 https://github.com/D-Programming-Language/druntime/pull/865

 So I think the issue here is that the pkg installer on OSX does 
 not clean up the target directory if it already exists (or at 
 least purposely remove thread.di). Will look into fixing that. 
 At least now, it works properly, thanks (did a rm -rf 
 /usr/share/dmd and reinstall).

 -Steve


Now that you mention it, I had similar issues on my Linux distro
at work (Ubuntu, alas!). The installer for 2.067.0 (or 2.066.0?)
didn't erase old files and I got compiler errors for no apparent
reason. What I did was to use dvm to install and manage my dmd
versions. This is much cleaner. I just didn't have the patience
to go through all the /dmd/ directories and clean them up.

dvm installs its own copy, it's not a system wide installation,
so you never have any issues with old files. I wouldn't want to
miss it now.

dvm install 2.067.1

later in your shell you just type

dvm use 2.067.1

https://github.com/jacob-carlborg/dvm
May 12 2015
prev sibling parent "Kagamin" <spam here.lot> writes:
On Friday, 24 April 2015 at 18:37:40 UTC, Steven Schveighoffer 
wrote:

 _D4core6thread6Thread5startMFZv
 _D4core6thread6Thread5startMFNbZC4core6thread6Thread


Maybe it will be better understandable if you demangle these 
symbols?
Apr 27 2015