I experienced the same errors some time ago.
I think I solved these errors by recompiling the gnu-libraries, so I
figure these errors come from the fact that you didn't recompile the
gnu-libraries when you recompiled the system. Solution: recompile
gnu-libraries:
# cd /usr/src
# make gnu-libraries
Hope it helps.
With kind regards,
Jorn van Engelen
> --
> You received this message because you are subscribed to the Google
> Groups "minix3" group.
> To post to this group, send email to min...@googlegroups.com.
> To unsubscribe from this group, send email to
> minix3+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/minix3?hl=en.
so I figure these errors come from the fact that you didn't recompile the gnu-libraries when you recompiled the system.
On 03/20/2011 12:46 PM, Hrishikesh Murali wrote:
> Hi,
>
> On Sun, Mar 20, 2011 at 5:13 PM, Jorn van Engelen <spa...@quzart.com
> <mailto:spa...@quzart.com>> wrote:
>
> so I figure these errors come from the fact that you didn't
> recompile the gnu-libraries when you recompiled the system.
>
>
> Thanks, I'll try it out. But one thing, I have never recompiled the
> system, this is a fresh install of minix3.
Ok, then I was probably wrong ... but I think it's still worth a shot.
Looking at your message again: if you want to compile with the gcc
libraries, shouldn't it be:
LIBS = -lc -lgcc
instead of
LIBS = -lc -gcc
Looking at your message again: if you want to compile with the gcc libraries, shouldn't it be:
LIBS = -lc -lgcc
instead of
LIBS = -lc -gcc
On 03/20/2011 01:09 PM, Hrishikesh Murali wrote:
> I thought all libraries to be used during compilation are to be prefixed
> by a '-l'.
Correct, but in your first message you said you were using
'LIBS = -lc -gcc', without the 'l'.
Correct, but in your first message you said you were using
'LIBS = -lc -gcc', without the 'l'.
Solution: recompile gnu-libraries:
On Sun, Mar 20, 2011 at 10:11 AM, Hrishikesh Murali wrote:
> Even now, no success! Same error persists.
Just a wild guess, but maybe try adding -lm
LIBS = -lc -lm -lgcc
- Jeff
--
You received this message because you are subscribed to the Google Groups "minix3" group.
To post to this group, send email to min...@googlegroups.com.
To unsubscribe from this group, send email to minix3+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/minix3?hl=en.
What version of wget are you trying to compile.
However I get a different error in regards to MSG_PEEK not being
defined, which I am tracking down at the moment.
I was wondering if the order of library flags is important, ie -lm
before -lgcc,
finaly did you run ./configure before make?
minix now uses fetch instead of wget, any reason you want to use wget?
--
You received this message because you are subscribed to the Google Groups "minix3" group.
To post to this group, send email to min...@googlegroups.com.
To unsubscribe from this group, send email to minix3+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/minix3?hl=en.
On 03/21/2011 06:12 AM, Hrishikesh Murali wrote:
> I was wondering if the order of library flags is important, ie -lm
> before -lgcc,
>
>
> I don't think so. If there are a lot of libraries being used, then
> taking them one by one and linking them will only increase the time of
> linking as it has to read the library from disk (I/O) each time.
>
> Since most of the system libraries are in /usr/lib, there is a good
> chance that the libraries are very closely allocated to each other on disk.
>
> A better mechanism would be to read all the library functions' virtual
> addresses (generated by gcc) at one shot to main memory and then link
> them, therefore decreasing the time needed to link.
>
> So I'm guessing gcc does this, but I may be wrong.
The order of library flags is actually very important. This message
explains it:
http://groups.google.com/group/minix3/msg/f2142b811cfd963e
The explanation begins with:
"Perhaps you haven't ran into this problem, but it took me a long time
to figure out. Outline is: order does matter when linking in static
libraries.
Situation
=====
[...]
Background: gcc automatically adds -lc -lgcc at the end of the link
command line; use -v (or LDFLAGS=-v) to have it on screen.
However, there are sometimes some dependancies from code inside libgcc.a
which depends from libc.a, so are not resolved correctly and may result
in errors. My guess is that, it is the case with wget.
An ugly hack yet effective workaround is to use explicitly -lc -lgcc on
the GCC command line, which results in exec'ing
ld [....] -lc -lgcc -lc -lgcc
so any unresolved references from first reading of libgcc.a can be
resolved by the second reading of libc.a... Yes this is a kludge.
A better solution is to use GNU ld features, like grouping; so the ld
line shows as
ld [....] -( -lc -lgcc -)
[or uses --begin-group/--end-group instead of -( / -) which are easy to
type on command line; the effect is the same.]
I do not know if the gcc used by Minix uses that
Another point: libm.a in MINIX is completely dummy, it has no effect at
all, it is provided just to satisfy old Makefiles from PDP11 era which
insist to provide explicit reference to it.
Hope it helps
Antoine
> I finally could get wget successfully compiled. I'm not sure in any case,
> but it might be a problem with the gcc44 package which pkgin downloaded from
> the repository and installed.
>
> This time, the only difference I did this time was to manually download the
> gcc44 package from
> ftp://ftp.minix3.org/pub/minix/packages/3.1.8/i386/All/gcc44-4.4.3.tgz and
> copy it to /usr/var/db/pkgin/cache/. Then, when I compiled wget, it worked
> fine without any linker error!
I attempted porting wget to Minix in January but got stuck in linker
errors. The error that i used to get was related to 'libidn.a' , and
when i compiled without it, running wget used to give core dumps.
If you didn't get any linker error, i may have been doing something
wrong and i will retry by setting up the configurations file in pkgsrc
tree and rebuilding wget.
> I want to know how to see which repository pkgin is updating its local
> database and installing the packages from. How do I do that, and for some
> wierd reason if I want to change it, where would I need to change?
The repository file is located at /usr/pkg/etc/pkgin/repositories.conf
. pkgin updates the database from the minix3 repository itself.
I am not sure what '--disable-ipv6' does ? Any idea ? I remember that
'CONFIGURE_ARGS+=--disable-ipv6' is already there in wget/options.mk
and yet i had problem in building wget.
~
Vivek Prakash
I attempted porting wget to Minix in January but got stuck in linker
errors. The error that i used to get was related to 'libidn.a' , and
when i compiled without it, running wget used to give core dumps.
If you didn't get any linker error, i may have been doing something
wrong and i will retry by setting up the configurations file in pkgsrc
tree and rebuilding wget.
> The exact same wget query works fine from my host machine running linux.
The possible reason is that wget got compiled by taking some function
prototype from headers but they are not implemented anywhere in the
Minix. The output from wget command reflects this. You can use a
debugger to find out where wget is crashing by finding which function
is not implemented.
~
Vivek Prakash
Have you looked at changes made to compile the older wget package from
bigports[1]?
[1] https://gforge.cs.vu.nl/gf/project/minix/scmsvn/?action=browse&path=%2Ftrunk%2Fbigports%2F
--
Gautam
As in, there are some functions which prototypes are provided by Minix
but there are no implementation?
I know such a case was detected some months ago (tc{get,set}pgrp), but I
consider it a bug and it ought to be reported, at the very least to
allow some tracking.
Or, do you mean wget hardcodes some prototypes which are (supposedly)
available with the "mainstream" operating systems (read: Linux), while
not provided by MINIX?
In such a case, besides being a blatant failure of the autofoobar
process, it looks like a bug to be reported "upstream", doesn't it?
> You can use a debugger to find out where wget is crashing by finding
> which function is not implemented.
Ahem. There are no shared libraries thus no dynamic linking in MINIX. So
things are at least easier in this area: either a function is not
implemented, and linking fails (with a helpful error message). Or the
function does have an implementation, and if there is some crash, it is
not because of some function missing, rather because of a bug.
Antoine
> Or, do you mean wget hardcodes some prototypes which are (supposedly)
> available with the "mainstream" operating systems (read: Linux), while
> not provided by MINIX?
> In such a case, besides being a blatant failure of the autofoobar
> process, it looks like a bug to be reported "upstream", doesn't it?
As of now, i haven't seen any hardcoded function prototype in the
source code of wget.
> Ahem. There are no shared libraries thus no dynamic linking in MINIX. So
> things are at least easier in this area: either a function is not
> implemented, and linking fails (with a helpful error message). Or the
> function does have an implementation, and if there is some crash, it is
> not because of some function missing, rather because of a bug.
Yes, you are right. My inexperience caused me to give a wrong
conclusion. However, if it is a bug, what may be the possible cause
of it ?
~
Vivek Prakash