/ Forside / Teknologi / Udvikling / C/C++ / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
C/C++
#NavnPoint
BertelBra.. 2425
pmbruun 695
Master_of.. 501
jdjespers.. 500
kyllekylle 500
Bech_bb 500
scootergr.. 300
gibson 300
molokyle 287
10  strarup 270
cygwin objekt-filer og Borland Builder
Fra : Troels Thomsen


Dato : 18-02-02 21:21

Hej

Hvordan kalder jeg metoder i en obj fil lavet af cygwin i borland c++
builder 5
(g++ testfil.cpp -c)

På forhånd tak
Troels



 
 
Mogens Hansen (19-02-2002)
Kommentar
Fra : Mogens Hansen


Dato : 19-02-02 07:10


"Troels Thomsen" <nej@tak.dk> wrote

>
> Hvordan kalder jeg metoder i en obj fil lavet af cygwin i borland c++
> builder 5

Generelt skal man ikke forvente at kunne bruge OBJ filer fra forskellige
compilere sammen - end ikke fra 2 versioner af den samme compiler.
Der er naturligvis undtagelser. Ofte vil 2 versioner af samme compiler være
kompatible - men det er ikke noget jeg har set specificeret. Sommetider vil
en compiler være specificeret til at være binær kompatibel med end anden.
F.eks. var Symantec i sin tid binær kompatibel med Microsoft Visual C++, og
i dag er Intel C++ V5.0 binær kompatiblel med Microsoft Visual C++ V6.0.

Der er mulighed for forskellige i såvel filformater, som det binære layout
for forskellige konstruktioner som f.eks. name-mangling,
exception-håndtering, multiple arv, virtuel arv etc.

Det nemmeste er at lade være..
Hvis du har source-koden til de OBJ filer du oversætter med cygwin, og de er
rimeligt portable, så oversæt dem med Borland C++Builder, og link det hele
sammen.
En anden mulighed er at benytte de muligheder som man har i MS-Windows:
* Lav et DLL med et C interface med cygwin, og brug det i Borland
C++Builder
* Lav et DLL med COM interfaces med cygwin, og brug det i Borland
C++Builder

De to løsninger er bestemt ikke uden komplikationer.

Venlig hilsen

Mogens Hansen



Anders Borum (20-02-2002)
Kommentar
Fra : Anders Borum


Dato : 20-02-02 12:22

"Mogens Hansen" <mogens_h@dk-online.dk> skrev i en meddelelse
news:a4sqad$rmu$1@news.cybercity.dk...
[klip]
> Generelt skal man ikke forvente at kunne bruge OBJ filer fra forskellige
> compilere sammen - end ikke fra 2 versioner af den samme compiler.
> Der er naturligvis undtagelser. Ofte vil 2 versioner af samme compiler
være
> kompatible - men det er ikke noget jeg har set specificeret. Sommetider
vil
> en compiler være specificeret til at være binær kompatibel med end anden.
> F.eks. var Symantec i sin tid binær kompatibel med Microsoft Visual C++,
og
> i dag er Intel C++ V5.0 binær kompatiblel med Microsoft Visual C++ V6.0.

