FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Linux Linking issues
Goto page 1, 2, 3, 4  Next
 
Post new topic   Reply to topic     Forum Index -> Mango
View previous topic :: View next topic  
Author Message
brad
Site Admin


Joined: 22 Feb 2004
Posts: 490
Location: Atlanta, GA USA

PostPosted: Sun Apr 11, 2004 12:08 am    Post subject: Linux Linking issues Reply with quote

Here's my makefile for Beta 2:

Code:

# Designed to work with GNU make
# Targets:
#
#   make unittest
#      Build dsc.io package, and create dsc/obj/dsc
# Notes:
#   (old note for Win32: This relies on LIB.EXE 8.00 or later, and MAKE.EXE 5.01 or later.)
#   don't know if we need to do anything about these version constraints in Linux

DMD=dmd
CC=gcc

DFLAGS=-version=linux
LIB=-lphobos -lpthread

OBJ=dsc/obj/
DSC=dsc/
IO=dsc/io/
IOMODEL=dsc/io/model/
SERVER=dsc/server/
SERVERMODEL=dsc/server/model/
SERVERUTILS=dsc/server/utils/
HTTP=dsc/server/http/
HTTPMODEL=dsc/server/http/model/
SERVLET=dsc/servlet/
SERVLETMODEL=dsc/servlet/model/
UTILS=dsc/utils/
JETTY=dsc/utils/jetty/

COMPILE=$(DMD) -c $(DFLAGS) -od$(OBJ) $**  # GNU make didn't like this... $** maybe?

.obj.d :
   $(COMPILE)


SRC= \
   $(IOMODEL)IBuffer.d \
   $(IOMODEL)IConduit.d \
   $(IOMODEL)IReader.d \
   $(IOMODEL)IWriter.d \
   $(IOMODEL)ISerializable.d \
   $(IO)Exception.d \
   $(IO)FileStyle.d \
   $(IO)FilePath.d \
   $(IO)ConduitStyle.d \
   $(IO)Conduit.d \
   $(IO)Buffer.d \
   $(IO)Resource.d \
   $(IO)FileSystem.d \
   $(IO)FileConduit.d \
   $(IO)FileProxy.d \
   $(IO)EndianReader.d \
   $(IO)EndianWriter.d \
   $(IO)Tokenizer.d \
   $(IO)Token.d \
   $(IO)Printf.d \
   $(IO)TextWriter.d \
   $(IO)TextReader.d \
   $(IO)DisplayWriter.d \
   $(IO)ColumnWriter.d \
   $(IO)Stdio.d \
   $(IO)Reader.d \
   $(IO)Writer.d \
   $(IO)System.d \
   $(IO)Socket.d \
   $(IO)CompositeReader.d \
   $(IO)CompositeWriter.d \
   $(SERVERUTILS)Dictionary.d \
   $(SERVERUTILS)TokenStack.d \
   $(SERVERUTILS)Uri.d \
   $(SERVERUTILS)Utils.d \
   $(SERVERMODEL)IServer.d \
   $(SERVER)AbstractServer.d \
   $(SERVER)ServerThread.d \
   $(HTTPMODEL)IProvider.d \
   $(HTTPMODEL)IProviderBridge.d \
   $(HTTP)HttpBridge.d \
   $(HTTP)HttpMessage.d \
   $(HTTP)HttpReader.d \
   $(HTTP)HttpWriter.d \
   $(HTTP)HttpRequest.d \
   $(HTTP)HttpResponse.d \
   $(HTTP)HttpProvider.d \
   $(HTTP)HttpServer.d \
   $(HTTP)HttpThread.d \
   $(HTTP)HttpToken.d \
   $(HTTP)HttpParam.d \
   $(HTTP)HttpHeader.d \
   $(HTTP)HttpCookie.d \
   $(SERVLETMODEL)IServletRequest.d \
   $(SERVLETMODEL)IServletResponse.d \
   $(SERVLET)ServletConfig.d \
   $(SERVLET)Servlet.d \
   $(SERVLET)ServletRequest.d \
   $(SERVLET)ServletResponse.d \
   $(SERVLET)ServletProvider.d \
   $(SERVLET)ServletContext.d \


unittest :
    $(DMD) -c $(DFLAGS) -od$(OBJ) $(SRC) $(DSC)unittest.d
    $(CC) $(OBJ)*.o $(LIB)


