Looking for a workaround to a GNU linker bug
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
0
down vote
favorite
Since a while (probably 12 years), the GNU linker includes support for linker map files for versioned shared libraries as introduced by Sun in 1993.
Unfortunately, the GNU linker rejects correct linker map files, but likes to see similar map files in reversed order.
A correct linker map file looks like:
SCHILY_3
global:
function5;
function6;
local:
*;
SCHILY_2;
SCHILY_2
global:
function3;
function4;
local:
*;
SCHILY_1;
SCHILY_1
global:
function1;
function2;
local:
*;
;
The GNU linker however seems to like it this way:
SCHILY_1
global:
function1;
function2;
local:
*;
;
SCHILY_2
global:
function3;
function4;
local:
*;
SCHILY_1;
SCHILY_3
global:
function5;
function6;
local:
*;
SCHILY_2;
Does someone know a way to automatically convert the first correct form into the second for using UNIX/LINUX on-board programs?
linux ld
asked 2 days ago
schily
8,38721435
add a comment |Â
up vote
0
down vote
favorite
Since a while (probably 12 years), the GNU linker includes support for linker map files for versioned shared libraries as introduced by Sun in 1993.
Unfortunately, the GNU linker rejects correct linker map files, but likes to see similar map files in reversed order.
A correct linker map file looks like:
SCHILY_3
global:
function5;
function6;
local:
*;
SCHILY_2;
SCHILY_2
global:
function3;
function4;
local:
*;
SCHILY_1;
SCHILY_1
global:
function1;
function2;
local:
*;
;
The GNU linker however seems to like it this way:
SCHILY_1
global:
function1;
function2;
local:
*;
;
SCHILY_2
global:
function3;
function4;
local:
*;
SCHILY_1;
SCHILY_3
global:
function5;
function6;
local:
*;
SCHILY_2;
Does someone know a way to automatically convert the first correct form into the second for using UNIX/LINUX on-board programs?
linux ld
asked 2 days ago
schily
8,38721435
1
To be fair, while the GNU linker is unhappy with the first form, I believe every linker (that supports version scripts) should be happy with the second form... So maybe just consider converting it and use what you call the "reverse" form for all the linkers on all platforms? If that's the case, then a one-time manual conversion should be fine. If the example is simple as you describe, then just splitting in blocks on newline and printing them back in reverse order should be enough?
– Filipe Brandenburger
2 days ago
Given the under-specification and non-standard nature of linker scripts, I'm not completely surprised (or at all disappointed) that the GNU linker developers decided to only support references to already defined names and break on forward references... I mean, there's really no reason why you need forward references here (unlike in C source where they're absolutely needed in some cases.)
– Filipe Brandenburger
2 days ago
If you ever like to use the GNU linker to e.g. link a Solaris ARM port because the UNIX linker has not yet been ported to support ARM, you definitely don't like to manually convert thousands of linker map files.
– schily
2 days ago
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
Since a while (probably 12 years), the GNU linker includes support for linker map files for versioned shared libraries as introduced by Sun in 1993.
Unfortunately, the GNU linker rejects correct linker map files, but likes to see similar map files in reversed order.
A correct linker map file looks like:
SCHILY_3
global:
function5;
function6;
local:
*;
SCHILY_2;
SCHILY_2
global:
function3;
function4;
local:
*;
SCHILY_1;
SCHILY_1
global:
function1;
function2;
local:
*;
;
The GNU linker however seems to like it this way:
SCHILY_1
global:
function1;
function2;
local:
*;
;
SCHILY_2
global:
function3;
function4;
local:
*;
SCHILY_1;
SCHILY_3
global:
function5;
function6;
local:
*;
SCHILY_2;
Does someone know a way to automatically convert the first correct form into the second for using UNIX/LINUX on-board programs?
linux ld
asked 2 days ago
schily
8,38721435
Since a while (probably 12 years), the GNU linker includes support for linker map files for versioned shared libraries as introduced by Sun in 1993.
Unfortunately, the GNU linker rejects correct linker map files, but likes to see similar map files in reversed order.
A correct linker map file looks like:
SCHILY_3
global:
function5;
function6;
local:
*;
SCHILY_2;
SCHILY_2
global:
function3;
function4;
local:
*;
SCHILY_1;
SCHILY_1
global:
function1;
function2;
local:
*;
;
The GNU linker however seems to like it this way:
SCHILY_1
global:
function1;
function2;
local:
*;
;
SCHILY_2
global:
function3;
function4;
local:
*;
SCHILY_1;
SCHILY_3
global:
function5;
function6;
local:
*;
SCHILY_2;
Does someone know a way to automatically convert the first correct form into the second for using UNIX/LINUX on-board programs?
linux ld
asked 2 days ago
schily
8,38721435
asked 2 days ago
schily
8,38721435
asked 2 days ago
schily
8,38721435
asked 2 days ago
schily
8,38721435
8,38721435
1
To be fair, while the GNU linker is unhappy with the first form, I believe every linker (that supports version scripts) should be happy with the second form... So maybe just consider converting it and use what you call the "reverse" form for all the linkers on all platforms? If that's the case, then a one-time manual conversion should be fine. If the example is simple as you describe, then just splitting in blocks on newline and printing them back in reverse order should be enough?
– Filipe Brandenburger
2 days ago
Given the under-specification and non-standard nature of linker scripts, I'm not completely surprised (or at all disappointed) that the GNU linker developers decided to only support references to already defined names and break on forward references... I mean, there's really no reason why you need forward references here (unlike in C source where they're absolutely needed in some cases.)
– Filipe Brandenburger
2 days ago
If you ever like to use the GNU linker to e.g. link a Solaris ARM port because the UNIX linker has not yet been ported to support ARM, you definitely don't like to manually convert thousands of linker map files.
– schily
2 days ago
add a comment |Â
1
To be fair, while the GNU linker is unhappy with the first form, I believe every linker (that supports version scripts) should be happy with the second form... So maybe just consider converting it and use what you call the "reverse" form for all the linkers on all platforms? If that's the case, then a one-time manual conversion should be fine. If the example is simple as you describe, then just splitting in blocks on newline and printing them back in reverse order should be enough?
– Filipe Brandenburger
2 days ago
Given the under-specification and non-standard nature of linker scripts, I'm not completely surprised (or at all disappointed) that the GNU linker developers decided to only support references to already defined names and break on forward references... I mean, there's really no reason why you need forward references here (unlike in C source where they're absolutely needed in some cases.)
– Filipe Brandenburger
2 days ago
If you ever like to use the GNU linker to e.g. link a Solaris ARM port because the UNIX linker has not yet been ported to support ARM, you definitely don't like to manually convert thousands of linker map files.
– schily
2 days ago
1
1
To be fair, while the GNU linker is unhappy with the first form, I believe every linker (that supports version scripts) should be happy with the second form... So maybe just consider converting it and use what you call the "reverse" form for all the linkers on all platforms? If that's the case, then a one-time manual conversion should be fine. If the example is simple as you describe, then just splitting in blocks on newline and printing them back in reverse order should be enough?
– Filipe Brandenburger
2 days ago
To be fair, while the GNU linker is unhappy with the first form, I believe every linker (that supports version scripts) should be happy with the second form... So maybe just consider converting it and use what you call the "reverse" form for all the linkers on all platforms? If that's the case, then a one-time manual conversion should be fine. If the example is simple as you describe, then just splitting in blocks on newline and printing them back in reverse order should be enough?
– Filipe Brandenburger
2 days ago
Given the under-specification and non-standard nature of linker scripts, I'm not completely surprised (or at all disappointed) that the GNU linker developers decided to only support references to already defined names and break on forward references... I mean, there's really no reason why you need forward references here (unlike in C source where they're absolutely needed in some cases.)
– Filipe Brandenburger
2 days ago
Given the under-specification and non-standard nature of linker scripts, I'm not completely surprised (or at all disappointed) that the GNU linker developers decided to only support references to already defined names and break on forward references... I mean, there's really no reason why you need forward references here (unlike in C source where they're absolutely needed in some cases.)
– Filipe Brandenburger
2 days ago
If you ever like to use the GNU linker to e.g. link a Solaris ARM port because the UNIX linker has not yet been ported to support ARM, you definitely don't like to manually convert thousands of linker map files.
– schily
2 days ago
If you ever like to use the GNU linker to e.g. link a Solaris ARM port because the UNIX linker has not yet been ported to support ARM, you definitely don't like to manually convert thousands of linker map files.
– schily
2 days ago
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
0
down vote
With the help of the right basic idea taken from a friend, I have been able to find a solution for a filter:
| sed 's/^SCHILY/+SCHILY/' | tr '12' '@' | tr '+' '12' | sort -t. -n -k1 -k2 -k3 | tr '@' '12'
This first sed makes the block start unique, the first tr removes newlines, the second tr makes block starts separate lines, the sort command creates the needed order and the final tr command restores all newlines.
The sed command is a bit complex as it needs to deal with up to three levels of ordering.
answered 2 days ago
schily
8,38721435
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
With the help of the right basic idea taken from a friend, I have been able to find a solution for a filter:
| sed 's/^SCHILY/+SCHILY/' | tr '12' '@' | tr '+' '12' | sort -t. -n -k1 -k2 -k3 | tr '@' '12'
This first sed makes the block start unique, the first tr removes newlines, the second tr makes block starts separate lines, the sort command creates the needed order and the final tr command restores all newlines.
The sed command is a bit complex as it needs to deal with up to three levels of ordering.
answered 2 days ago
schily
8,38721435
add a comment |Â
up vote
0
down vote
With the help of the right basic idea taken from a friend, I have been able to find a solution for a filter:
| sed 's/^SCHILY/+SCHILY/' | tr '12' '@' | tr '+' '12' | sort -t. -n -k1 -k2 -k3 | tr '@' '12'
This first sed makes the block start unique, the first tr removes newlines, the second tr makes block starts separate lines, the sort command creates the needed order and the final tr command restores all newlines.
The sed command is a bit complex as it needs to deal with up to three levels of ordering.
answered 2 days ago
schily
8,38721435
add a comment |Â
up vote
0
down vote
up vote
0
down vote
With the help of the right basic idea taken from a friend, I have been able to find a solution for a filter:
| sed 's/^SCHILY/+SCHILY/' | tr '12' '@' | tr '+' '12' | sort -t. -n -k1 -k2 -k3 | tr '@' '12'
This first sed makes the block start unique, the first tr removes newlines, the second tr makes block starts separate lines, the sort command creates the needed order and the final tr command restores all newlines.
The sed command is a bit complex as it needs to deal with up to three levels of ordering.
answered 2 days ago
schily
8,38721435
With the help of the right basic idea taken from a friend, I have been able to find a solution for a filter:
| sed 's/^SCHILY/+SCHILY/' | tr '12' '@' | tr '+' '12' | sort -t. -n -k1 -k2 -k3 | tr '@' '12'
This first sed makes the block start unique, the first tr removes newlines, the second tr makes block starts separate lines, the sort command creates the needed order and the final tr command restores all newlines.
The sed command is a bit complex as it needs to deal with up to three levels of ordering.
answered 2 days ago
schily
8,38721435
answered 2 days ago
schily
8,38721435
answered 2 days ago
schily
8,38721435
answered 2 days ago
schily
8,38721435
8,38721435
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f460509%2flooking-for-a-workaround-to-a-gnu-linker-bug%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
To be fair, while the GNU linker is unhappy with the first form, I believe every linker (that supports version scripts) should be happy with the second form... So maybe just consider converting it and use what you call the "reverse" form for all the linkers on all platforms? If that's the case, then a one-time manual conversion should be fine. If the example is simple as you describe, then just splitting in blocks on newline and printing them back in reverse order should be enough?
– Filipe Brandenburger
2 days ago
Given the under-specification and non-standard nature of linker scripts, I'm not completely surprised (or at all disappointed) that the GNU linker developers decided to only support references to already defined names and break on forward references... I mean, there's really no reason why you need forward references here (unlike in C source where they're absolutely needed in some cases.)
– Filipe Brandenburger
2 days ago
If you ever like to use the GNU linker to e.g. link a Solaris ARM port because the UNIX linker has not yet been ported to support ARM, you definitely don't like to manually convert thousands of linker map files.
– schily
2 days ago