| View previous topic :: View next topic |
| Author |
Message |
mhweather
Joined: 07 Aug 2005
Posts: 54
|
 Posted: Mon Nov 07, 2005 7:39 am Post subject: Wview 1.8.3 MAKE errors |
 |
|
Trying to make 1.8.3, getting errors:
gcc -g -O2 -o wviewd -L/usr/lib -L/usr/local/lib -L/usr/local/lib -static wvutils.o dbfiles.o windAverage.o daemon.o daemonStates.o serial.o ethernet.o computedData.o vpinterface.o -lc -lm -lrad -lz -lrad -lpng -lm -lgd -lc
/usr/local/lib/librad.a(radsocket.o)(.text+0x2fd): In function `radSocketClientCreate':
src/radsocket.c:216: warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
ethernet.o(.text+0x320): In function `ethernetMediumInit':
../daemon/ethernet.c:231: undefined reference to `rpl_malloc'
collect2: ld returned 1 exit status
make[2]: *** [wviewd] Error 1
make[2]: Leaving directory `/home/teamloser/wview-1.8.3/daemon'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/teamloser/wview-1.8.3'
make: *** [all] Error 2
Only change I made for this 1.8.3 was to install the radlib 2.5.0 as per your prereq. |
|
| Back to top |
|
 |
mteel
Joined: 30 Jun 2005
Posts: 435
Location: Collinsville, TX
|
| Posted: Mon Nov 07, 2005 3:24 pm Post subject: |
|
|
See:
http://www.wviewweather.com/phpBB2/viewtopic.php?p=107&
I also found this on the web:
| Quote: | As far as I can tell, this is the Linux distribution issue. The
./configure script should find which implementation of malloc is
supported by the system and write its finding to phoebe_build_config.h.
What I *think* is happening is that the system somehow misleads
./configure to think that you have rpm_malloc instead of gcc's malloc.
Unfortunately, I never experienced this issue myself and someone from
the list may be able to help. |
I think you can edit config.h and change
to
and it will also fix it. I would try the make distclean approach first though...
I don't have this problem on FreeBSD or Fedora Core 4 
Mark |
|
| Back to top |
|
|
mhweather
Joined: 07 Aug 2005
Posts: 54
|
| Posted: Mon Nov 07, 2005 7:21 pm Post subject: |
|
|
The config.h edit did the trick. Thanks!  |
|
| Back to top |
|
|
mteel
Joined: 30 Jun 2005
Posts: 435
Location: Collinsville, TX
|
| Posted: Mon Nov 07, 2005 8:30 pm Post subject: |
|
|
| But the *make distclean* didn't? That would be a much cleaner solution and I could put it into the User Manuals... |
|
| Back to top |
|
|
mhweather
Joined: 07 Aug 2005
Posts: 54
|
| Posted: Tue Nov 08, 2005 6:13 am Post subject: |
|
|
Well, I tried :
make distclean
./configure --enable-wundergound
make
That did not work. So I went and edited the config.h, and that did work.
Did I do the right sequence of steps ? |
|
| Back to top |
|
|
pata
Joined: 27 Oct 2005
Posts: 21
Location: Long Island, NY
|
| Posted: Thu Nov 10, 2005 8:59 pm Post subject: |
|
|
I had the same problem as mhweather. I am using Fidora Core 3. Tried to upgrade to 1.8.3 and could not finish the make, same problem. (this after install of radlib-2.5.0). Could also not go back to wview-1.8.1.
make distclean did not work for me. I made the change to conf.h and that worked for me. I am now up and running with 1.8.3
Pat |
|
| Back to top |
|
|
mteel
Joined: 30 Jun 2005
Posts: 435
Location: Collinsville, TX
|
| Posted: Thu Nov 10, 2005 9:03 pm Post subject: |
|
|
It is very odd - I test built it on my Fedora Core 4, no problems at all. And it is running on my FreeBSD 5.3 server...
Maybe I can find some work-around for the autoconf setup to alleviate this in the future. |
|
| Back to top |
|
|
THogland
Joined: 26 Sep 2005
Posts: 33
|
| Posted: Sun Nov 13, 2005 12:20 pm Post subject: Compile errors on upgrade |
|
|
I also had the same issues. Weather Underground stopped uploading, so I decided it'd be a good time to update. Installed radlib2.5 (no errors), then both 1.8.3 and 1.8.4p2 gave the rpl_malloc error on make. (Same as posted before, so I'll refrain from re-posting...) The configure script for wview says the system doesn't have a GCC-compatible malloc (thought that was odd), but commenting out the '#define malloc rpl_malloc' let it compile. Make-distclean made no difference...
However, trying to start gives this error:
| Code: | | /usr/local/bin/wviewd: error while loading shared libraries: librad.so.0: cannot open shared object file: No such file or directory |
(Each module gave the same error.)
Cleaned and recompiled radlib and noticed that IT says there's a GCC-compatible malloc in here... Re-ran the config in 1.8.4p2, changed config.h '#define HAVE_MALLOC 0' to '1' and it compiled fine. Still get the same shared library error on (failure to) start...
(Insert very faint sound of clue hitting dense skull...)
Now, radlib 2.5 on the 'make install' mentioned that it needs to have either a couple parameters passed (via -L) during compile of any software needing it, or the shared library directory (/usr/local/lib) added to /etc/ld.so.conf so said programs can find it. I checked, and ld.so.conf didn't have that, so I added it, ran ldconfig, and then the make clean/config/make/make install worked fine, no editing the config.h needed...
Is it possible there's an error in the radlib 2.5 install script that's causing this? I ran the 2.4 install and the 2.5 install back to back to test, and they *look* the same (says the non-programmer), but it seemed to point to that, at least on mine...
Be glad to help test - just let me know what to do... |
|
| Back to top |
|
|
mteel
Joined: 30 Jun 2005
Posts: 435
Location: Collinsville, TX
|
| Posted: Sun Nov 13, 2005 1:28 pm Post subject: |
|
|
Thanks for the detailed description of events.
radlib 2.5.0 is the first version of radlib to use libtool, which creates shared and static versions of librad. I made this change to allow linking radlib in C++ applications (I have a new project I'm working on for multiprocessor synchronization using a C++ library built on top of radlib). However, gcc wants to default to linking against shared libraries instead of static as it makes the binary image smaller and is supposed to load faster when run. The gotcha with shared libraries (all of them, not just radlib) is that you have to have the path to the shared library *known* when the binary is being loaded (when you execute it). If it is not, you get the error you documented.
The way you updated ld.so.conf and ran ldconfig is one way to accomplish this, the other way is to specify your shared library path in the environment variable "LD_LIBRARY_PATH". The new wview start scripts define this variable and can be copied over your old start script.
These are the growing pains associated with moving radlib to a libtool build model. In the past (2.4.0 and earlier), radlib was only built as a static library and gcc had no choice when linking the wview daemons but to do a static link (thus avoiding the shared library load failure when running them).
In summary, I don't think there is anything to test with respect to the shared library runtime error - folks are just going to have to update their shared library cache (like you did) or use the new wview start scripts. There may be a way to cause the shared library cache to be updated via autoconf - I'll look around and see if I can find anything.
The issue I would like to figure out though is this rpl_malloc problem. Somehow the configure script is not finding the libc malloc. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
