Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
126 user(s) are online (119 user(s) are browsing Forums)

Members: 1
Guests: 125

joerg, more...

Support us!

Headlines

Forum Index


Board index » All Posts (elfpipe)




Re: Link problem (relocation truncated to fit)
Just can't stay away
Just can't stay away


@tonyw

Hmm... I'm not sure, I think I'm only using newlib libraries. Anyway, all the Amicygnix libraries are static, the rest are not.

But since I just managed to compile and link the whole thing with only static objects, and since the critical factor turns out the be the -mlongcall flag, mixing shared and static objects shouldn't be the issue.

I'm not sure wether -mlongcall versus no -mlongcall is going to be an issue, though...?

Go to top


Re: Link problem (relocation truncated to fit)
Just can't stay away
Just can't stay away


@nbache

Yes, making it smaller would be a good solution. Problem is, I know so relatively little about the code I'm working with, so I wouldn't know where to start...

In the meantime, I managed to compile and link the code by means of adding -fPIC and -mlongcall to the compiler and recompiling all the Qt libs (the recompile took just about 20 hours...). Of course I can't know for sure, but I think the critical point here is the -mlongcall flag, that supposedly turns all the relative jumps and branches into absolute 32 bit ones. I'm building with only static objects now (no -use-dynld), so the shared objects V1 vs. V2 is not the issue. Also, I tried linking static only with my old objects (those without -fPIC and -mlongcall), and it still didn't work...

Problem with -mlongcall is, that the code gets slightly slower. Next thing I'm going to do is, that I'm going to link the Qt libs as all shared objects and see if I can get it working that way. As you said, Niels, I might have to split up the WebKit library in smaller parts to get it working.

Still my conclusion is, that if this is a general issue with large executables compiled with gcc on aos4, then there should be some information on how to solve it in the SDK docs, because other people are bound to get into the same problems as me in the future. Also, -mlongcall would not be a general solution unless ALL of the libraries used to link the code are compiled with this flag. As for my example, I'm just lucky, that recompiling Qt "solved" the problem.

Go to top


Re: More mysterious matters... ;-)
Just can't stay away
Just can't stay away


@emeck

Nope, it's not Netsurf . I have netsurf installed, and I think it works well, even through Amicygnix.

Go to top


Re: More mysterious matters... ;-)
Just can't stay away
Just can't stay away


@broadblues

Hehe, you are spot on .

It's "just" the webkit engine in a Qt wrapper, and as you say, it's not really very fancy at all. Nevertheless, if I manage to get this one running, there is a much more elaborate demo-browser in the Qt package, that has tabbed browsing, download manager etc. And of course it's going to be rather slowish running in Amicygnix, but hey, there is going to be no native Qt before I have the X11 version up and running at full feature level .

For those of you, who should be interested in Qt, I can tell you, that all the command line tools, QtCore and QtGui are up and running, and all the simple widget examples work pretty much flawlessly, except for a few minor problems.

...and yes, I know this screenshot is actually rather pathetic, but still I have spent quite a lot of time and energy just getting to this point, so I thought I would at least show it to the public...

Go to top


Re: More mysterious matters... ;-)
Just can't stay away
Just can't stay away


@328gts

Yeah, Timberwolf.... mmmmmmmm! 8-D

(Notice the super cool "[Not responding]" tag at the top..... Doh!)

Go to top


More mysterious matters... ;-)
Just can't stay away
Just can't stay away


... What is this ??!...

http://dl.dropbox.com/u/5482530/fancybrowser.jpg

..... it sure ain't Timberwolf... so what is it.....?



Go to top


Re: Link problem (relocation truncated to fit)
Just can't stay away
Just can't stay away


@phx

Thanks for the info. It seems, that the issue have been fixed with later versions of gcc (4.4 or smth), but that doesn't help me a lot. Some people seem to think, that it can be avoided by compiling libraries as shared objects (that's pretty much what I'm trying to do at the moment) and possibly by compiling everything with -mlongcall. I have tried compiling the executable code with -mlongcall, and it _does_ seem to have an impact on the problem, but it doesn't remove it, it just "shifts" the problem to a new area. I'm guessing, that if I'm going to make it work, I'll need to compile EVERYTHING - including newlib - with -mlongcall, and that's a bit of a problem, since I don't even have access to the newlib sources...

Are the newlib sources available somewhere, or is it proprietary stuff? I've tried to contact J?rg, but he's probably too busy to answer. Also, I'm interested in knowing, if the adtools project on sourceforge is still active? It seems, that the last release was 20 months ago...?

This is a big shame, since my project was going so well until now...

Go to top


Re: New Programming Book for OS4
Just can't stay away
Just can't stay away


@Coder

Hehe, I actually started writing a book on "modern Amiga programming" (intended to include a section on Hollywood and other stuff) but eventually gave up, because I realized, I knew too little about the subject.

I would definitely buy one!

Go to top


Re: Link problem (relocation truncated to fit)
Just can't stay away
Just can't stay away


@ssolie

Thanks for the update on shared objects, I didn't read the docs since the SDK update.

Hmm... It seems, that -fPIC shouldn't be able to explain the error, although I _am_ in fact using some shared objects. But I'm also linking with at least 3 other static libraries, that haven't been compiled with -fPIC, and they don't display any such problems... (The code in the static libs cannot possibly ever be called from within the shared objects, so -fPIC is not a problem.)

