Stefan Parvu wrote:
If you were to elfdump(1) the archive object, I think you'll discover
the same error.
the result after elfdump:
http://www.nbl.fi/~nbl97/elfdump.libHSCabal.a.out.gz
Hmm, no errors, it seems that for once ld(1) has some stronger error
checking than elfdump - I should fix
Stefan Parvu wrote:
ld: fatal: symbol `s44W_info' in file
/export/home/sparvu/ghc/lib/ghc-6.6.1/libHSCabal.a(Utils__90.o): \
section [1] .text: size 1042: symbol (address 0x400, size 20) lies outside
of containing section
...
Anyone any ideas ? Is this a GNU ld / Sun ld issue ?
The
Vishwajeet wrote:
Q-2 If my executable has a dependency then it should load that dependency
only from /usr/lib/secure or /lib/secure. In my another program it is not
taking from /usr/lib/secure rather it is taking from /usr/lib/ or /lib as
default path for looking a shared object.
ld.so.1(1)
Go visit:
http://www.opensolaris.org/jive/thread.jspa?threadID=24771tstart=0
http://www.opensolaris.org/jive/thread.jspa?threadID=24565tstart=0
Might you all be involved in the same discussion?
--
Rod.
This message posted from opensolaris.org
Deepak Bhatia wrote:
I am working on a project related to the dynamic linker on Solaris.
You have asked a number of rudimentary questions in regards this area
of Solaris on this alias, and I have suggested that you target your
questions to [EMAIL PROTECTED], which is a more appropriate
alias
[EMAIL PROTECTED] wrote:
Rod Evans wrote:
Given that we're now several years into the *new* Solars :-), I have
on my list of things to do, the EOL of all this AOUT technology. I
find it hard to believe that anyone still expects a 4.x binary to
run on Solaris (although Sun had a few squirreled
Deepak Bhatia wrote:
Will it possible for you to help us in case we ask questions inside the dynamic
linker code ?
I recommend you send questions to [EMAIL PROTECTED]
I'm on this alias, and so are a lot of others who may be able to
help.
--
Rod.
Deepak Bhatia wrote:
#bldenv -d ./opensolaris.sh
Then I goto particular directory to do dmake all.
It says sh:/usr/src/cmd/sgs/tools/i386/sgsmsg
It looks like this is the continuation of a previous post where
you're trying to build the runtime linker :-)
As with many subsystems under
Deepak Bhatia wrote:
mdb document seems to be very large. Do we have a quick user guide for the same.
There's some Tips and Tricks here:
http://www.opensolaris.org/os/community/mdb/
perhaps that'll help you start.
--
Rod.
___
DEEPAK BHATIA wrote:
Can anyone please suggest how to proceed ? How do I tell the OS to invoke my
dynamic linker instead of the original one.
You can explicitly invoke a different runtime linker:
oxpoly 428. cp /usr/lib/ld.so.1 /tmp/ld.so.1
oxpoly 429. /tmp/ld.so.1 /bin/cat
[1] 17398
Mohd Hisham Auyob wrote:
ld: fatal: file /oracle/app/oracle/product/10.2.0/lib//libclntsh.so: wrong ELF
class: ELFCLASS64
ld: fatal: file /oracle/app/oracle/product/10.2.0/lib/scorept.o: wrong ELF
class: ELFCLASS64
ld: fatal: File processing errors. No output written to t.exe
Joerg Schilling wrote:
The problem is that I need an address from inside the module in case
I like to get the name for an arbitrary library handle. Do you believe that it
should always work to try retrieving the address for _DYNAMIC?
Yes, I don't know of any dynamic objects that don't have a
Joerg Schilling wrote:
This may still not prove your claim as the final ELF spec has been done by Sun
and ATT as part of the the joined work for SVr4.
The original ELF spec was indeed created by these players. But, the design
allowed for a great deal of extensibility. All of the UN*X's have
Alan Modra wrote:
On Mon, Nov 27, 2006 at 10:04:42PM +0100, Martin Man wrote:
There seems to be a bug in GNU ld that does not link filter symbols
properly.
I'd hardly call it a bug. By the sound of things, Sun has made some
extensions to ELF that GNU ld doesn't understand. Someone (you
Alan Modra wrote:
The question, I think, is why the ABS state of the symbol *definition* is
inherited by the symbol state of the *reference*. A reference is
typically undefined (UNDEF).
Perhaps because the Sys V ABI says:
SHN_ABS
The symbol has an absolute value that will not change
Rod Evans wrote:
Martin might have to add some c stub functions to his builds so that
his libraries provide non-ABS filter symbols in the mean time.
Arrr, but then the gnu linker probably doesn't grok symbol filter
definitions from a mapfile, so the sc tub trick wouldn't provide
much use
Martin Man wrote:
I'm just curious why this happens, what these symbols mean, and what are
they used for. Seems that GNU ld is picking them up in situations where
it shouldn't be, and I would like to reproduce a test case where ld can
deliberately exhibit this bug.
...
P.S. an excerpt of
$
wb wrote:
Hi.
I try to compile php 5.16 for apache 2.059 and mysql 4.0.17:
./configure --with-apxs2=/usr/local/apache/bin/apxs --enable-ftp
--with-mysql=/usr/local/mysql
and when I try to make, it finishes sadly as:
...
getenv 0xd5
wb wrote:
uh? could you explain please?
There is a flag that you can pass to ld(1), -z text that:
In dynamic mode only, forces a fatal error if any relo-
cations against non-writable, allocatable sections
remain. For historic reasons, this mode is not
Does Solaris and/Or Sun Studio have any linker/compiler flags to warn
users if a library or other code defines a symbol which is already used
by libc ?
For example MacOSX seems to create the following output when you define
|strtol| in an application library (this is from
Roland Mainz wrote:
Does Solaris and/Or Sun Studio have any linker/compiler flags to warn
users if a library or other code defines a symbol which is already used
by libc ?
-- snip --
I'd like to get similar output in Solaris - is that somehow possible ?
Multiple definitions within dynamic
Frank Mash wrote:
# Set up my environment
CC=/opt/SUNWspro/bin/cc
CFLAGS=-xarch=v9
LD_LIBRARY_PATH=/usr/local/mysql/lib:/usr/ccs/lib:/usr/lib:/usr/local/lib:/lib:/usr/ucblib
These three paths are searched by
Torrey McMahon wrote:
Rod Evans wrote:
I'd have thought things could be simpler by adding:
-L usr/local/mysql/lib -L /usr/local/lib
to the link-edit command line (LDFLAGS?).
And don't forget, LD_LIBRARY_PATH is recognized by the runtime linker
(ld.so.1)
too. Thus you are forcing
Martin Bochnig wrote:
you cannot mix -xarch=v9 and -xarch=v8 objects.
Somethings gets compiled 32 bits, something else 64bits, then the
/usr/ccs/bin/ld linker cannot link different ELFCLASS objects.
It might be a mistake in a makefile.
Looks very good otherwise.
Try to either make everything
Roland Mainz wrote:
+ /opt/SUNWspro/bin/cc -xO3 -xarch=amd64
.
-L/home/test001/ksh93/on_build1/test1/usr/src/cmd/sgs/libconv/amd64
-lconv -lc
Text relocation remains referenced
against symbol offset in file
unknown
Note: I'm moving this conversation over to [EMAIL PROTECTED]
To follow up, please use tools-linking and drop opensolaris-discuss.
Holger Berger wrote:
On 4/30/06, Rod Evans [EMAIL PROTECTED] wrote:
The colon has been the standard separator of multiple pathnames within
the link-editing
[EMAIL PROTECTED] wrote:
No, this is another case In short you cannot dlopen a library with a : in
the pathname
That seems like a bug.
Perhaps, but the intent has been to make all pathname processing within
ld.so.1 consistent. FILTERS, RUNPATHS, LD_LIBRARY_PATH, dependencies, in
fact,
Robert Lunnon wrote:
Wine now uses softlinks named x: (where x is the device name to link to)
placed in the filesystem. Wine preserved the Windows naming including the
colon in the link name. Unfortunately ld.so.1 doesn't seem to be able to load
a library across these links being confused by
Robert Lunnon wrote:
I have run across a problem in the latest wine sources, that seems to be
related to the linker (This is on Solaris 10 GA BTW). Wine's gcc links
shared libraries including an archive (.a) that defines main() (main calls
WinMain and format the command line for
The tools community has a new member - Dynamic Linking
http://www.opensolaris.org/os/community/tools/linker
and its own alias:
[EMAIL PROTECTED]
Comments, questions and lively discussions, welcome.
--
Rod.
___
opensolaris-discuss mailing list
I'd like to propose the creation of a new community that focuses
on Dynamic Linking. Primarily, this would discuss issues regarding
the runtime linker (ld.so.1(1)), and link-editor (ld(1)). However,
having supported these utilities for some time now, the core issues
that are normally discussed
Laszlo Peter wrote:
Hi Rod,
Thanks for the detailed response.
Of course I agree that it's better to avoid the problem by
carefully controlling public interface changes. However more
and more software in Solaris comes from external sources ...
So we can't break the interfaces we'd shipped
Laca wrote:
As far as I understand, the main problem with multiple versions
(apart from the increased maintenance effort) is that different
versions of the same lib may end up linked to the same executable
(through dependent libs) and it'll cause unpredictable runtime
linking and most likely a
33 matches
Mail list logo