and here's the error. It's puking on memicmp, and I don't know where to look for it. I figured it would be in my libc, but I don't know what to do if it's not.

Code:

gcc dsc/obj/*.o -lphobos -lpthread
dsc/obj/TokenStack.o(.gnu.linkonce.t_D3dsc6server5utils10TokenStack10TokenStack7isMatchFC3dsc2io5Token5TokenAaZb+0x2e): In function `_D3dsc6server5utils10TokenStack10TokenStack7isMatchFC3dsc2io5Token5TokenAaZb':
: undefined reference to `memicmp'
collect2: ld returned 1 exit status
make: *** [unittest] Error 1

_________________
I really like the vest!
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Sun Apr 11, 2004 12:24 pm    Post subject: Reply with quote

I haven't got as far as you yet, but memicmp is found in the static library libc.a (also shared libc.so ?). I don't know why there's a problem here. I vaguely recall this being an issue in the first linux dmd versions. Linking libc.a (which is huge) into this project seems counterintuitive. I'm sure there's a simple fix for this. I'll keep looking (unless you've solved it already).
Back to top
View user's profile Send private message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Sun Apr 11, 2004 12:33 pm    Post subject: Reply with quote

You might temporarily replace memicmp with memcmp instead (within TokenStack.d).

Alternatively, you could remove the Servlet and Http components from the makefile, and then version-out (or comment-out) the last three or four functions within unittest.d -- at least you'd have a working IO package ...

Let me know if there's anything I can help with;

- Kris
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Sun Apr 11, 2004 3:27 pm    Post subject: Reply with quote

Well, I don't have the same linking problems as Brad. No reference to memicmp as yet. But I have a whole wack of other link errors, although they seem to be understandably related to a lack of a sockets library. I haven't dealt with that yet. But for interests sake, here's my current makefile for perusal/fixing. I could be doing something wrong here too.

I have moved unittest out of the obj directory to prevent it from being included into the library archive. This is just quick and dirty stuff. Maybe someone can get a little further. My next step is to see what I can do with the linux sockets.d library.

Code:

# Designed to work with GNU make
# Targets:
#
#   make unittest
#      Build dsc.io package, and create dsc/obj/dsc
# Notes:
#   (old note for Win32: This relies on LIB.EXE 8.00 or later, and MAKE.EXE 5.01 or later.)
#   don't know if we need to do anything about these version constraints in Linux

DFLAGS=-version=linux

DMD=dmd
OBJ=dsc/obj/
DSC=dsc/
IO=dsc/io/
IOMODEL=dsc/io/model/
SERVER=dsc/server/
SERVERMODEL=dsc/server/model/
SERVERUTILS=dsc/server/utils/
HTTP=dsc/server/http/
HTTPMODEL=dsc/server/http/model/
SERVLET=dsc/servlet/
SERVLETMODEL=dsc/servlet/model/
UTILS=dsc/utils/
JETTY=dsc/utils/jetty/

COMPILE=$(DMD) -c $(DFLAGS) -od$(OBJ) $**  # GNU make didn't like this... $** maybe?

.obj.d :
   $(COMPILE)


SRC=   $(IOMODEL)IBuffer.d \
   $(IOMODEL)IConduit.d \
   $(IOMODEL)IReader.d \
   $(IOMODEL)IWriter.d \
   $(IOMODEL)ISerializable.d \
   $(IO)Exception.d \
   $(IO)FileStyle.d \
   $(IO)FilePath.d \
   $(IO)ConduitStyle.d \
   $(IO)Conduit.d \
   $(IO)Buffer.d \
   $(IO)Resource.d \
   $(IO)FileSystem.d \
   $(IO)FileConduit.d \
   $(IO)FileProxy.d \
   $(IO)EndianReader.d \
   $(IO)EndianWriter.d \
   $(IO)Tokenizer.d \
   $(IO)Token.d \
   $(IO)Printf.d \
   $(IO)TextWriter.d \
   $(IO)TextReader.d \
   $(IO)DisplayWriter.d \
   $(IO)ColumnWriter.d \
   $(IO)Stdio.d \
   $(IO)Reader.d \
   $(IO)Writer.d \
   $(IO)System.d \
   $(IO)Socket.d \
   $(IO)CompositeReader.d \
   $(IO)CompositeWriter.d \
   $(SERVERMODEL)IServer.d \
   $(SERVER)AbstractServer.d \
   $(SERVER)ServerThread.d \
   $(HTTPMODEL)IProvider.d \
   $(HTTPMODEL)IProviderBridge.d \
#   $(HTTP)HttpConstants.d \
   $(HTTP)HttpBridge.d \
   $(HTTP)HttpMessage.d \
   $(HTTP)HttpReader.d \
   $(HTTP)HttpWriter.d \
   $(HTTP)HttpRequest.d \
   $(HTTP)HttpResponse.d \
   $(HTTP)HttpProvider.d \
   $(HTTP)HttpServer.d \
   $(HTTP)HttpThread.d \
   $(HTTP)HttpToken.d \
   $(HTTP)HttpParamsIn.d \
   $(HTTP)HttpHeadersIn.d \
   $(HTTP)HttpParamsOut.d \
   $(HTTP)HttpHeadersOut.d \
   $(SERVERUTILS)Dictionary.d \
   $(SERVERUTILS)TokenStack.d \
   $(SERVERUTILS)Uri.d \
   $(SERVERUTILS)Utils.d \
   $(SERVLETMODEL)IServletRequest.d \
   $(SERVLETMODEL)IServletResponse.d \
   $(SERVLET)Servlet.d \
   $(SERVLET)ServletRequest.d \
   $(SERVLET)ServletResponse.d \
   $(SERVLET)ServletProvider.d \
   $(SERVLET)ServletContext.d \
   $(SERVLET)ServletConfig.d \

unittest : libdmc.a
    $(DMD) -c $(DFLAGS) $(DSC)unittest.d -I/opt/dmd/src/dsc
    $(CC) -o dsctest unittest.o libdsc.a -lphobos -lpthread -lm -g
       
unittestbin :
    $(DMD) -of.\dsc\obj\dsc $(OBJ)*.o

libdsc.a :
   $(DMD) -c $(DFLAGS) -od$(OBJ) $(SRC)
   ar -r $@ $(OBJ)*.o


Last edited by JJR on Sun Apr 11, 2004 4:08 pm; edited 2 times in total
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Sun Apr 11, 2004 3:29 pm    Post subject: Reply with quote

Just deleting this error display to get rid of the obscenely long lines. These linker errors are no longer an issue now, anyway.

Last edited by JJR on Sun Apr 11, 2004 3:50 pm; edited 2 times in total
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Sun Apr 11, 2004 3:32 pm    Post subject: Reply with quote

Oops! Seems I forgot to tell dmd where to look for imports on the unittest line.
Back to top
View user's profile Send private message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Sun Apr 11, 2004 3:34 pm    Post subject: Reply with quote

ahh, you have an slightly out-of-date make file. Use the one I mailed out last night, or cut and paste Brad's one above ...
Back to top
View user's profile Send private message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Sun Apr 11, 2004 3:40 pm    Post subject: Reply with quote

you may also need to clean out any old .o files, since some of the Modules have been renamed and may cause some kind of conflict. Frankly I'd delete the older dsc source tree, and reinstall afresh.

Hope that'll help ...

- Kris
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Sun Apr 11, 2004 3:40 pm    Post subject: Reply with quote

Well... the problem is that both Brad and you sent me one. I guess I must have tried the wrong one! I thought they were both the same. I'll give it another shot.
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Sun Apr 11, 2004 3:48 pm    Post subject: Reply with quote

Ok, the stale makefile was the problem. Thanks. I'm now getting the same memicmp problem as Brad now. I'll try your suggestion on memcmp from here.

Later,

John
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Sun Apr 11, 2004 4:06 pm    Post subject: Reply with quote

He he.... link success with a working library libdsc.a.

Running the unittest (which I had to rename dsctest because of conflict with directory of same name) works splendidly. The default unittest is testServletEngine and it seemed to run fine (spat out a bunch of data on the Linux console: no exceptions). I'll have to try out the other unittests in a bit, but have to get something to eat.

Kris, changing memicmp to memcmp did the trick.

In TokenStack.d line 46 changed to:

extern (C) int memcmp (void *, void *, uint);

TokenStack.d line 198 changed to:

return memcmp (cast(void*)target, cast(void*)match, length) == 0;

Seems to do the trick.
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Sun Apr 11, 2004 4:14 pm    Post subject: Reply with quote

Oh and the last makefile mod was this (at the bottom):

Code:

unittest : libdsc.a
    $(DMD) -c $(DFLAGS) $(DSC)unittest.d -I/opt/dmd/src/dsc
    $(CC) -o dsctest unittest.o libdsc.a -lphobos -lpthread -lm -g
       
unittestbin :
    $(DMD) -of.\dsc\obj\dsc $(OBJ)*.o

libdsc.a :
   $(DMD) -c $(DFLAGS) -od$(OBJ) $(SRC)
   ar -r $@ $(OBJ)*.o


May have to clean this up to make it more generic.
Back to top
View user's profile Send private message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Sun Apr 11, 2004 4:19 pm    Post subject: Reply with quote

That's good news!

The temporary lack of memicmp would manifest problems if you were checking for a particular HTTP header, or query parameter. Not a problem for the time being.

I guess you're already pointing a Browser at "127.0.0.1" (localhost) to get the console output? It's vaguely interesting to see what different Browsers send as default headers, cookies, and so on. BTW; you may notice that a couple of lines of the Servlet output (in unittest.d) are commented out -- this is to avoid the "Interface upcast" issue that's resolved in v0.83.

If you try the testHttpServer(), it waits for a CR on the console and then sends 100,000 requests (as a client) to itself (as a server), before quitting. I'd be interested to see how long that takes to execute on your linux boxen ...
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Sun Apr 11, 2004 4:47 pm    Post subject: Reply with quote

Well, it doesn't seem to work consistantly. When I tried the testServelet Engine, I hadn't actually done anything other than press enter... so it displayed connections to 0.0.0.0. So it wasn't doing anything.

When I try running the testServerHttp() unittest, it's not dependable. Once it coredumped (segmentation fault after pressing enter), once it complained a thousands times about not accepting the connection, and once it complained "Unable to bind socket." It consistanly alternates between these three. Also it keeps on wanting to try connections to 0.0.0.0. How do I change that?

So I guess the most significant thing is that it compiles and links. Unfortunately on my Linux it's not reliable yet. It's a start, though. Hopefully Brad can get it up and running soon and give it some tests too.
Back to top
View user's profile Send private message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Sun Apr 11, 2004 5:08 pm    Post subject: Reply with quote

JJR wrote:
Well, it doesn't seem to work consistantly. When I tried the testServelet Engine, I hadn't actually done anything other than press enter... so it displayed connections to 0.0.0.0. So it wasn't doing anything.

Right; it would start sending 100.000 requests (after console input) to itself also :-) If you don't hit CR, then it just waits for a Browser request on localhost. BTW, that 0.0.0.0 address is the result of the test Server binding itself to 'any' local port ... I guess that's just the way it represents itself.

JJR wrote:
When I try running the testServerHttp() unittest, it's not dependable. Once it coredumped (segmentation fault after pressing enter), once it complained a thousands times about not accepting the connection, and once it complained "Unable to bind socket." It consistanly alternates between these three. Also it keeps on wanting to try connections to 0.0.0.0. How do I change that?

Hmmm. The message "Unable to bind socket" is an easy one: When a socket is closed, it will still "linger" around for a bit in the OS. On Windows that appears to be just a few seconds by default. If you start the executable again within this period, it should produce that message. If this were not just a test-jig it would disable said "lingering" so as to avoid the message.

The other errors are much more serious. The "accept failed", and coredump are likely to represet problems regarding the manner in which the lower levels are being (ab)used. We should be able to get around these somehow, but I'll have to seek advice from CM. Note that this identifies a difference between WinSock and the linux BsdSocket implementations.

As far as changing the bound address, take a look at line 960 in unittest.d: it creates an InternetAddress() without specifying a specific binding address. You would make the appropriate change there. Note that this is where the listening socket (ServerSocket) is bound to.

JJR wrote:
So I guess the most significant thing is that it compiles and links. Unfortunately on my Linux it's not reliable yet. It's a start, though. Hopefully Brad can get it up and running soon and give it some tests too.

Yes; that is really great. I hope you have more solid results with the other stuff (non server-socket).
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> Mango All times are GMT - 6 Hours
Goto page 1, 2, 3, 4  Next
Page 1 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group