Unix-systemer vil som regel benytte ELF- eller COFF-formatet til både
objekt- og
program-filer og det er der andre som også gør (fx. oversættere til Analog
Devices
DSP'er). Ved nogen af jer om VC eller BC bruger noget af dette?

> Der er mulighed for forskellige i såvel filformater, som det binære layout
> for forskellige konstruktioner som f.eks. name-mangling,
> exception-håndtering, multiple arv, virtuel arv etc.

At to oversættere begge bruger COFF (Common Object File Firmat) løser
selvfølgelig
ikke problemer med navne-mangelering, men hvis man nu kunne klare sig uden
objekter
og undtagelser og så bruge extern "C" til alle funktionerne som skulle
bruges af den anden
oversætter. Kunne noget sådan tænkes at fungere?
Nogen der har prøvet ad?

Hilsen Anders

[klip]




Anders Borum (20-02-2002)
Kommentar
Fra : Anders Borum


Dato : 20-02-02 13:26

"Anders Borum" <overflade@fedt.dk> skrev i en meddelelse
news:aGLc8.2485$PE.47878@news000.worldonline.dk...
[klip]
> At to oversættere begge bruger COFF (Common Object File Firmat) løser
> selvfølgelig
> ikke problemer med navne-mangelering, men hvis man nu kunne klare sig uden
> objekter
> og undtagelser og så bruge extern "C" til alle funktionerne som skulle
> bruges af den anden
> oversætter. Kunne noget sådan tænkes at fungere?
> Nogen der har prøvet ad?

Ja nu tog iveren overhånd og jeg svarer på eget indlæg.

Såvel visual c++ som gcc i cygwin bruger coff-formatet - det ser man på
de to magiske bytes 0x4c og 0x01 der indleder coff-filer.

Visual C++ kan godt linke .o-filer fra cygwin og overføre
parametre og modtage en returværdi, omend man nok ikke skal
forsøge sig med fastcall-nøgleordet. Mit lille eksempel gik
meget glat.

vc.cpp:
#include <iostream>
using namespace std;
extern "C" int shared(int);

void main() {
cout << "shared(1) = " << shared(1) << endl;
}

ggc.cc:
extern "C" int shared(int);
int shared(int a) {
return a+7;
}

Det endelige program svarede: shared(1) = 8




Mogens Hansen (20-02-2002)
Kommentar
Fra : Mogens Hansen


Dato : 20-02-02 13:41


"Anders Borum" <overflade@fedt.dk> wrote in message
news:UBMc8.2505$PE.48968@news000.worldonline.dk...
>
> Visual C++ kan godt linke .o-filer fra cygwin og overføre
> parametre og modtage en returværdi, omend man nok ikke skal
> forsøge sig med fastcall-nøgleordet.

Hvad er "sizeof(long double)" med cgg i cygwin ?

Microsoft Visual C++ V6.0: 8 bytes
Microsoft Visual C++.NET : 8 bytes
Borland C++Builder V5.0: 10 bytes
gcc 2.96 på Red Hat 7.1: 12 bytes

Der er masser af ting, der kan gå galt.
Enighed om filformatet er nødvendigt, men ikke tilstrækkeligt.

Venlig hilsen

Mogens Hansen




Mogens Hansen (20-02-2002)
Kommentar
Fra : Mogens Hansen


Dato : 20-02-02 13:40


"Anders Borum" <overflade@fedt.dk> wrote
> "Mogens Hansen" <mogens_h@dk-online.dk> skrev i en meddelelse

>
> Unix-systemer vil som regel benytte ELF- eller COFF-formatet til både
> objekt- og
> program-filer og det er der andre som også gør (fx. oversættere til Analog
> Devices
> DSP'er). Ved nogen af jer om VC eller BC bruger noget af dette?
>

Så vidt jeg ved genererer Visual C++ V6.0 COFF (Common Object File Format)
filer. Microsofts format er afledt af COFF på Unix (ifølge dokumentationen).

OBJ filer fra Visual C++ .NET har et radikalt, og interessant, anderledes
indhold hvis man anvender /GL (Whole Program Optimization) compiler option
sammen med /LTGG (Link-time Code Generation) linker option.
Kode genereringen og dele af optimeringen er flyttet fra compileren til
linkeren.
I den forbindelse er det specificeret at man _ikke_ skal forvente OBJ fil
kompatibilitet mellem compiler versioner.

Så vidt jeg ved genererer Borland C++Builder V5.0 OMF (Object Module Format)
filer.

> > Der er mulighed for forskellige i såvel filformater, som det binære
layout
> > for forskellige konstruktioner som f.eks. name-mangling,
> > exception-håndtering, multiple arv, virtuel arv etc.
>
> At to oversættere begge bruger COFF (Common Object File Firmat) løser
> selvfølgelig
> ikke problemer med navne-mangelering, men hvis man nu kunne klare sig uden
> objekter
> og undtagelser og så bruge extern "C" til alle funktionerne som skulle
> bruges af den anden
> oversætter.

Netop - generelt kan man ikke bruge det binære output fra een C++ compiler
sammen med en anden.
Men der findes naturligvis undtagelser.

> Kunne noget sådan tænkes at fungere?
> Nogen der har prøvet ad?
>

Er det ikke _næsten_ det samme som at lave et DLL der eksporterer et C
baseret interface, med een compiler og bruge det med en anden
compiler/linker ?
Det er prøvet, og det virker - Win32 er bygget på den måde.

Venlig hilsen

Mogens Hansen



Anders Borum (20-02-2002)
Kommentar
Fra : Anders Borum


Dato : 20-02-02 14:07

"Mogens Hansen" <mogens_h@dk-online.dk> skrev i en meddelelse
news:a505ee$22g8$1@news.cybercity.dk...
[klip]
> OBJ filer fra Visual C++ .NET har et radikalt, og interessant, anderledes
> indhold hvis man anvender /GL (Whole Program Optimization) compiler option
> sammen med /LTGG (Link-time Code Generation) linker option.
> Kode genereringen og dele af optimeringen er flyttet fra compileren til
> linkeren.
> I den forbindelse er det specificeret at man _ikke_ skal forvente OBJ fil
> kompatibilitet mellem compiler versioner.

Det kan nogen gange godt ærgre mig at jeg ikke ejer en VC7. Der er
tilsyneladende sket en masse siden 6'eren. Jeg skammer mig over først
at have troet VC.NET blot indeholdt lidt ekstra features rettet mod COM+.

[klip]
> Er det ikke _næsten_ det samme som at lave et DLL der eksporterer et C
> baseret interface, med een compiler og bruge det med en anden
> compiler/linker ?
> Det er prøvet, og det virker - Win32 er bygget på den måde.

Man kan sige at linkningen så er udskudt til køretidspunktet med
indtroduktionen
af en ekstra fejlmulighed som konsekvens. Jo - det er strengt taget det
samme.

Nu gik Troels' første spørgsmål på linkning mellem to C oversættere.
En anden fordel med objektformat-kompatibilitet er at man nemt kan linke
assembler og C sammen. Det ville være synd og skam at spilde de cykler man
har vundet ved håndoptimeret assembler på overhead mht. bibliotekskald og
konvertering af datatyper. Men her kan man måske ligeså godt bruge inline-
assembleren i sin C-oversætter.

Hilsen Anders




Anders Melchiorsen (20-02-2002)
Kommentar
Fra : Anders Melchiorsen


Dato : 20-02-02 22:02

"Anders Borum" <overflade@fedt.dk> skrev:

> Det ville være synd og skam at spilde de cykler man har vundet ved
> håndoptimeret assembler på overhead mht. bibliotekskald og
> konvertering af datatyper.

Hvor og hvornår afholdes disse konkurrencer i håndoptimering af
assembler? Og er der andre præmier end cykler?


,
Anders.

Per Abrahamsen (20-02-2002)
Kommentar
Fra : Per Abrahamsen


Dato : 20-02-02 16:28

"Mogens Hansen" <mogens_h@dk-online.dk> writes:

> Hvad er "sizeof(long double)" med cgg i cygwin ?

12 bytes

> Der er masser af ting, der kan gå galt.
> Enighed om filformatet er nødvendigt, men ikke tilstrækkeligt.

Hvis man holder sig til C89 er det meste normalt dækket af ABI'en.


Mogens Hansen (20-02-2002)
Kommentar
Fra : Mogens Hansen


Dato : 20-02-02 17:26


"Per Abrahamsen" <abraham@dina.kvl.dk> wrote
> "Mogens Hansen" <mogens_h@dk-online.dk> writes:
>
> > Hvad er "sizeof(long double)" med cgg i cygwin ?
>
> 12 bytes
>

Tak.
Så kan man vist lave et kvalificeret gæt på hvorvidt man kan overføre en
"long double" fra en funktion compileret med gcc til en funktion compileret
med Visual C++ V6.0, og få det til at virke efter hensigten.

> > Der er masser af ting, der kan gå galt.
> > Enighed om filformatet er nødvendigt, men ikke tilstrækkeligt.
>
> Hvis man holder sig til C89 er det meste normalt dækket af ABI'en.
>

Hvem specificeret ABI'et til MS-Windows (cygwin/gcc og Borland C++Builder) ?
Mit bud er den ikke findes - Microsoft har en reference implementering (hvor
en del ting er ændret undervejs - f.eks. sizeof(long double)).
Burde typen "long double" ikke være dækket af det ?
Udtrykkene "det meste" og "normalt" indikerer for mig at der kan være
problemer.

Så vidt jeg ved er der i forbindelse med udviklingen af gcc 3.0 gjort et
arbejde for at lave et ABI der dækker C++.
Det samme har Intel gjort i forbindelse med Itanium processoren.
Jeg ved ikke hvor dækkende de er, men jeg kan forestille mig at hvis de er
baseret på en traditionel objekt-fil med maskinkode, kommer det under pres
hvis man vil lave "Whole Program Optimization" efter den model som Microsoft
Visual C++ .NET anvender.

Venlig hilsen

Mogens Hansen



Anders Borum (20-02-2002)
Kommentar
Fra : Anders Borum


Dato : 20-02-02 17:59

"Mogens Hansen" <mogens_h@dk-online.dk> skrev i en meddelelse
news:a50ikh$ad$1@news.cybercity.dk...
[klip]
> Så kan man vist lave et kvalificeret gæt på hvorvidt man kan overføre en
> "long double" fra en funktion compileret med gcc til en funktion
compileret
> med Visual C++ V6.0, og få det til at virke efter hensigten.

Det her jeg prøvet og det fungerer ikke.

> > > Der er masser af ting, der kan gå galt.
> > > Enighed om filformatet er nødvendigt, men ikke tilstrækkeligt.
> >
> > Hvis man holder sig til C89 er det meste normalt dækket af ABI'en.

Hvad er ABI en forkortelse af?

[klip]
> Så vidt jeg ved er der i forbindelse med udviklingen af gcc 3.0 gjort et
> arbejde for at lave et ABI der dækker C++.
> Det samme har Intel gjort i forbindelse med Itanium processoren.
> Jeg ved ikke hvor dækkende de er, men jeg kan forestille mig at hvis de er
> baseret på en traditionel objekt-fil med maskinkode, kommer det under pres
> hvis man vil lave "Whole Program Optimization" efter den model som
Microsoft
> Visual C++ .NET anvender.

Det er vel klart at VC7 ikke vil kunne foretage linktime-optimering på
objektfiler
fra fremmede oversættere. Dette betyder dog ikke at de fremmede objektfiler
ikke
/kan/ linkes med - ej heller at resten af programmet ikke /kan/ optimeres,
så man får
noget "Almost WPO". Men der kan selvfølgelig være forskel på /kan/ og
/bliver/.

Det er dog næppe muligt at gå den anden vej og linke en VC7 objektfil med
gcc.

Hilsen Anders




Mogens Hansen (20-02-2002)
Kommentar
Fra : Mogens Hansen


Dato : 20-02-02 19:45


"Anders Borum" <overflade@fedt.dk> wrote in message
news:6CQc8.2612$PE.59919@news000.worldonline.dk...
> "Mogens Hansen" <mogens_h@dk-online.dk> skrev i


>
> Hvad er ABI en forkortelse af?
>

Application Binary Interface

> [klip]

>
> Det er vel klart at VC7 ikke vil kunne foretage linktime-optimering på
> objektfiler
> fra fremmede oversættere. Dette betyder dog ikke at de fremmede
objektfiler
> ikke
> /kan/ linkes med - ej heller at resten af programmet ikke /kan/ optimeres,
> så man får
> noget "Almost WPO". Men der kan selvfølgelig være forskel på /kan/ og
> /bliver/.
>

Min pointe er blot at hvis anvender en compiler ud over hvad den er
specificeret til, risikerer man at få problemer (og jeg har nævnt nogle
konkrete eksempler) - også selv om man ikke umiddelbart kan overskue alle
aspekter. Der er ingen steder man kan henvende sig med sine eventuelle
problemer.
Jeg har aldrig set at hverken Microsoft Visual C++ eller Borland C++Builder
har været specificeret til at kunne anvende objektfiler lavet med gcc.
Jeg forventer at når Borland lancerer C++Builder til Linux, vil der komme en
beskrivelse af i hvilket omfang den er kompatibel med gcc og i hvilke
versioner af gcc, ligesom der følger med Intel C++ V5.0 for Linux.
Når f.eks. Intel specificerer at Intel C++ V5.0 for Windows er binær
kompatibel med Microsoft Visual C++ V6.0, forventer jeg at tingene virker
(og det gør de, så vidt jeg har set) og at jeg kan kræve at Intel støtter
med løsning af eventuelle problemer.
Det sikreste er at lade være med at blande mellemresultatet fra 2 compilere,
og løse problemet på en velspecificeret måde. På MS-Windows er mulighederne
* compiler al source-koden med een compiler
* lav et DLL der stiller et C baseret interface til rådighed
* lav et DLL der stiller et COM baseret interface til rådighed

Venlig hilsen

Mogens Hansen



Anders Borum (20-02-2002)
Kommentar
Fra : Anders Borum


Dato : 20-02-02 20:19

"Mogens Hansen" <mogens_h@dk-online.dk> skrev i en meddelelse
news:a50qt8$h87$1@news.cybercity.dk...
[klip]
> Jeg har aldrig set at hverken Microsoft Visual C++ eller Borland
C++Builder
> har været specificeret til at kunne anvende objektfiler lavet med gcc.
> Jeg forventer at når Borland lancerer C++Builder til Linux, vil der
komme en
> beskrivelse af i hvilket omfang den er kompatibel med gcc og i hvilke
> versioner af gcc, ligesom der følger med Intel C++ V5.0 for Linux.
> Når f.eks. Intel specificerer at Intel C++ V5.0 for Windows er binær
> kompatibel med Microsoft Visual C++ V6.0, forventer jeg at tingene
virker
> (og det gør de, så vidt jeg har set) og at jeg kan kræve at Intel
støtter
> med løsning af eventuelle problemer.

Nu har jeg kigget rundt i dokumentationen til VC6 og fundet følgende
fragment:
"LINK accepts .OBJ files that are either Common Object File Format
(COFF) or
32-bit Object Module Format (OMF). Microsoft's compiler creates COFF
..OBJ
files. LINK automatically converts 32-bit OMF objects to COFF. See Set
Linker
Options for related information."

Nu betyder dette jo ikke præcis at VC6 lover at være kompatibel med alle
mulige
coff- og wol-filer. Det ville selvfølgelig gå galt hvis jeg forsøger at
linke med en
objektfil til ADSP21065L (tidligere omtalte digital signalprocessor) som
dog er i
coff-format. Men MS har dog gjort en indsats for at kunne læse Borlands
objektformat.

Man er på egen hånd et stykke hen ad vejen når man linker, idét man fx.
selv
skal sikre sig at argument- og returtyper forstås entydigt - løses
selvfølgelig
ved at placere disse erklæringer i en enkelt headerfil.
Jeg kan have uoverensstemmelse mellem extern-erklæringer i forskellige
kildefiler. Denne uoverensstemmelse bliver ikke fanget af linkeren
medmindre
navne-mingelering rent faktisk oversætter de forskellige erklæringer til
forskellige
symboler.

> Det sikreste er at lade være med at blande mellemresultatet fra 2
compilere,
> og løse problemet på en velspecificeret måde. På MS-Windows er
mulighederne
> * compiler al source-koden med een compiler
> * lav et DLL der stiller et C baseret interface til rådighed
> * lav et DLL der stiller et COM baseret interface til rådighed

Jeg kan give dig rette et stykke hen ad vejen. Men nogen gange er det
statisk linkning
mere hensigtsmæssigt end dynamisk linkning.

En stor del af problemerne med Win95/98/ME skyldes problemer med
dynamisk
linkning. Programmer og DLL'er forventer en anden version af en DLL end
hvad
der er installeret. Resultatet bliver et program der kan afvikles, men
som ikke
fungerer korrekt.

Hilsen Anders



Mogens Hansen (20-02-2002)
Kommentar
Fra : Mogens Hansen


Dato : 20-02-02 21:25


"Anders Borum" <overflade@fedt.dk> wrote in
> "Mogens Hansen" <mogens_h@dk-online.dk> skrev

>
> Men MS har dog gjort en indsats for at kunne læse Borlands
> objektformat.
>

Det mener jeg nu ikke at man kan se ud af dokumentationen.
Så vidt jeg husker skiftede Microsoft på et tidspunkt fra OMF til COFF.

>
> Jeg kan give dig rette et stykke hen ad vejen. Men nogen gange er det
> statisk linkning
> mere hensigtsmæssigt end dynamisk linkning.
>

Jeg er fuldstændig enig.

Venlig hilsen

Mogens Hansen



Per Abrahamsen (21-02-2002)
Kommentar
Fra : Per Abrahamsen


Dato : 21-02-02 19:33

"Mogens Hansen" <mogens_h@dk-online.dk> writes:

> "Per Abrahamsen" <abraham@dina.kvl.dk> wrote
>
>> Hvis man holder sig til C89 er det meste normalt dækket af ABI'en.
>
> Hvem specificeret ABI'et til MS-Windows (cygwin/gcc og Borland C++Builder) ?

Normalt chip eller OS leverandøren, men MS er jo kendt for at køre
deres eget løb.

> Mit bud er den ikke findes - Microsoft har en reference implementering (hvor
> en del ting er ændret undervejs - f.eks. sizeof(long double)).
> Burde typen "long double" ikke være dækket af det ?

Jo, i og med at f.eks. GCC ikke kommer med sit eget C bibliotek, og er
afhængig af leverandørens. Det vil sige at

long double foo = 1.0;
printf ("%Lg", foo);

ikke vil virke med GCC under MS Windows.

Den eneste grund jeg kan se til at GCC er sluppet afsted med det, er
at ingen for alvor bruger long double, eller at de folk der bruger det
er klar over inkompatibiliteten.

De folk der vælger at bruge long double har antageligvis brug for den
ekstra præcision, og foretrækker derfor en en type de ikke kan skrive
ud (uden et cast), fremfor en type der er identisk med double.

Ups, jeg kommer lige i tanke om at Cygwin faktisk kommer med sit eget
C bibliotek, så ovenstående gælder kun for MinGW. Og jeg har ikke
MinGW, så jeg kan ikke teste størrelsen af "long double" der.

> Så vidt jeg ved er der i forbindelse med udviklingen af gcc 3.0 gjort et
> arbejde for at lave et ABI der dækker C++.

De forskellige firmaer der arbejder på IA64 compilere er gået sammen
om at lave en fælles C++ ABI til denne processor.

GCC har så valgt at bruge C++ delen af denne ABI til alle processorer,
da ingen andre har en sådan ABI. Med hensyn til C delen vil de dog
fortsat bruge den allerede eksisterende ABI.

> Det samme har Intel gjort i forbindelse med Itanium processoren.

Intel er en del af IA64 C++ ABI gruppen.

Ken (19-02-2002)
Kommentar
Fra : Ken


Dato : 19-02-02 13:02

"Troels Thomsen" <nej@tak.dk> wrote in message
news:3c716288$0$18446$ba624c82@nntp02.dk.telia.net...
> Hej
>
> Hvordan kalder jeg metoder i en obj fil lavet af cygwin i borland c++
> builder 5

Det er måske en detalje men cygwin er ikke en oversætter, men et UNIX
environment til windows. Som jo i principet kan indeholde mange forskellige
oversættere.

> (g++ testfil.cpp -c)

Det angiver så at du naturligvis bruger gcc. (Men ikke versionen, som også
har betydning for "obj-formatet")

Mvh Ken




Troels Thomsen (19-02-2002)
Kommentar
Fra : Troels Thomsen


Dato : 19-02-02 21:44


"Ken" <ken.f@mail.com> wrote in message news:3c723eac$1@lxcs1.manbw.dk...
> "Troels Thomsen" <nej@tak.dk> wrote in message
> news:3c716288$0$18446$ba624c82@nntp02.dk.telia.net...

> Det er måske en detalje

Det må jeg give dig ret i.



Søg
Reklame
Statistik
Spørgsmål : 177500
Tips : 31968
Nyheder : 719565
Indlæg : 6408514
Brugere : 218887

Månedens bedste
Årets bedste
Sidste års bedste