[SF][VM][UNIX] VM 2.8a Some work to do... [was: Re: Serial port code in Unix?]

Stephan Rudlof sr at evolgo.de
Mon Jul 10 23:22:48 UTC 2000


Dear VM-Hackers!

Ned has detected missing parts in the Unix port at SourceForge. I'm not
able to check for all potential problems/features/missingFeatures.

See this as a good chance to
- become familiar with SF;
- remove some not workable Plugins (if you are sure, that they don't
work, because of missing platform specific stuff);
- supply some missing code to SF, which exists at another location;
- implement some code, which you want to have.

Greetings,

Stephan

Ned Konz wrote:
> 
> Stephan Rudlof wrote:
> > > I'm eventually going to need SerialPort capability, but didn't want to
> > > write something that someone else had already written.
> > >
> > > Also, I'm likely to only write the Linux version if I do write it,
> > > because
> > > I only have Linux.
> > >
> > > Had you or someone else planned to do the SerialPort stuff soon?
> >
> > Not me. Probably you should post this question to the list after looking
> > into the current port, for what's in there now.
> 
> Well, I'm confused. The 2.8a sources I had had a
> sqUnixSerialAndMIDIPort.c
> file in them, but your newest ones don't even have that file.

I have used Tims sources, where do your's come from?

> So how
> does
> the SerialPlugin even compile without routines like serialPortOpen(),
> etc.?

I just have generated *all* plugins from Squeak and checked for
compilability, *not* for functionality.
The AsynchFilePlugin was not compilable, so it's sources are missing in
the port.

But there remain some other not working ones, as you have detected now.

<snipped>
 
> But JoystickTabletPlugin.so, MIDIPlugin.so, and SerialPlugin.so are
> still
> being compiled. How does that work?

Obbiously it's not necessary to resolve all externals at compile time.

> And what happens when routines in
> them
> get invoked when they have unresolved externals?

Good question! I have tried
	SerialPort new openPort: 0
, which results in a primitiveFailed and then inspected
	Smalltalk listLoadedModules
; the SocketPlugin wasn't shown there!

Loading of the shared library SocketPlugin.so fails, because the missing
externals have to be resolved at this time (not at compile time before).

In sqUnixExternalPrims.c there dlopen is called with the flag RTLD_NOW,
which forces exactly this behaviour.

>From the man page of dlopen()
...
       flag must be either RTLD_LAZY, meaning  resolve  undefined
       symbols  as  code from the dynamic library is executed, or
       RTLD_NOW, meaning resolve  all  undefined  symbols  before
       dlopen  returns, and fail if this cannot be done.  Option­
       ally, RTLD_GLOBAL may be or'ed with flag,  in  which  case
       the  external  symbols defined in the library will be made
       available to subsequently loaded libraries.
...

> My impression was that previously the plugin.c code would be linked with
> whatever platform-specific code was necessary to resolve externals. But
> now
> I don't see that??
> 
> Oh well...
> 
> So what do I have to do to add the serial port routines that I write (if
> I
> choose to do so)?

You have to add sqUnixSerialAndMIDIPort.c into src/ and make it
compilable (possibly by changing some other files, too.
If you have an developer account at SF and have read some docs, you
should put it into SF yourself, if it works.
This would be the best way to do, especially if you develop more than
once for the platform specific parts of the VM.

The other variant would be to post it to the list as [FIX] and let other
VM developers do the SF upload.

Greetings,

Stephan

> 
> --
> Ned Konz
> currently: Stanwood, WA
> email:     ned at bike-nomad.com
> homepage:  http://bike-nomad.com

-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3





More information about the Squeak-dev mailing list