I'll try and get a hold of J?rg, although my previous attempts at reaching him have all been in vain. I'm guessing he is dead busy...

EDIT: The -fPIC theory is definitely dead, because the people mentioning it refer to it as a "-fPIC versus -fpic issue". Amiga doesn't have -fpic at all. All other suggested solutions I have seen so far have - as far as I can see - been referring to system specific issues... Drats!

Go to top


Link problem (relocation truncated to fit)
Just can't stay away
Just can't stay away


I'm trying to link an executable against library that is about 180MB large. I get these errors:

main.cpp(.text+0x2c): relocation truncated to fit: R_PPC_PLTREL24 against symbol 'std::string::size() const' defined in .plt section in /SDK/newlib/lib/crtbegin.o


I can't find much help on google, but one thing that people mention is, that it is a size problem, and that it could be related to -fPIC. I'm not so tough on code generation issues, but I do know, that -fPIC is something used for generating shared objects. My 180MB size library is a static library and is compiled without -fPIC or -fpic. My only go at the moment is to add -fPIC to the makefile and recompile the entire library... It's just, it takes more than 12 hours to compile, so I wanted to hear, if somebody had a better guess before wasting more time on it .

EDIT: I just noticed, that all the error msgs refer to crtbegin.o. Could it be a problem with crtbegin.o?

Go to top


Re: Problems with PIPE:
Just can't stay away
Just can't stay away


@alfkil

Steven Solie stepped in and saved the queue-handler !

Thanks Steven

@nbache:
Gotta keep up with evolution

Go to top


Re: Problems with PIPE:
Just can't stay away
Just can't stay away


@thomas

No difference.

Go to top


Re: Problems with PIPE:
Just can't stay away
Just can't stay away


@nbache

One can always count on you, Niels! Thanks for the info!

Go to top


Re: Problems with PIPE:
Just can't stay away
Just can't stay away


@abalaban

Thanks for the info, I'll check it out when I get home this weekend.

It still doesn't explain why /NOBLOCK doesn't work in reading mode, though.

Go to top


Re: Amiga meeting in norway
Just can't stay away
Just can't stay away


@Antique:

Hey wait a minute!... 13th of March is Z-day! You are stealing our audience!

Go to top


Re: Problems with PIPE:
Just can't stay away
Just can't stay away


@abalaban

Yes it should! But this one returns an error even when it is NOT empty, that's the problem...

Again: Where do I go to file a bug report on an Amiga OS component?

EDIT:
And also: Could somebody please just copy the code, compile and run it to confirm, that it is not just a local problem on my system? You don't need to know anything about, what the code does, all you need is to have the official OS 4.1 SDK installed, follow the compiling instructions I gave, run with 'apipe', and then if you would post the output you get to this thread. It should take about 2 minutes to do. Please??... Thanks!


Edited by alfkil on 2010/2/24 13:09:27
Edited by alfkil on 2010/2/24 13:09:59
Edited by alfkil on 2010/2/24 13:10:39
Edited by alfkil on 2010/2/24 13:11:33
Go to top


Re: Problems with PIPE:
Just can't stay away
Just can't stay away


@colinw

Hmm... What is it returning? True/false or smth else? I can't check right now, I'll look at it this weekend.

Still this doesn't explain why Open("PIPE:testpipe/NOBLOCK", MODE_OLDFILE) doesn't work (it returns a valid filehandle, but when reading from it, it returns only errors).

Go to top


Re: Problems with PIPE:
Just can't stay away
Just can't stay away


@Rigo

Ok, thanks, I'll try it!

Go to top


Re: Problems with PIPE:
Just can't stay away
Just can't stay away


@centaurz

Hmm... I replied to your msg yesterday, but the reply seems to have vanished. I'll retry:

Of course I'm not going to use a pipe for read/write in the same process. This is just a simplified test app to see, if the pipe itself will actually work or not.

The reason it blocks is because that's how it's supposed to do (at least that's how it works on Mac OS X 10.4 with the unix 'pipe()'). But it is ALSO supposed to react to setting a /NOBLOCK flag, that makes this behavior go away (which means, that the subsequent call to Read would return immediately with no data). The last thing is what I cannot get to work. From the documentation it is supposed to work, so I figure there's a bug somewhere (read my other post).


Edited by alfkil on 2010/2/22 21:33:13
Go to top


Re: Problems with PIPE:
Just can't stay away
Just can't stay away


@ssolie

Thanks, but I already read though that file a gazillion times, and as far as I can see, from the description it gives, there is a BIG FAT BUG in queue-handler... or at least what I would call a "discrepancy" btw the documentation and the actual API; namely that the /NOBLOCK clause doesn't work at all when applied to a reading end of the pipe, and that IDOS->SetBlockingMode() also fails to fulfill it's purpose (on the writing end it might work, I don't know)... In both cases IDOS->Read(pipehandle, ...) will return only errors and no data, although the filehandle seems to be fine otherwise.

I would like if anyone could confirm this... Also, if it is really a bug, I would like to send a bug report, but I don't know where to send it.

EDIT: Usually in these kinds of situations, it turns out, that I'm just a big fat pinhead who has overlooked something totally obvious to the person of average intelligence. Hence my need for confirmation

Go to top



TopTop
« 1 ... 69 70 71 (72) 73 74 75 »




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project